caliburn Wiki & Documentation Rss Feed

New Comment on "Building Caliburn"

vaananart — Fri, 07 Dec 2012 00:18:41 GMT

Is the following url still valid for checking out code https://caliburn.svn.codeplex.com/svn/trunk

New Comment on "Composite Commands"

vaananart — Fri, 07 Dec 2012 00:04:31 GMT

the following three lines were indicating as error even after I have setup and copied and pasted and followed you class namings correctly. I am using WPF framework with Caliburn and my Window1.xaml file correctly. <cal:AllCommand x:Key="Grandfather" /> <cal:AllCommand x:Key="All" /> <cal:AnyCommand x:Key="Any" /> I have also ensured the xmlns:cal="http://www.caliburnproject.org" is in place in the header part of Window1.xaml file. The other part of the Window.xaml file is fine and only showing errors linked three lines above. Following is the error message from Visual Studio 2010 while trying to compile. The tag 'AllCommand' does not exist in XML namespace 'http://www.caliburnproject.org'. Need your help, please.

Updated Wiki: Home

EisenbergEffect — Fri, 16 Nov 2012 18:19:58 GMT

Caliburn is a legacy framework maintained to support existing apps. Future development is focused on Caliburn.Micro.

STOP! If you are new here, we recommend a simpler framework with 90% of the features and power! Check out Caliburn.Micro.

If you like what you find here, please consider donating.

Updated Wiki: Home

EisenbergEffect — Fri, 16 Nov 2012 18:19:50 GMT

Caliburn is a legacy framework maintained to support existing apps. Future development is focused on Caliburn.Micro.

STOP! If you are new here, we recommend a simpler framework with 90% of the features and power! Check out Caliburn.Micro.

If you like what you find here, please consider donating.

Updated Wiki: Home

EisenbergEffect — Fri, 16 Nov 2012 18:19:20 GMT

Caliburn is a legacy framework maintained to support existing apps. Future development is focused on Caliburn.Micro.

STOP! If you are new here, we recommend a simpler framework with 90% of the features and power! Check out Caliburn.Micro.

If you like what you find here, please consider donating.

Updated Wiki: Home

EisenbergEffect — Fri, 16 Nov 2012 18:18:38 GMT

Caliburn is a legacy framework maintained to support existing apps. Future development is focused on Caliburn.Micro.

STOP! If you are new here, we recommend a simpler framework with 90% of the features and power! Check out Caliburn.Micro.

If you like what you find here, please consider donating.

New Comment on "PropertyChangedBase and BindableCollection"

mahara — Tue, 17 Apr 2012 13:00:55 GMT

@rekna: You're right about the performance issue with BindableCollection. I've just noticed it. I suspect it's caused by notification done using Execute.OnUIThread().

Updated Wiki: Home

EisenbergEffect — Wed, 14 Mar 2012 19:09:28 GMT

Caliburn is a legacy framework maintained to support existing apps. Future development is focused on Caliburn.Micro.

STOP! If you are new here, we recommend a simpler framework with 90% of the features and power! Check out Caliburn.Micro.

If you like what you find, please Donate.

Updated Wiki: Documentation

EisenbergEffect — Thu, 08 Mar 2012 22:19:39 GMT

v2.0 Documentation

Caliburn 2.0 exists to support existing applications built with Caliburn 1.0 and 1.1 which wish to upgrade to the latest .NET frameworks and presentation tier idioms. Please consider switching to Caliburn.Micro for new development. Also, you may wish to investigate upgrading your Caliburn 1.0/1.1 application to Caliburn.Micro instead of Caliburn 2.0. There are no further investment in new versions for Caliburn. All future development will be focused on Caliburn.Micro.

Soup to Nuts
- Basic Configuration, Actions and Conventions
- Customizing The Bootstrapper
- All About Actions
- IResult and Coroutines
- Screens, Conductors and Composition
- All About Conventions
- The Event Aggregator
- The Window Manager
- Caliburn vs. Caliburn.Micro

v1.1 Documentation

User Guide
- Getting Started
- Actions
- Commands
  - Basics
  - Composite Commands
- Application Model
- General
- Testability
Community Tutorials
Shells
- Navigation
  - Introduction
Gallery
- Products
- Blogs, Articles and Related Projects
MVVM Study

New Comment on "BlogsArticlesProjects"

swiszczak — Fri, 24 Feb 2012 11:17:06 GMT

'Build an Application with Caliburn And Prism' link is dead.

Updated Wiki: Home

EisenbergEffect — Wed, 19 Oct 2011 16:53:59 GMT

Project Description

A framework designed for WPF and Silverlight which implements a variety of UI patterns including MVVM (Presentation Model), MVP and MVC. Caliburn is a legacy framework maintained to support existing apps. Future development is focused on Caliburn.Micro.

STOP! If you are new here, we recommend a simpler framework with 90% of the features and power! Check out Caliburn.Micro.

If you like what you find, please Donate.

Click here to view the RSS feed.

Updated Wiki: Home

EisenbergEffect — Wed, 19 Oct 2011 16:53:26 GMT

Project Description

STOP! If you are new here, we recommend a simpler framework with 90% of the features and power! Check out Caliburn.Micro. If you like what you find, please Donate.

Click here to view the RSS feed.

New Comment on "Application"

kingliang123 — Thu, 21 Jul 2011 09:00:48 GMT

public partial class App : CaliburnApplication i can not sucess, had already add ref Caliburn.Core Caliburn.PresentationFramework Microsoft.Practices.ServiceLocation

New Comment on "PropertyChangedBase and BindableCollection"

rekna — Mon, 27 Jun 2011 19:56:37 GMT

One has to be carefull with BindableCollection because it does have quite a performance impact... When I changed an ObservableCollection which was bound to a datagrid in silverlight to a BindableCollection I noticed the datagrid build up far slower than with a ObservableCollection. And there were only 11 rows in the datagrid. Any comments on this performance issue?

Updated Wiki: The Event Aggregator

EisenbergEffect — Mon, 30 May 2011 17:10:17 GMT

The Event Aggregator

In Caliburn we have a series of supporting services for building presentation tiers. Among them is the EventAggregator, a service which supports in-process publish/subscribe. There are various implementations of this pattern available in other frameworks, but I think you’ll find that Caliburn's implementation sports the cleanest API and the richest set of features. Let’s start by having a look at the IEventAggregator interface:

public interface IEventAggregator {  
    void Subscribe(object instance);  
    void Unsubscribe(object instance);  
    void Publish(object message, Action<System.Action> marshal = null);  
}

Below we’ll dig into how the default implementation of this interface (EventAggregator) works.

With the Caliburn EventAggregator we don’t actually leverage events under the covers. Events are prone to memory leaks and it’s extremely difficult to avoid them or to write a flawless weak event implementation. Instead, we allow you to subscribe an object instance. Under the covers we hold a weak reference. That makes things quite simple. But, how do we know what messages to subscribe to and what methods to use as callbacks? Well, we follow a declarative model by requiring subscribers to implement an interface which states which message they are interested in and provides the callback method. The interface looks like this:

public interface IHandle<TMessage> : IHandle {  
    void Handle(TMessage message);  
}

And it’s used like this:

public class MyViewModel : IHandle<SomeMessage>{  
    public void Handle(SomeMessage message){  
        //do something with the message  
    }  
}

Because we use an interface, you can implement IHandle<T> as many times as you want on a given class. This approach keeps things declarative, strongly-typed and free from memory leaks. You can even use explicit interface implementations to hide the handlers if you desire.

Unsubscribe

There’s not too much to say about this. When you call this method, we search our list of subscribers and remove the specified instance. You may be wondering why this is even necessary if subscribers are held with weak references to begin with. It turns out that there are a number of cases where you want to control the subscription’s activation. Imagine you have a Screen Collection and only the Active Screen is supposed to receive events. In this case, you’d want to subscribe when the screen was activated and unsubscribe when it was deactivated.

Publish

As you might expect, calling Publish actually sends a message to all it’s subscribers. Here’s how you might use it:

public class MyOtherViewModel{  
    IEventAggregator events;  
  
    public MyOtherViewModel(IEventAggregator events){  
        this.events = events;  
    }  
  
    public void DoSomething(){  
        events.Publish(new SomeMessage{  
            SomeNumber = 5,  
            SomeString = "Blah..."  
        });  
    }  
}

Here, we get an instance of the IEventAggregator service via constructor injection. Then, when the DoSomething method is invoked, we publish the SomeMessage message along with its data. Assuming MyViewMododel above had subscribed itself to the aggregator, it would then have it's Handle method called with the SomeMessage instance. So how does this work? We do this by iterating our list of subscribers to see if any of them implement IHandle<T> where T is assignable from the message that is being published. All the matches that are found then have their handlers called on the UI thread.

Marker Interface

IHandle<T> inherits from a marker interface IHandle. This allows the use of casting to determine if an object instance subscribes to any events. This enables simple auto-subscribing if you integrate with an IoC container. Most IoC containers provide a hook for being called when a new instance is created. Simply wire for your container’s callback, inspect the instance being created to see if it implement IHandle, and if it does, call Subscribe on the event aggregator. Just remember, you probably don’t want to use this technique if you need conditional subscription as I described above.

Custom Publication Marshaling

By default messages will be automatically published synchronously on the UI thread. However, this is not always desirable. The optional "marshal" parameter allows you to provide an action which marshals the publication to a custom thread. By using this extension point, a developer could easily write extension methods such as: PublishOnCurrentThread, PublishOnBackgroundThread or PublishOnUIThreadAsync.

Polymorphic Event Subscriptions

Above I stated that during publication we check for handlers “where T is assignable from the message being published.” We do this with reflection rather than casting in order to enable polymorphic event subscriptions. Let me explain what this means by providing an example:

public interface ICustomerMessage{  
    //implementation here  
}  
  
public interface ICustomerCreated : ICustomerMessage{  
    //implementation here  
}  
  
public interface ICustomerDeleted : ICustomerMessage{  
    //implementation here  
}  
  
public class AnUnrelatedMessage{  
    //implementation here  
}  
  
public class MyObserver :  
    IHandle<object>,   
    IHandle<ICustomerMessage>,   
    IHandle<ICustomerDeleted> {  
      
    public void Handle(object message){  
        //will handle every message in the application  
    }  
  
    public void Handle(ICustomerMessage message){  
        //handles ICustomerCreated and ICustomerDeleted  
    }  
  
    public void Handle(ICustomerDeleted message){  
        //handles only ICustomerDeleted  
    }  
}

This turns out to be very powerful, especially when you need to evolve a system over time.

You can see the EventAggregator in action and step through some code by opening up the HelloEventAggregator sample under source. This sample creates a ShellViewModel with two child view models. Each child publishes a message that the other child is subscribed to. The ShellViewModel is subscribed to all messages via the polymorphic features of the aggregator. Here’s a screen shot after some messages have been published:

Referenced Samples

Caliburn.EventAggregation

Updated Wiki: The Event Aggregator

EisenbergEffect — Mon, 30 May 2011 17:09:56 GMT

The Event Aggregator

public interface IEventAggregator {  
    void Subscribe(object instance);  
    void Unsubscribe(object instance);  
    void Publish(object message, Action<System.Action> marshal = null);  
}

Below we’ll dig into how the default implementation of this interface (EventAggregator) works.

public interface IHandle<TMessage> : IHandle {  
    void Handle(TMessage message);  
}

And it’s used like this:

public class MyViewModel : IHandle<SomeMessage>{  
    public void Handle(SomeMessage message){  
        //do something with the message  
    }  
}

Unsubscribe

Publish

As you might expect, calling Publish actually sends a message to all it’s subscribers. Here’s how you might use it:

public class MyOtherViewModel{  
    IEventAggregator events;  
  
    public MyOtherViewModel(IEventAggregator events){  
        this.events = events;  
    }  
  
    public void DoSomething(){  
        events.Publish(new SomeMessage{  
            SomeNumber = 5,  
            SomeString = "Blah..."  
        });  
    }  
}

Marker Interface

Custom Publication Marshaling

Polymorphic Event Subscriptions

public interface ICustomerMessage{  
    //implementation here  
}  
  
public interface ICustomerCreated : ICustomerMessage{  
    //implementation here  
}  
  
public interface ICustomerDeleted : ICustomerMessage{  
    //implementation here  
}  
  
public class AnUnrelatedMessage{  
    //implementation here  
}  
  
public class MyObserver :  
    IHandle<object>,   
    IHandle<ICustomerMessage>,   
    IHandle<ICustomerDeleted> {  
      
    public void Handle(object message){  
        //will handle every message in the application  
    }  
  
    public void Handle(ICustomerMessage message){  
        //handles ICustomerCreated and ICustomerDeleted  
    }  
  
    public void Handle(ICustomerDeleted message){  
        //handles only ICustomerDeleted  
    }  
}

Referenced Samples

Caliburn.EventAggregation

Updated Wiki: Documentation

EisenbergEffect — Mon, 30 May 2011 17:04:43 GMT

v2.0 Documentation

Caliburn 2.0 exists to support existing applications built with Caliburn 1.0 and 1.1 which wish to upgrade to the latest .NET frameworks and presentation tier idioms. Please consider switching to Caliburn.Micro for new development. Also, you may wish to investigate upgrading your Caliburn 1.0/1.1 application to Caliburn.Micro instead of Caliburn 2.0. After v2.0, there will be no further investment in new versions for Caliburn. All future development will be focused on Caliburn.Micro.

Soup to Nuts
- Basic Configuration, Actions and Conventions
- Customizing The Bootstrapper
- All About Actions
- IResult and Coroutines
- Screens, Conductors and Composition
- All About Conventions
- The Event Aggregator
- The Window Manager
- Caliburn vs. Caliburn.Micro

v1.1 Documentation

User Guide
- Getting Started
- Actions
- Commands
  - Basics
  - Composite Commands
- Application Model
- General
- Testability
Community Tutorials
Shells
- Navigation
  - Introduction
Gallery
- Products
- Blogs, Articles and Related Projects
MVVM Study

New Comment on "Documentation"

ksnavinkumar — Fri, 27 May 2011 09:02:06 GMT

Hi Community, Please check or remove the LINKS which were broken Thanks, ksnavinkumar@live.com

Updated Wiki: Documentation

EisenbergEffect — Mon, 04 Apr 2011 13:20:04 GMT

v2.0 Documentation

Caliburn 2.0 exists to support existing applications built with Caliburn 1.0 and 1.1 which wish to upgrade to the latest .NET frameworks and presentation tier idioms. Please consider switching to Caliburn.Micro for new development. Also, you may wish to investigate upgrading your Caliburn 1.0/1.1 application to Caliburn.Micro instead of Caliburn 2.0. After v2.0, there will be no further investment in new versions for Caliburn. All future development will be focused on Caliburn.Micro.

Soup to Nuts
- Basic Configuration, Actions and Conventions
- Customizing The Bootstrapper
- All About Actions
- IResult and Coroutines
- Screens, Conductors and Composition
- All About Conventions
- The Window Manager
- The Event Aggregator
- Caliburn vs. Caliburn.Micro

v1.1 Documentation

User Guide
- Getting Started
- Actions
- Commands
  - Basics
  - Composite Commands
- Application Model
- General
- Testability
Community Tutorials
Shells
- Navigation
  - Introduction
Gallery
- Products
- Blogs, Articles and Related Projects
MVVM Study

Updated Wiki: Documentation

EisenbergEffect — Mon, 04 Apr 2011 13:19:05 GMT

v2.0 Documentation

Caliburn 2.0 exists to support existing applications built with Caliburn 1.0 and 1.1 which wish to upgrade to the latest .NET frameworks and presentation tier idioms. Please consider switching to http://caliburnmicro.codeplex.com/ for new development. Also, you may wish to investigate upgrading your Caliburn 1.0/1.1 application to Caliburn.Micro instead of Caliburn 2.0. After v2.0, there will be no further investment in new versions for Caliburn. All gfuture development will be focused on Caliburn.Micro.

Soup to Nuts
- Basic Configuration, Actions and Conventions
- Customizing The Bootstrapper
- All About Actions
- IResult and Coroutines
- Screens, Conductors and Composition
- All About Conventions
- The Window Manager
- The Event Aggregator
- Caliburn vs. Caliburn.Micro

v1.1 Documentation

User Guide
- Getting Started
- Actions
- Commands
  - Basics
  - Composite Commands
- Application Model
- General
- Testability
Community Tutorials
Shells
- Navigation
  - Introduction
Gallery
- Products
- Blogs, Articles and Related Projects
MVVM Study