Hi All, I'm back from my honeymoon... and so that means it's time to resume the Sylvia Park Architecture Chat.

Next one is scheduled for this Thursday, 17^th April 2008 at 11:30am at Garrisons.

No set topics this week - just an open floor / general catch up - though if anyone has any ideas just leave a comment on this post or send me an email.

Look forward to seeing you all there!

Someone recently sent me an email letting me know my NUnit "support" for IronPython project only targeted NUnit 2.2 and was a little out of date.

(For those not sure what I'm talking about - perhaps take a look back at these posts (1, 2) from October of 2006)

I didn't realise anyone was actually using it - but I see it's being linked too from the IronPython cookbook, so I decided to take half an hour and update it to target NUnit 2.4 - I left it targeting IronPython 1.1 however instead of 2.0 (IronPython users should be able to handle that task if required).

The usage changes a little from NUnit 2.2 to 2.4, instead of deriving your tests from a custom TestSuite class you now just annotate an empty class with some attributes... makes everything a little cleaner as your project doesn't need to reference IronPython etc. any more.

[PythonSuite, Script(FileName = "MyPythonFixture.py")] public class MyPythonSuite { }

The python files are embedded resources by default (though it's a minor code change to support external python files as well) - you can include multiple Script attributes for a single suite as well, if required.

If you want to dynamically include python resource files based on their content i.e. all embedded resources with a first line containing "#test" then you would do this:

[PythonSuite(DiscoverEmbeddedResources = true, DiscoveryKey = "#test")] public class DynamicPythonSuite { }

The project is now split into two assemblies.

• IronPythonTest.Addin
• IronPythonTest.Framework

The Addin assembly needs to be installed into your NUnit 2.4 add-ins directory i.e. C:Program Files (x86)TestDriven.NET 2.0NUnit2.4addins - you will need to place the IronPython assemblies in there as well if they're not registered in the
GAC.

Only the framework assembly needs to be referenced in your project so you can have access to the PythonSuite and Script attributes.

And that's about it, all other questions should be answered in the posts from 2006, or just leave a comment on this post if you have any trouble.

Code can be downloaded from here.

So just a short note to say that I got married on the 23rd of Feb
to the love of my life Renee... a good time was had by all, even
though the weather was horrific (rained
non-stop for 2 days) - big thanks to Ben, Nick, Stu, Sacha (my
Entourage) and everyone else for helping with the last minute
re-organisations :)

I'm now on honeymoon in Europe... currently lurking in Rome for a
few days to take in the local sights - however we'll be making our
way to England soon to catch up with some family.

For anyone curious about the Architecture Chat, it'll start up
again in April once I'm back in New Zealand and my life has
returned to some semblance of normality.

So a few weeks back there was a  post on the Genome TeamBlog which included a link to one of my  lambda abuse posts from last year.

At any rate - the problem they faced was that with code like this:

DataContext Context = new DataContext();
string connStr = "";
DataDomainSchema schema = DataDomainSchema.LoadFrom("SomeMappingFile");
schema.CreateDbSchema(connStr);
DataDomain dd = new DataDomain(schema, connStr);
using (Context.Push(ShortRunningTransactionContext.Create()))

{

    Customer tt = dd.New();

    tt.Name = "TechTalk";
    RootProject tt_hk = dd.New();

    tt_hk.Name = "Housekeeping";
    ChildProject tt_hk_hol = dd.New();

    tt_hk_hol.Name = "Holiday";

    tt_hk.ChildProjects.Add(tt_hk_hol);
    ChildProject tt_hk_ill = dd.New();

    tt_hk_ill.Name = "Illness";
    tt_hk.ChildProjects.Add(tt_hk_ill);
    tt.RootProjects.Add(tt_hk);
    RootProject tt_g = dd.New();

    tt_g.Name = "Genome";
    ChildProject tt_g_dev = dd.New();

    tt_g_dev.Name = "Development";

    tt_g.ChildProjects.Add(tt_g_dev);
    ChildProject tt_g_mnt = dd.New();

    tt_g_mnt.Name = "Maintenance";

    tt_g.ChildProjects.Add(tt_g_mnt);

    tt.RootProjects.Add(tt_g);
    Context.CommitCurrent();

}

You ended up with a very flat member initialization structure plagued with:

• Having to explicitly name child instances being added to collections - there's a lot of unnecessary noise.
• Where you can't easily see the structure i.e. it's not visually hierarchical, so at a glance you're not sure just what the structure is compared to say looking at an xml document with nested elements where it's quite obvious.

At any rate, the guys at the Genome project attempted to overcome this using the nested lambdas (what I coined a "DSL" at the time, though It's a terrible and inaccurate term for what's effectively just a bit of a "trick" relying on side effects of evaluation) - it didn't go so well though because of course at first glance the syntax look strongly typed, the reality is it's anything but, and refactoring tools just aren't going to do things like renaming of keys in the hash style syntax i.e. key => value, because the key is just a Lambda parameter.

But all is not lost - of course with C# 3.0 we already have a great syntax for doing this kind of hierarchical initialization, say for this set of types:

public class BlogPost

{

    private readonly List _tags = new List();

    private readonly BlogUser _createdBy = new BlogUser();       
    public string Title { get; set; }
    public string Body { get; set; }
    public List Tags

    {

        get { return _tags; }

    }
    public BlogUser CreatedBy

    {

        get { return _createdBy; }

    }
    public BlogUser LastEditedBy { get; set; }

}
public class BlogUser

{

    public int Age { get; set; }

    public string Name { get; set; }

}

We could do something like this to initialize an instance of BlogPost:

BlogPost post = new BlogPost()

{

    Title = "Post on Lambdas",

    Body = "This is a post...",

    Tags =

    {

        ".Net",

        "Lambda",

        "C#3.0"

    },

    CreatedBy =

    {

        Name = "Jane Doe",

        Age = 35

    },

    LastEditedBy = new BlogUser()

    {

        Name = "Joe Bloggs",

        Age = 25

    }

};

But the catch for the Genome guys is that it looks like they need to construct their entities using their DataDomain class ...  I don't know about how there product works but I can only assume it's either to get a transparent proxy for change tracking purposes or to enlist it into the current session etc. (though if it's just to enlist the entity I can't see why they need to bother with getting the DataDomain to create a new instance, surely they could manually enlist it).

At any rate that's irrelevant :)

So I got to thinking that of course member initialization is one of the Lambda-friendly things we can do because it's expressed in a single statement - so we can happily take the above code snippet and express it like so:

BlogPost post = evaluator.Create(() => new BlogPost()

{

    Title = "Post on Lambdas",

    Body = "This is a post...",

    Tags =

    {

        ".Net",

        "Lambda",

        "C#3.0"

    },

    CreatedBy =

    {

        Name = "Jane Doe",

        Age = 35

    },

    LastEditedBy = new BlogUser()

    {

        Name = "Joe Bloggs",

        Age = 25

    }

});

Where evaluator is an instance of a class I wrote called ServiceInjectionEvaluator ... the Create method (as you can probably guess) has the following signature:

public T Create(Expression<>> expression)

The service injection evaluator just relies on being configured with an  IServiceProvider capable of resolving instances of types... at this point we just unwind the expression, substituting our own instance activation mechanism wherever we stumble upon a  NewExpression and walking through the expressions executing each bit as required - though it makes the assumption that you're going to have either a New or MemberInit expression at the top level of the Lambda, otherwise we just compile the whole thing and throw it back without any changes (because I don't want to bother writing code to visit the other types of expression node).

