For those of you who are using Caliburn v1.1, please grab the latest revision, build and try it out with your applications. Assuming there are no further major issues, we will be releasing v1.1 shortly.

If you aren’t using v1.1, then you are probably using the 2.0 Alpha in the Trunk. I’m planning to make some further breaking changes there. So, I just want to warn you in advance. Below is a list of what I am planning on doing. There are a couple of things I haven’t quite decided fully about. I would enjoy your feedback on those items.

CaliburnApplication

Currently the standard approach to building an application is to inherit your application class from CaliburnApplication. I’m going to do away with this. I think having to alter the application object itself is a negative. But, there’s a bigger reason I want to change this. I need a way to discover various configuration settings at design-time without instantiating an application class. This will open up the possibility for better design-time support, possibly including the ability to apply a developer’s custom conventions at design-time. What I am going to add is a base Bootstrapper class. Developers will inherit from this class, receiving access to all the methods they currently get from the CaliburnApplication class, then they will simply add the bootstrapper to their application’s resources. When the application starts, the resource will be created and will hook the same events the CaliburnApplication class does now.

ScreenConductor, et al.

In many cases I have the need for a ScreenConductor-like functionality across ViewModels which do not implement the IScreen interface or which only require a portion of that interface such as Activation. I’m planning to break the IScreen interface into a series of composable interfaces and rework the ScreenConductor classes around that. So, instead of ScreenConductor<T>, you will have Conductor<T>. If T implements the IActivate interface, it will be activated, if it implemented the IDeactivate interface, it will be deactivated, etc. I’m also planning some signature changes to the methods on those interfaces to simplify certain scenarios and to account for lifecycle events in a cleaner way. Below are the proposed changes in brief:

   public interface IActivate

   {

       void Activate();

       event EventHandler<ActivationEventArgs> Activated;

   }

 

   public interface IDeactivate

   {

       void Deactivate(bool close);

       event EventHandler<DeactivationEventArgs> Deactivated;

   }

 

   public interface IGuardClose

   {

       void CanClose(Action<bool> callback);

   }

 

   public interface IHaveDisplayName

   {

       string DisplayName { get; set; }

   }

 

   public interface IScreen : IHaveDisplayName, IActivate, IDeactivate, IGuardClose, INotifyPropertyChangedEx

   {

   }

 

   public class ActivationEventArgs : EventArgs

   {

       public bool WasInitialized;

   }

 

   public class DeactivationEventArgs : EventArgs

   {

       public bool WasClosed;

   }

I believe this will add much greater flexibility and simplify some of the inner workings as well.

CommonServiceLocator

I’d like your feedback on this item. I am considering removing the dependency on the CSL. In general, it has lost favor with many developers. Additionally, there’s really no benefit to Caliburn from keeping the dependency, since the Caliburn project maintains all the container adapters itself. When I first added it, there was some thought that it might be added to a future version of the .NET Framework. Recently, discussion seems to indicate that Microsoft has no plans to ever do that and additionally they have made no effort to update it for newer versions of .NET or to incorporate improvements/feedback from the community. In such a case it would be easier for Caliburn to simply define its own interface. This would also reduce the number of assemblies and the overall size of Caliburn. If I do this, the API probably won’t change at all. I’ll combine Caliburn’s existing IRegistry and IContainer interfaces with a basic Service Locator interface so that it essentially looks and works exactly like it does now. Thoughts?

System.Windows.Interactivity and Version Support

I’m planning to drop support for Silverlight 2.0 in v2. My question is: Can I drop support for Silverlight 3.0 as well? If we can support only .NET and SL4 (and later), then we can make some major improvements to Caliburn’s routed messaging and Actions implementation. You may have noticed that Microsoft’s System.Windows.Interactivity.Interaction.Triggers et al, look a lot like Caliburn’s Message.Triggers syntax. (I’ve often wondered if they copied Caliburn, since my implementation predates theirs by a year or two.) If we only have to support SL4 and beyond, I can remove my duplicate implementation and base Caliburn’s mechanism on the Microsoft supported Triggers mechanism. This would reduce a lot of duplicate code in Caliburn. It would also provide instant Blendability to Caliburn’s actions, since Blend already supports Interaction.Triggers with a nice design-time experience. Furthermore, it would allow any community developed Interaction.Trigger to be plugged into Caliburn to trigger Actions/Commands/RoutedMessages. So, there are a lot of huge benefits. But, it cannot be done with SL3, due to platform limitations, which were finally fixed in SL4. I’ve been fighting for these fixes since SL2, and they finally got it done. So, again, my question is: Would it be ok to only support .NET and SL4 going forward in order to make these improvements?

