NHibernate static proxy

It's been a long time (06/24/2011) I pushed my last commit on my GitHub project NHibernate.StaticProxy, and I notice only now that I even didn't speak about this project on my blog... Shame on me! So after a short delay (hum...), here it comes 🙂

[CaliburnMicro] Dependencies attribute on any depth level of properties

I didn't post anything on the blog for a very long time (2010-12-07), so let's break the silence with something new about Caliburn Micro.

In this post, I will briefly show you an update of an "old" article I wrote. The main drawback of the previous version of this dependencies attribute was its inability to make the availability of the action depend on more than one level.

For example, you could write these dependencies, which update the availability of the Do method when either OtherProperty (a property of the same view-model than Do) or OtherProperty.ChildProperty were modified.

[code lang="csharp"][Dependencies("OtherProperty", "OtherProperty.ChildProperty")] public IEnumerable Do() { }[/code] With the new Dependencies attribute I'll show you right after the break, you won't be limited to this single level of hierarchy, thus allowing you to write a dependency like:

[code lang="csharp"][Dependencies("OtherProperty.ChildProperty.OneMoreLevelProperty.LastLevelProperty.*")] public IEnumerable Do() { }[/code]

[PostSharp] Ease the creation of configuration sections

In this article, I'll show yet another use of PostSharp, this time focusing on the ConfigurationSection class. If you look in the MSDN at the articles which explain how to use the ConfigurationSection, you may have noticed that the code you need to write is repetitive, tedious, and error-prone:

[code lang="csharp"]public class PageAppearanceSection : ConfigurationSection { [ConfigurationProperty("remoteOnly", DefaultValue = "false", IsRequired = false)] public Boolean RemoteOnly { get { return (Boolean)this["remoteOnly"]; } set { this["remoteOnly"] = value; } } [ConfigurationProperty("font")] public FontElement Font { get { return (FontElement)this["font"]; } set { this["font"] = value; } } [ConfigurationProperty("color")] public ColorElement Color { get { return (ColorElement)this["color"]; } set { this["color"] = value; } } }[/code] As you can see, you have to put the ConfigurationPropertyAttribute on top of each property, and to make calls to an indexer to the Get and Set methods of the properties, using the same name you used in the attribute.

Doesn't this repetition look like to be a good candidate for an aspect?

[PostSharp] [Caliburn] Automatic IEventPublisher subscription and publication

If you develop in WPF using the MVVM pattern, you have certainly heard about the Event Aggregator pattern, which allows, as the MSDN says:

decoupling of publishers and subscribers so they can evolve independently.

There are several implementations of this pattern:

Of course, as the title of this article told you, we are going to use the latter, and I will propose an implementation of a PostSharp aspect which will help us to subscribe to events, publish them, and dispose the subscriptions when the view-model is deactivated.

[Caliburn Micro] Action filters - Dependencies on "properties of properties", using the Reactive Extensions

By default, Caliburn Micro (CM) doesn't contain the action filters which belong to Caliburn (C). There is a recipe on how to implement them back in CM, but unfortunately it doesn't cover all the initial functionalities which are in C.

One feature missing, and that I needed, is the possibility to depend on "properties of properties".

With the recipe, you can add a dependency between the property of a view-model (VM) and another property of this same VM. Thus, when the latter property is changed, the PropertyChanged event of the VM is fired, resulting in the update of the availability of the action on which the Dependencies attribute is put. But what it doesn't allow you to do, is to define something like:

[code lang="csharp"][Dependencies("OtherProperty.ChildProperty")][/code] This would update the availability of the action if OtherProperty implements INotifyPropertyChanged and if the ChildProperty is modified. You could even use something like:

[code lang="csharp"][Dependencies("OtherProperty.*")][/code] which would update the availability if any of the properties of OtherProperty is modified.

But let me show you how I implemented this feature on top of the recipe, with the great use of the Reactive Extensions.

[PostSharp] Don't NotifyPropertyChanged all properties

This article will show you another improvement which can be made to the DataBinding sample aspect found on SharpCrafters, after the Fire INotifyPropertyChanged.OnPropertyChanged for read-only properties depending on other properties article.

By default, the aspect will fire the PropertyChanged event each time any property is changed. But what if you don't want some of them to fire the event? Or what if, as it happened to me, you set the value of a property, and must do some work in the property setter, even if the new value of the property is the same as the old one?

The latter example is a bit odd, but in the default implementation of the aspect, in the OnPropertySet method, you have this code:

[code lang="csharp"]if ( args.Value == args.GetCurrentValue() ) return; args.ProceedSetValue();[/code] If the new value of the property is the same, the aspect will return, and then never call the args.ProceedSetValue(); method, which will avoid your code to be called in the property setter.

In this short article, I'll show you how to change the aspect, to call the OnPropertyChanged event on all properties, excepted those which are marked with a custom attribute.

[Caliburn Micro] How to use the same view for multiple view-models

The default behavior of Caliburn Micro (CM), when it must locate a view from a view-model, is very straightforward: it takes the full name of the view-model, replaces the word "Model" by an empty string, and locates a view with this new name.

One problem with this way is that you must exactly have one view per view-model. So, if you have an abstract view-model, with multiple derived view-models, which only set some filters on the displayed data, you must have one view per derived VM. Which is kind of annoying, useless, and error prone.

In this short article, I'll show you how to easily implement a new feature which will allow us to specify, with an attribute on top of the VM, the view we want CM to display when we activate the VM.

[PostSharp] Fire INotifyPropertyChanged.OnPropertyChanged for read-only properties depending on other properties

One problem of the INotifyPropertyChanged aspect concerns automatic notification of read-only properties which depend on other properties.

Indeed, say you have this class, on which the aspect is applied:

[code lang="csharp"][NotifyPropertyChanged] public class Test { public string FirstName { get; set; } public string LastName { get; set; } public string FullName { get { return FirstName + " " + LastName; } } }[/code] If you change the values of FirstName or LastName, the OnPropertyChanged event will be fired, and the view will be able to display the new values of the properties. But if a control of your view is bound to the FullName property, it won't be updated. A solution would be to declare FullName as an automatic property, and update it in the setters of FirstName and LastName. Not very practical.

In this article, I will show you how to extend the aspect, in order to make it fire the event for dependent properties when a "parent" property is modified.