public class ServiceInjectionEvaluator

{

    private readonly IServiceProvider _serviceProvider;
    public ServiceInjectionEvaluator(IServiceProvider serviceProvider)

    {

        _serviceProvider = serviceProvider;

    }
    public T Create(Expression<>> expression)

    {

        switch (expression.Body.NodeType)

        {

            case ExpressionType.New:

            case ExpressionType.MemberInit:

                return (T)EvaluateExpression(expression.Body);

            default:

                return expression.Compile().Invoke();

        }

    }
    private object GetInstanceWithInit(MemberInitExpression expression)

    {

        object instance = GetInstance(expression.NewExpression);

        foreach (MemberBinding binding in expression.Bindings)

        {

            ApplyBinding(instance, binding);

        }

        return instance;

    }
    private void ApplyBinding(object instance, MemberBinding binding)

    {

        switch (binding.BindingType)

        {

            case MemberBindingType.Assignment:

                ApplyAssignmentBinding(instance, (MemberAssignment)binding);

                break;

            case MemberBindingType.ListBinding:

                ApplyListBinding(instance, (MemberListBinding)binding);

                break;

            case MemberBindingType.MemberBinding:

                ApplyMemberBinding(instance, (MemberMemberBinding)binding);

                break;

            default:

                throw new NotImplementedException();

        }

    }
    private void ApplyMemberBinding(object instance, MemberMemberBinding binding)

