structuremap/structuremap — pull request #30 by cpx (2011-12-04 16:19:31+00:00)
Title: TypeConverter support in PropertyExpression.EqualToAppSetting()

Commit contains: PropertyExpression.EqualToAppSetting() is changed so that it scans for TypeConverterAttribute on the property and uses the TypeConverter when setting the property value.

Motivation: In a project I'm working in I want to load a URI from appSettings as follows:
...WithProperty(x => x.ServiceUri).EqualToAppSetting("serviceUri");
The problem is that appSettings values are always strings, so my only two options are to either change the ServiceUri property to be a string, and convert it to a Uri in the owning class (pretty ugly), or to use PropertyExpression.EqualsTo() and load the value manually from appSettings and convert it in the initializer (also pretty ugly).

Other thoughts:
* TypeConverters did come along with WPF (in order to facilitate creating objects in XAML) but they reside in System.ComponentModel in System.dll, so they're not really coupled to WPF at all. I.e. it shouldn't introduce any funky dependency by using them in StructureMap.
* I did try two approaches to implementing this. This commit contains the approach with minimal impact on the rest of the codebase, but at the cost of having to load the PropertyInfo in the constructor. This is redundant since SetterPropertyCollection already loads the PropertyInfo, but necessary because there doesn't seem to be any way of getting it from there.
* The other approach was to refactor so that PropertyInfo is loaded in PropertyExpression, and passed down to the SetterProperty through ConstructorInstance.SetValue(), but this quickly required breaking or expanding a number of interfaces, since pretty much everything relies on members being passed by name and not as MemberInfo objects. Personally I think it would be a good refactoring to do, because MemberInfo is a much better representative for a member than a simple string. There are probably issues I haven't foreseen with such a refactoring, but from a naive point of view, it seems more sound.

Anyway, I think it would be really great if this change was accepted into the repo!