I agree with everything you've said. CSL seemed like a good idea for the reasons you described, but after a while seemed to only get in the way. I found myself going more towards a static class with a Func instead just setup at startup, and easily mocked for tests.

I am always a fan of cutting out fat where you can. If it makes your life easier, go for it.

+1 for dropping support for older versions of Silverlight. There is Caliburn 1.1 for people who need to support SL 2 or 3, I think it would be a mistake at this stage to hold back the types of improvements you're suggesting for platforms which are shrinking fast.

If there's a lot of demand for Silverlight 3 support it's not too difficult to support binding to System.Interactivity behavior properties in Silverlight 3. I've used nRoute Toolkit's Bindinable Triggers,Actions,Behaviors where are inherited versions of the ones in System.Interactivity which provide a very easy to use syntax for creating behaviors that supporting binding to behavior property targets, extremely useful before Silverlight 4 added binding support for Dependency Object targets (in SL3 it was only FrameworkElement).  I don't know if this is true or not, but the nRoute toolkit, or something like it may still be necessary for behavior binding support in Windows Phone 7. 

The real problem with System.Interactivity and SL3 is not binding to the ActionMessage itself. That will work. The problem is binding to the Parameters. That will not work because the DependencyObject and ElementName binding support was really only partially done in SL3. They finished the work in SL4. So, if I still had to support SL3, I would have to keep all the current hacks I have in place now, which is what I really want to remove.

Here are what I think you would have to change:

1. Switch your application back to inheriting from Application and move the code previously in your application class into a new class called Bootstrapper. Add the bootstrapper to your application's resources.

2. Change the base classes related to ScreenConductors. The compiler should tell you everything that is wrong here. Some properties are going to change. For example, the Screens property will be renamed to Items and ActiveScreen to ActiveItem (to reflect that we will  be able to conduct any object). This is probably the biggest issue for those using conventions and relying on element name convention binding. This will be the first thing I work on because it is the most destructive. If you are doing a lot of coding against the ILifecycleNotifier interface, you will need to adapt that to the new IActivate, etc interfaces as well.

3. Hopefully, removal of CSL will be transparent. If there are any changes, the compiler will help in finding them. I don't think this will be a big deal.

4. If you are using Message.Attach, you should see no changes to how you handle Actions. If you are using the long syntax via Message.Triggers, you will have to change all instances of this to use Interaction.Triggers.

So, the ScreenConductor changes are the biggest issue. But, if you are coming from v1.1 to 2.0, you would have to deal with that anyways.

That's the question on my mind too ;)

+1 for SL4 only. +1 for removal of CommonServiceLocator.  The CaliburnApplication and IScreen changes sound good as well. Is EventAggregator coming in 2.0?

@mlinnen It's already in the trunk and based on Reactive Extensions. See here. :)

I should also mention that there are improvements/extensions planned for the event aggregator as well.

SL4 only please!  Other changes make sense too.

+1 for dropping CSL. Less is more in this case.

+1 for dropping SL3 in caliburn 2 too. As others said. if you're still on SL3, use v1.1

Remco

Sorry, the post was actually about *my* migration result, not a general guide; I should have pointed this out.
About your questions:

1) You can use IConventionManager.AddElementConvention method to inject new interaction defaults into the default manager, or you can provide a custom IConventionManager inheriting from DefaultConventionManager and override DefaultConventionManager.GetDefaultElementConventions.

2) Conventions applied to a view are grouped into IViewConventionCategory-ies, depending on the the View Model "target" they apply to.
Let me elaborate a bit: to attempt conventional bindings, the framework enumerates all components available in the VM that could possibly be bound to a view element; this "target" (exposed by IViewModelDescription) includes properties, actions and filters.
A IViewConventionCategory is composed by a set of "rules" (IViewConvention-s) focused on uniform targets (for example, all actions available in a VM) and figures out a set of applications.

You can add new IViewConventionCategory-ies with IConventionManager.AddViewConventions, but to fine trim the default rules you have to provide a custom IConventionManager and override SetupDefaultViewConventions.

3) Subject are useful in scenarios using composition in VM, where you have multiple screens exposing the same "sub-viewmodel", or the same screen working with multiple kind of object:

public class PersonEditorScreen: Screen, IPersonEditorScreen {
  public Person ThePerson {get;set;}
}
public class PersonOverviewScreen: Screen, IPersonOverviewScreen {
  public Person ThePerson {get;set;}
}
public class OrganizationOverviewScreen: Screen, IOrganizationOverviewScreen {
  public Organization TheOrganization {get;set;}
}

You can reorganize screens like:

public class PersonEditorScreen: Screen<Person>, IPersonEditorScreen {}
public class GenericOverviewScreen: Screen<T>, IOverviewScreen<T> {
 //common overview behaviors
}
public class PersonOverviewScreen: GenericOverviewScreen<Person> {}
public class OrganizationOverviewScreen: GenericOverviewScreen<Organization>  {}

This allows to qualify the screen as "a screen presenting a subject", gaining some facility from the ScreenConductor/IScreenSubject infrastructure: when you open a subject in a conductor, the latter takes care of creating a new screen against the given subject or to activate an existing one if already present.

+1 for SL4 only. +1 for removal of CommonServiceLocator.

+1 for SL4 only. All other ideas sounds good as well.

-1 for SL4 only. My current project is rather large and complex (+700,000 LOC code-base) to which we have added Silverlight components using Caliburn trunk and the customer has no plans to upgrade to VS 2010 in the near future which makes SL4 unreachable for us. From what I gather using SL4 only will require VS 2010 and that upgrade isn't done overnight in larger codebases and teams. So SL4 is no problem for us but VS 2010 is. Please correct me if I have the wrong idea about the VS 2010+SL4 coupling that Microsoft has done. Also I think we cannot partially upgrade since the csproj/vbproj/sln format is not compatible so all developers would have to go into 2010 in one go (or we need to split the codebase into binary only dependencies which will make inter-operability painful). 

If Caliburn has to be SL4-only to be great I understand that you will have to do.... But it would be nice to have a way out for us poor VS 2008-only guys...

All changes above except System.Windows.Interactivity will work for SL3. The interactivity piece will work partially; Action Parameters bound to elements will not work. Would you be able to live with that? If so, I could continue with my plan but keep SL3 as part of the build.

I think people in general are more willing to upgrade their projects to the latest Silverlight in general, sans Caliburn, since every Silverlight release so far has had must have core feature adds. It's not like the move from WPF 3 to 3.51 or 4, the feature adds tends to be more dramatic (printing, webcam support, com interop, out of browser, core binding/styling features, etc..).

Hi, I am currently using caliburn-50837 trunk.

I want to use my own bootstrapper instead of using CaliburnApplication class.

Is the base calss for Bootstrapper is added in this trunk? I have tried to look into the trunk but couldn't  find it.

If yes how I can use it.

Thanks,  Rajendra.

None of the changes discussed here are in the Trunk yet. The first round of changes, related to ScreenConductor, will be checked in soon. After that I'll probably work on the IoC piece, then the Bootstrapper and finally the Interactivity. You should know, that using CaliburnApplication is not required. You could create your own Bootstrapper fairly easily by using the raw configuration API. Have a look at the basic samples for actions, etc. They all use the config API directly.

@Rajendra

No, the refactoring is not done yet. Anyway, if you would like to anticipate segregation of bootstrapping code from Application class, you can use the "fluent" configuration rather than CaliburnApplication base class:

http://caliburn.codeplex.com/wikipage?title=Project%20Setup&referringTitle=Documentation
 

Can't we getting a view of "Coming Attractions" with Caliburn.Micro?

Rob

Yes. Essentially the Conductors from Micro are being ported over. I'm working on that now and have made a few improvements int the process which I will probably feedback into Micro as well. Bootstrapper and ActionMessage will be coming over as well, though their implementations will probably be quite a bit different in Caliburn in the end, due to the fact that they have to support a lot more features.

How do you use dragable event triggers in blend to fire view model methods? With MvvmLite I would have been able to select a delegate command from the binding in blend, but I'm not really sure how to do this with Caliburn. I'm fairly new to this but I see that Caliburn is using normal methods instead of delegate commands but blend will not let me select a method as a Command. What am I missing?

Edit: Found the ActionMessage haha.

I just downloaded the source and figure that one indication this isn't complete is that the solution in still VS2008..

Since I don't work with WP7 I have no compelling reason to need CM's smaller footprint, and I like that Caliburn (Classic?) has more in the way of validation and unit testing support (not to mention unit tests!).

I saw the recommendation to "prefer CM", but I'm not totally sure why. Is there a latest statement of direction for both products that I'm missing? 

Cheers

+1 for SL4 only