    {

        PropertyInfo property = (PropertyInfo)binding.Member;

        object memberValue = property.GetValue(instance, null);

        foreach (MemberBinding childBinding in binding.Bindings)

        {

            ApplyBinding(memberValue, childBinding);

        }

    }
    private void ApplyListBinding(object instance, MemberListBinding binding)

    {

        object list = ((PropertyInfo)binding.Member).GetValue(instance, null);
        foreach (ElementInit elementInit in binding.Initializers)

        {

            Delegate compiled = Expression.Lambda(Expression.NewArrayInit(typeof(object), elementInit.Arguments.ToArray())).Compile();

            object[] arguments = (object[])compiled.DynamicInvoke();

            elementInit.AddMethod.Invoke(list, arguments);

        }

    }
    private void ApplyAssignmentBinding(object instance, MemberAssignment assignment)

    {

        object value = EvaluateExpression(assignment.Expression);

        PropertyInfo info = (PropertyInfo)assignment.Member;

        info.SetValue(instance, value, null);

    }
    private object EvaluateExpression(Expression expression)

    {

        switch (expression.NodeType)

        {

            case ExpressionType.New:

                return GetInstance((NewExpression) expression);

            case ExpressionType.MemberInit:

                return GetInstanceWithInit((MemberInitExpression) expression);

            default:

                return Expression.Lambda(expression).Compile().DynamicInvoke();

        }

    }
    private object GetInstance(NewExpression expression)

    {

        return _serviceProvider.GetService(expression.Type);

    }

}

The only thing left is to then either provide an existing instance of IServiceProvider (i.e. the Windsor container) or creating an adaptor

public class DataDomainServiceProvider : IServiceProvider

{

    private readonly DataDomain _domain;

    private static readonly MethodInfo member = typeof(DataDomain).GetMethod("New");
    public DataDomainServiceProvider(DataDomain domain)

    {

        _domain = domain;

    }
    public object GetService(Type serviceType)

    {

        return member.MakeGenericMethod(serviceType).Invoke(_domain, null);

    }

}

There's a few things the enterprising mind can do with substitutions and member initialization I can think of, especially around IoC - anyone else have some ideas or thoughts on using/abusing them?

I have to say SharePoint just continues to underwhelm me (as a developer, I don't mind the product itself I should probably make that clear)...

A couple of quick examples:

Configuration over Convention

Regional settings and dates are a prime example - for instance you get a which brings with it a common look and feel for date pickers in SharePoint... and on the various pre-canned forms etc. everything appears to display with the current user/sites regional settings.

However whenever you use this control you end up resorting to code along the lines of:

SPRegionalSettings regionalSettings = SPContext.Current.Web.CurrentUser.RegionalSettings ?? SPContext.Current.Web.RegionalSettings; myDatePickerControl.LocaleId = (int)regionalSettings.LocaleId;

Or extending your control yourself to do the same... why on earth would I not want the control to default to the current regional settings?

Again the lack of convention rears it's ugly head when working with SharePoint's SPGridView - if it's going to a render a date, why doesn't it render it with the current user's Locale in mind (which I've talked about in this  hack last year) - shouldn't these controls be taking that burden of responsibility away from me?

Useless Extensions Points

When something is extensible in SharePoint, then generally:

1. It's not documented (except by the community)
2. It doesn't really work for the most common scenario.

Take the  SPGridView and  SPDataSource combo - with this you can setup a grid to feed
from a CAML query pretty easily ... and it's smart enough to add the required to the underlying CAML query when you sort on a column... so far so good.

But what if you want to sort on more then one column?

Well, you could try specifying more then one column in the grid's SortExpression - but this causes the SPDataSource to spit the dummy... so obviously the first question is why doesn't that work, when it works for other data sources, and would have been trivial
to implement.

But not all hope is lost after opening reflector and perusing the code (which thankfully wasn't obfuscated in this case, though quite a bit of it is) you see that in fact you can specify additional sort columns in the original query and the SPDataSource is smart enough to keep them and insert the new field references into the existing ... a handy way for extending your query to have a number of default sort columns.

But there's a catch, it sticks the entries in the wrong position, so it will sort by the fixed columns first - rather then last - making it all but useless in most cases (users expect to click on a column and see the results sorted by the selected column first) .. And to be honest this still wouldn't worry me if I was given at least one virtual method to override allowing me to mutate the CAML query appropriately.