Archive for January, 2010

25
Jan
10

Migration to Caliburn v2

After being held captive by the aliens for the last couple months… ehm… what? it’s hardly credible?

The plain truth is that I’m having a very busy period at work, so I had to cut hobbies to avoid my daughter stopping calling me “papà” (“daddy”, in italian).

Nevertheless, I missed the pleasure of writing something here (I have to exercise my English!) so I’ll report about my effort to port a couple project I’m working on to Caliburn v2. I froze my references to v1.x branch some time ago and deferred the update until today, for the lack of necessary time and because I was afraid to slow down my work with breaking changes.
But all new stuff introduced by Rob in Caliburn trunk was too tempting; plus, I started to be hardly able to follow new Caliburn forum posts about new features, so I finally decided to switch.

It was not hard at all, I have to say.

I still have to refine class and variables names to follow the new “Screens” naming (formerly “Presenters”), but I’ve got the whole thing compiling and passing tests.

For those who are about to start the migration to v2, here is a list of the changes I had to make in my projects. It’s very unlikely an exhaustive list of all changes made to Caliburn, but, since I use a lot of customizations, I think it covers the most frequent issues.

Modules

Modules structure was a bit refactored to simplify (I guess) the addiction of configuration parameters to existing and new framework modules; from the user perspective, it means just to choose the new correct base class and the renaming of a couple methods.
I use modules for two distinct goals:

  • provide a way for independent application parts to load and hook itself into the shell without hard-wiring their reference in the main exe
  • hook some app-specific configuration into the CaliburnFramework static accessor, mimicking other Caliburn’s modules fluent configuration style.

For the first need I inherited from ModuleBase; for the second goal, I started from CaliburnModule<T> and added an extension method to hook into the fluent configuration. In both cases I had to change the name of Initialize and GetComponents methods into InitializeCore and GetComponentsCore.


public class MyAppModule : ModuleBase
{
  protected override void InitializeCore(Microsoft.Practices.ServiceLocation.IServiceLocator locator)
  {
  }

  protected override IEnumerable<IComponentRegistration> GetComponentsCore()
  {
    yield return Singleton(typeof(IMyService), typeof(MyService));
  }
}
 

public class MyFluentModuleConfig : CaliburnModule<MyFluentModuleConfig>
{
  protected override void InitializeCore(Microsoft.Practices.ServiceLocation.IServiceLocator locator)
  {

  }

  protected override IEnumerable<IComponentRegistration> GetComponentsCore()
  {
    yield return Singleton(typeof(IMyOtherService), typeof(MyOtherService));
  }
}

public static class Extenstions
{

  public static MyFluentModuleConfig MyFluentModule(this IModuleHook hook)
  {
    return hook.Module(MyFluentModuleConfig.Instance);
  }
}

Screens

There was a major refactoring in this area:

  • Naming change (“Presenters” are now “Screens”)
  • Strong typing of the screen with regard to their “subject”
  • Strong typing of screen composites based on contained screen
  • Automatic activation of already opened screen based on their subject

In order to accomodate existing code to v2 you have to replace existing class and interfaces following the subsequent scheme:

  • IPresenter –> IScreen
  • IPresenterHost -> IScreenCollection<IScreen>
  • IPresenterManager -> IScreenConductor<IScreen>
  • MultiPresenter -> ScreenConductor<IScreen>.WithCollection.AllScreensActive
  • MultiPresenterManager -> ScreenConductor<IScreen>.WithCollection.OneScreenActive
  • PresenterManager -> ScreenConductor<IScreen>
  • Presenter –> Screen

I closed generic class against IScreen to exactly reproduce the previous behaviour; note that I also chose to use generic version of IScreenCollection and IScreenConductor to match the new signature of screen-related extension functions.

I’m still not getting the benefits of strong typing and subject management, I have to refactor my applications in more depth for this.

Application

I had to fix a trivial signature change in CaliburnApplication.ConfigurePresentationFramework override. In addiction, I changed calls to Presentation Framework module configuration:

module.UsingViewStrategy<NoxaViewStrategy>();

module.UsingWindowManager<NoxaWindowManager>();

changed to

module.Using(c => c.ViewLocator<NoxaViewStrategy>());

module.Using(c => c.WindowManager<NoxaWindowManager>());

Framework classes

Some refactoring was done in the framework internals, so you only have to adjust this classes if you have done customization of the framework behaviour:

  • IWindowManager interface: bool isDialog parameter was added in EnsureWindow signature
  • IResult: signature of Execute method is changed from
    void Execute(IRoutedMessageWithOutcome message, IInteractionNode handlingNode)
    to
    void Execute(ResultExecutionContext context)
  • IResult: signature of Completed event was changed in
    EventHandler<ResultCompletionEventArgs>

Other random member name changes

  • RoutedMessageController -> DefaultRoutedMessageController
  • IBinder -> IViewModelBinder
  • ViewAttribute: namespace change
  • IViewStrategy -> IViewLocator
  • IViewStrategy.GetView –> IViewLocator.Locate
  • CurrentPresenter property -> ActiveScreen
  • Presenters property -> Screens
  • IExtendedPresenter interface -> IScreenEx
  • Open method -> OpenScreen
  • Shutdown method -> ShutdownScreen



January 2010
S M T W T F S
« Oct   Mar »
 12
3456789
10111213141516
17181920212223
24252627282930
31  

%d bloggers like this: