Jeremy D. Miller -- The Shade Tree Developer

Your chance to heckle me on Ignite your Coding tomorrow

2010-03-18T02:06:00Z

It's my turn next to talk and try to field questions on the new Ignite your Coding podcast tomorrow. It's a little bit different format where you can join the NetMeeting and jump right into the conversation. I'm going to be talking about the whole "Essence vs. Ceremony" discussion and all the ways we can pack more punch with less code. I want to talk about the newer convention based programming techniques that are popping up everywhere in the newer open source projects in .Net, building and using DSL's in the wild, and techniques for "DRY-ing" up your .Net code. I hope you'll tune it, because I'm a vastly better speaker when I'm getting a lot of questions and even backtalk;-)

How to know if you're a coding optimist or pessimist

2010-03-16T01:39:00Z

Let's say you're a developer -- and you probably are if you're reading this. How do you know if you have a generally sunny, optimistic set of mind or a gloomy, pessimistic attitude? It's very simple. You know how you constantly look at 6 month old code and see a better way to rewrite the code? An optimist rewrites that code and says "damn, the new code is so much cleaner!" The pessimist rewrites the old code and says "damn, that old code sure was a mess."

And if you never find any thing wrong with your 6 month old code? You sir are either severely lacking in retrospection and/or you might very well be unconsciously incompetent.

Nice introduction to StructureMap

2010-03-05T16:29:00Z

Using StructureMap and the StructureMap AutoMocking library in the context of MS MVC:

http://blog.jorritsalverda.nl/2010/02/09/maintainable-mvc-series-inversion-of-control-container-structuremap/

StoryTeller Video from Pablo's Fiesta

2010-03-03T15:01:00Z

I meant to write a summary of Pablo's Fiesta, but the will to blog just isn't there anymore. Instead, here's the video from the StoryTeller demo that Weston Binford roped me into. I'm pushing very hard right now toward the StoryTeller 1.0 release. I'm hoping to have it released -- with docs and examples -- by the end of March so I can get on to other things.

A Vision for FubuMVC’s Component Model (gems, Nu, engines, slices, oh my…)

2010-02-25T15:46:00Z

I’m banging this out fast and trying to think out loud. Blame the lack of polish on that previous statement. The whole point of this blog post is to elicit feedback and get ready for Pablo’s Fiesta this weekend (no crazy tax evader can stop the ALT.NET community by merely crashing a plane into the building).

Pablo’s Fiesta starts tomorrow night with the typical Open Spaces agenda creation. Coincidentally, we’ve got several FubuMVC contributors coming into town and we’re going to take advantage of that to carry out some FubuMVC project business. My main concern for the conference is to nail down our component story for FubuMVC. First off, I want FubuMVC to have a fullblown “engine” or “slice” strategy that allows you to build and reuse vertical slices of an application across projects. Secondly, we need an easy way to apply those “engines” to other places. For those of you familiar with Rails and Merb, I’m wanting nothing less than a “gems” like solution for FubuMVC that allows a project team to quickly assemble project infrastructure and share substantial parts of an application architecture with as little friction as possible. Right now, my focus is on the resurrected Nu project as a way to distribute and apply engines to your code tree packaged up as “Nug’s” (the Nu analogue to a gem).

To really make the usage and distribution of FubuMVC “engines” go well, I think we need to do be able to package / discover / distribute the following:

Libraries. One of the things I hear from people is that they just think it’s too hard to piece together OSS tools (it doesn’t matter if you disagree with that statement, because many people *do* feel that way). The very first step is to finally get a decent .Net OSS story around distributing components. I want something like “gems install fluent-nhibernate” that puts the latest released version of Fluent NHibernate into my “tools” directory, and oh yeah, also gets the correct NHibernate binaries with all the little Castle and LinFu pieces that live underneath NHibernate in one go. This is obviously pretty complicated when you think about versioning and dependency trees, but it’s also been done in other development communities and we can take a lot of inspiration from things like gems, Maven, etc.
- We’ll have to effectively agree upon a standard folder layout for external tools so that Nu can scan
- I’m fully aware of HornGet, but I do not see it as the right approach to this problem.
Extensible Command Line tools. We have several command line utilities at Dovetail for our localization subsystem (exporting/importing data, filling in missing localization keys, etc.) that could easily be useful on other projects. Other folks are keen on building “scaffolding” approaches into Fubu Nu is built around extensible command line tools and I think it could be a powerful way to distribute little project utilities as part of an engine/Nug package.
Project Files. I think it’d be nice if when I installed the (not yet existent) “NHibernate QuickKit” engine with Nu and Nu could reach into my *.csproj files and add the right references for me in order to use the NHibernate features. That’s a big can of worms, but I think it could reduce friction in using a lot of tools – especially tools that come with lots of assemblies (I’m looking at you nServiceBus).
Configuration. Your engine could easily require some external configuration. I know one of the first engines I’d like to see is a NHibernate starter kit that would give you a basic NHibernate setup and a simplistic Repository implementation – and NHibernate just doesn’t go without a connection string somewhere. My thought is to standardize FubuMVC on the AppSettingsProvider model that Josh blogged about here.
- When a Nug is installed, maybe it could scan the new imported assemblies and find any new “Settings” classes needed for the new engine. We could have it add the new properties to the appSettings file automatically with any default values. I think this could help to make things like NHibernate integration easier
- The standardized configuration model for things like file paths, Url’s, and connection strings would make it easier to share deployment recipes and infrastructure for staging code through different environments (dev to test to UAT to production).
Services. A slice/engine may easily need to expose other services to the underlying IoC engine. Fubu can only function with an IoC container. It’s been a very important goal to me to ensure that Fubu is IoC tool agnostic (it’s not there yet, too many assumptions about StructureMap runtime characteristics that aren’t necessarily true of the other tools. We’ll get there) and that Fubu makes no restrictions on *how* you can use your IoC tool (many of the “abstract away the IoC tool” strategies do an awful job on this score). You already have some limited ability to register services in FubuRegistry. The FubuRegistry.Include( other registry ) doesn’t merge the service registry yet, but will at some point.
Conventions. Html conventions, behavior policies, Url/Route conventions, View conventions, you name it, all of it is reusable in FubuMVC. I think it’d be nice to say “I wanna use the ‘DataAnnotations’ pack” and just like that, you get Html conventions applied to your project that read metadata off of the DataAnnotation attributes and apply that towards client side jQuery validation. Today this is done with code in a FubuRegistry class to explicitly add conventions.
JavaScript libraries. Look, it’s a rich internet world now and you almost have to use Ajax to create a compelling user experience. There’s the whole jQuery ecosystem with more useful plugins than you can shake a fist at. However, a lot of these plugins (jqGrid comes to mind) require some server side integration to really shine. What if your “Nug’s” could contain both server side functions and custom JavaScript libraries? When you download a Nug, any Javascript libraries will be pushed to where the main Fubu app can find those libraries.
- We have to determine a standard location for the JavaScript files
- We need some sort of script manager piece in FubuMVC.UI that can load them
- Maybe we minify them on demand?
- I think it would be nice if custom Html Helper from external engines could quietly declare behind the scenes that “I need this JS / CSS file” and a <script> tag is added to the page if it isn’t already there
Packaged Views. It would be nice is some engines could include packaged views for things like admin screens. You can do this out of the box by using some sort of embedded views, but it’d probably be nice if we had a good way for an engine installation to copy the view files to a known location where you could modify or skin those views at will (in this case, the reusable view from the engine is mostly just a template).
Warmup / Deployment tools. I’ve always admired things like Capistrano in the Ruby world. If we standardized the FubuMVC code structure, maybe we could reuse project setup, automated build tooling, and deployment recipes across projects the way that Rails developers do. Wouldn’t that be awesome.

Another architectural issue is how the externalized engines are discovered by FubuMVC. Right now, you have to explicitly add things to a FubuRegistry class. I think we also need to consider some sort of dynamic discovery of the external addin’s. It could just be a known folder that we scan at application startup, a partial class in your top level web project that could be auto-generated, an Xml/Json file listing the class names of FubuRegistry types to load as engines or something else I haven’t considered yet. I’m leaning towards the scanning model, but I’m all ears.

The core architectural philosophy of FubuMVC is composition. It’s completely wrapped around IoC service composition, the code basically follows the S.O.L.I.D. ideas for object responsibilities so there’s a lot of seams, and everything is swappable (think “sharp tools”). Conventions can be packaged up and reused across projects. Vertical slices of the application can be packaged and reused across applications by the FubuRegistry concept. The thought right now is to keep a pretty spare core MVC infrastructure in the core assemblies and add additional UI magic in external assemblies that can be optionally added into your project. The Html conventions feature was already developed in this way. In the next 3-4 months I know where adding new facilities for localization, validation, and some more Html conventions on top of those things – but none of it will come out of the box. The “tinker toy” approach gives us a huge advantage in being able to adapt FubuMVC for totally new scenarios and reuse code and avoid the original Rails problem of “use my opinions or go home,” but…

How the bleep is the average team going to be able to assemble all these little pieces and get them to work together without losing all their hair?

My personal goal for FubuMVC is to get that question answered – and I’m hoping that Pablo’s Fiesta moves the conversation.

Preview of the new StoryTeller Test Editor -- Looking for Feedback

2010-02-19T14:35:00Z

EDIT: 9:40 AM CST -- fixed the download. Missed one absolute path hiding at the bottom of the page. Sorry about that.

In November I made a post about rewriting the StoryTeller test editor (because the current one is an embarassment) in which I wondered out loud about whether to do the rewrite in Javascript against an HTML DOM or try again in WPF. Opinions were mixed, but I already had a working proof of concept for the Javascript/HTML model from Dovetail's rules engine so I went in that direction. I did most of it the day after Thanksgiving, but put it aside until just the past week. Here's a zip file with everything you need to play around with the new test editor. Just unzip it, and open the Editor.htm file. There's a dropdown box at the top that gives you the ability to open up one of about 2 dozen sample tests I use in testing. Admittedly, I haven't tried this thing on IE (shame on me), but it's running like a champ on Firefox 3.6. If you see any wonkiness after switching tests, just reload the page.

It isn't finished yet, but it can happily open up StoryTeller tests with every type of grammar and fixture mode and edit them. I still have to apply:

Validation (using jQuery validation)
Ordering via dragging (again more jQuery goodness)
"IsDirty" checking
More styling I'm sure

I'd really like some feedback on both the look and feel plus the usability aspects of the test editor.

My thought is that this test editor will be embedded inside the StoryTeller WPF client as just a screen. It's also my thought that this could be adapted a little bit down the road as a way to host a StoryTeller DSL editor within a web application. As if I didn't have enough on my plate already, I'm very serious about pushing StoryTeller as a tool for creating external DSL's in .Net as well as being the FitNesse killer for .Net.

Our “Extension Properties” Story

2010-02-16T14:51:00Z

Late last year I made myself a promise that I would resuscitate my blog instead of just tweeting drivel. I don’t particularly feel up (or self important enough) to the old 10 page missives of yore, so I’m just going to write about the project and OSS work I’m doing this year and see if any of it is useful or interesting.

I’ve built software in some capacity for a dozen years. My first couple projects were exciting just because it was my first couple projects, but for the most part, I’ve always felt like everybody else worked on cooler projects than I did – until I started at Dovetail anyway. Yesterday I (mostly) wrapped up a crucial subsystem for us on our story for “extension properties that I thought was cool enough to share.

We know from experience that our customers need to add some of their own fields to track their own special data in the system. Here’s the facts, requirements, and assumptions we’ve made about these extension properties:

We’re assuming that the extension properties will be completely set up by our professional services folks during the deployment product, so we don’t have to open up any magic way for the customers to change the database schema and screens on the fly.
Our “professional services” guys sit 10 feet from me and they’re perfectly capable of some coding
We really need an “Open / Closed” architecture. By this I mean that we absolutely must be able to add these customer specific properties to their own installation without any impact or change to our core codebase. Nothing destroys a small ISV like having to maintain customer specific
The extension properties have to be editable on the screen
The extension properties have to be available inside our rules engine
I’d really, really like to reuse all our existing infrastructure for validation, persistence, and html conventions for these extension properties. I’m lazy and I don’t want to write a lot of special infrastructure.

Step 1: Adding Extends<T> to the Domain Model

My original thought was to just make the extension properties live in a name/value collection on all of our entities. It’s a simple solution and the quickie NHibernate spike I did made it clear that the persistence wouldn’t be a problem. However, we make use of a *lot* of conventions and validation policies in our application that utilize the type system and our validation attributes to drive behavior. Using the name/value approach meant that I threw all that away. Instead, I decided that the extension properties would just live in a separate class like this one that I use for testing:

    // This object would be attached to our 
    // Site objects in our Domain Model
    public class SiteExtensions : Extends<Site>
    {
        [Required, ShowNew]
        public string ExtraString { get; set; }
        public int ExtraNumber { get; set; }
        public DateTime? ExtraDate { get; set; }
 
        // Fake property and a fake list I use to test
        // multi-level lists
        [ListValue("Year"), ShowNew]
        public string Year { get; set; }
 
        [ListValue("Make"), ShowNew]
        public string Make { get; set; }
 
        [ListValue("Model"), ShowNew]
        public string Model { get; set; }
    }

A couple notes about this class. As you see, it inherits from the Extends<TEntity> class where TEntity is the type in our domain model that is being extended. Extends<TEntity> is strictly a marker interface with no functionality.

    public class Extends<T> where T : DomainEntity
    {
    }

You might also notice that the SiteExtensions class is decorated with several attributes (Required, ShowNew, ListValue, etc.). These attributes are mostly for our server side validation, but they also drive Html construction in the web pages and tie into client side validation with jQuery validation (more on this later).

Step 2: Discovering Extension Properties on Application Startup

So far, so good, but now I need to hook the SiteExtensions objects to Site objects while keeping the SiteExtensions class in a totally separate assembly specific to that particular customer. First, all of our domain model classes implement a layer supertype class called “DomainEntity,” so this becomes a natural way to connect our domain entities to their extension properties:

    [Serializable]
    public class DomainEntity : Entity, IValidated
    {
        public object ExtendedProperties { get; set; }
 
    }

Next, I need to discover the proper extension property class for each domain model type (if any) at runtime. I decided to store that information in a simple static class called “ExtensionProperties” that acts as a well known place in the system to query for the proper type of extension class:

    public static class ExtensionProperties
    {
        private static readonly Cache<Type, Type> _types = new Cache<Type, Type>();
 
        public static void Register(Type entityType, Type extensionType)
        {
            _types[entityType] = extensionType;
        }
 
        public static void ClearAll()
        {
            _types.ClearAll();
        }
 
        public static bool HasExtensionFor(Type entityType)
        {
            return _types.Has(entityType);
        }
 
        public static Type ExtensionFor(Type type)
        {
            return _types[type];
        }
    }

Now that we’ve got ExtensionProperties, we need to discover the available extension properties at application startup and register them with ExtensionProperties. Unsurprisingly, I used StructureMap to discover the extension property types. First off, we’re doing customer extensions by placing their customizations in separate assemblies that are placed into our application bin. At the moment, our convention is that these assemblies must contain “Extensions” somewhere in their assembly name to be picked up. So knowing that assumption, I created an auto-registration policy in StructureMap that scans all the “Extensions” assemblies in our application base directory and discovers the Extends<T> types:

    public class ExtensionRegistry : Registry
    {
        public ExtensionRegistry()
        {
            Scan(x =>
            {
                ExtensionProperties.ClearAll();
                x.AssembliesFromApplicationBaseDirectory(assem => assem.GetName().Name.Contains("Extensions"));
                x.Convention<ExtensionScanner>();
            });
        }
    }
 
    // This little guy just finds any type that inherits from
    // Extends<T> and registers that type against "T" in 
    // our wellknown ExtensionProperties class
    public class ExtensionScanner : IRegistrationConvention
    {
        public void Process(Type type, Registry graph)
        {
            if (type.BaseType.IsGenericType && type.BaseType.GetGenericTypeDefinition() == typeof (Extends<>))
            {
                var entityType = type.BaseType.GetGenericArguments()[0];
                ExtensionProperties.Register(entityType, type);
            }
        }
    }

Step 3: Persisting the little devils

The goal is definitely to make the properties on the extension classes persistent, and I’d really prefer not to write custom SQL for this one off need, so it’s time to teach NHibernate how to persist these extension types – if they exist. The Extends<T> objects are really just part of the domain entity that they extend, so let’s just say we put the backing fields directly onto the proper table for each entity. We *might* have a conflict with the extension properties and later versions of our product, so let’s make a little naming convention for these backing fields and say that all extension fields in the database have to be prepended with “x_” like this (yes kids, I *can* write Sql by hand if I absolutely have to):

BEGIN TRANSACTION
GO
ALTER TABLE dbo.Site ADD
    x_ExtraString nvarchar(50) NULL,
    x_ExtraNumber int NULL,
    x_ExtraDate datetime NULL,
        x_Year nvarchar(20) NULL,
        x_Make nvarchar(50) NULL,
        x_Model nvarchar(100) NULL
 
COMMIT

Now I need to alter our NHibernate mappings *if* a domain entity has an extension type attached to it. Back in the bad old HBM.XML days this used to be a klooge, but Fluent NHibernate (FNH) made it very simple. Let’s just treat the Extends<T> type as a “Component” on the main entity type. We have our own base class that extends FNH’s ClassMap<T> called DomainMap<T> to specify NHibernate mappings with our own policies, so let’s just add a bit of code to that base class that will dynamically create a component mapping to the extension property type if it exists:

    public abstract class DomainMap<T> : ClassMap<T>, IDomainMap where T : DomainEntity
    {
        protected DomainMap()
        {
            // For every DomainEntity class, use the Id property
            // as the Primary Key / Object Identifier
            Id(x => x.Id).ColumnName("id").GeneratedBy.GuidComb();
            WithTable(typeof(T).Name);
            Map(x => x.LastModified);
            Map(x => x.Created);
 
            if (ExtensionProperties.HasExtensionFor(typeof(T)))
            {
                var componentType = typeof (ExtensionComponent<>)
                    .MakeGenericType(ExtensionProperties.ExtensionFor(typeof (T)));
 
                var component = Activator.CreateInstance(componentType) as IMappingPart;
                AddPart(component);
            }
        }
    }
 
 
    public class ExtensionComponent<T> : ComponentPart<T>
    {
        public ExtensionComponent()
            : base(ReflectionHelper.GetProperty<DomainEntity>(x => x.ExtendedProperties), false)
        {
            SetAttribute("class", typeof(T).AssemblyQualifiedName);
 
            // Assume that all properties are persistable
            typeof(T).GetProperties()
                .Where(x => x.DeclaringType == typeof(T))
                .Each(prop =>
                {
                    // See the "x_" prefix for the naming convention?
                    Map(prop, "x_" + prop.Name);
                });
        }
    }

The awesome thing about using an “internal DSL” like that in Fluent NHibernate is that you still have every single bit of the real language at your disposal. The code above effectively extends our NHibernate mapping to persist all the properties of the Extends<T> objects whenever the host entity is persisted. By doing this we largely make the extension property persistence transparent to the main code.

Step 3: Validating the Extension Properties

This part is actually pretty simple, but it doesn’t really translate all that well to other codebases. For validation we use a homegrown mini-framework I built years ago that lives (largely abandoned) in the ShadeTree repository on Google Code (it hasn’t changed a lot since this post on the Notification pattern). This tooling allows you to mix validation between attributes and special methods on a Domain Entity. Going back to our DomainEntity supertype, we make it implement the ShadeTree “IValidated” interface and in the single Validate(Notification) method, we do a transparent pass through to validate the extension properties:

    [Serializable]
    public class DomainEntity : Entity, IValidated
    {
 
        public virtual void Validate(Notification notification)
        {
            if (ExtendedProperties == null) return;
 
            Validator.ValidateObject(ExtendedProperties, notification);
        }
 
        public object ExtendedProperties { get; set; }
 
    }

Not really much to this. Your mechanics will be different for other validation frameworks, but the principle is still the same. Just validate the extension property object if it exists and add those messages to whatever your framework uses for its Notification.

Step 4: Putting this stuff on the screen

Most of our online forms present the main fields in a pretty standard 2 column layout. For the moment, we’re trying to get away with just adding any extension properties to the bottom of the two columns and hope that’s good enough for most clients. Once Chad and I made that assumption I moved onto making a new Html helper that would dynamically add the labels and editable fields for any extension properties:

    <%=this.ExtensionFieldsForView()%>

This helper needs to discover the proper extension type, if any, and write a label/field pair for each property it discovers on that extension object:

        // Discover what extension type, if any, is valid for the ViewModel of this page
        public static HtmlTag ExtensionFieldsForView<TViewModel>(this IDovetailViewWithModel<TViewModel> view) where TViewModel : class
        {
            var form = buildFormFor(view);
            var entityModel = view.Model as EditEntityModel;
            return form == null ? HtmlTag.Empty() : form.WriteView(entityModel.Target);
        }
 
        private static IExtensionForm buildFormFor<TViewModel>(IDovetailViewWithModel<TViewModel> view) where TViewModel : class
        {
            var editModel = view.Model as EditEntityModel;
            if (editModel == null) return null;
 
            var entityType = editModel.EntityType;
            if (!ExtensionProperties.HasExtensionFor(entityType)) return null;
 
 
            // The Form "magic" happens in ExtensionForm<,>
            var extensionType = ExtensionProperties.ExtensionFor(entityType);
            var extenderFormType = typeof(ExtensionForm<,>).MakeGenericType(extensionType, entityType);
 
            return (IExtensionForm)view.Container.GetInstance(extenderFormType);
        }

One of my goals with the extension properties was to utilize our existing infrastructure for Html generation. We have a large investment in the FubuMVC Html conventions and it makes our form creation quick and consistent. In order to use the Html conventions with our extension properties, I use this utility class to mediate between the dynamically discovered extension properties and the Fubu Html conventions:

    public interface IExtensionForm
    {
        HtmlTag WriteNew();
        HtmlTag WriteView(DomainEntity entity);
    }
 
    public class ExtensionForm<T, TEntity> : IExtensionForm where T : Extends<TEntity>, new() where TEntity : DomainEntity
    {
        private readonly TagGenerator<T> _tags;
 
        public ExtensionForm(TagGenerator<T> tags)
        {
            _tags = tags;
 
            // This is consistent w/ our naming convention
            _tags.ElementPrefix = typeof (TEntity).Name;
        }
 
        private HtmlTag writeFields(string profileName, IEnumerable<PropertyInfo> properties)
        {
            _tags.SetProfile(profileName);
            return new HtmlTag("dl", x =>
            {
                x.AddClass("details");
 
                properties.Each(prop =>
                {
                    x.Add("dt").Text(LocalizationManager.GetHeader(prop));
 
                    var request = _tags.GetRequest(new FubuMVC.Core.Util.SingleProperty(prop));
                    HtmlTag inputTag = _tags.InputFor(request);
                    x.Add("dd").Child(inputTag);
                });
            });
        }
 
        public HtmlTag WriteNew()
        {
            _tags.Model = new T();
            return writeFields(TagProfile.DEFAULT, ExtensionFieldRegistry.NewProperties<T>());
        } 
 
        public HtmlTag WriteView(DomainEntity entity)
        {
            _tags.Model = (T) entity.ExtendedProperties ?? new T();
            return writeFields(DovetailViewActivator.EDIT_PROFILE, ExtensionFieldRegistry.ViewProperties<T>());
        }
    }

TagGenerator<T> is the main service in FubuMVC.UI for generating HtmlTag’s by convention. As you can probably surmise from the code above, our localization machinery can lookup the header name for a PropertyInfo (or Expression) and that’s how we build the labels. The actual editor tag is completely generated by the FubuMVC machinery based on its policies that we’ve configured:

    public class DovetailHtmlConventions : HtmlConventionRegistry
    {
        public DovetailHtmlConventions()
        {
            validationAttributes();
            numbers();
            dates();
 
            Editors.Builder<ListValueDropdownBuilder>();
 
            Editors.IfPropertyIs<bool>().BuildBy(request => new CheckboxTag(request.Value<bool>())
                .Style("width", "auto !important")
                .Attr("value", request.ElementId));
 
            Editors.Always.Modify((request, tag) =>
            {
                tag.Attr("label", request.Header());
                tag.Attr("name", request.ElementId);
            });
        }
 
        private void numbers()
        {
            Editors.IfPropertyIs<Int32>().Attr("max", Int32.MaxValue);
            Editors.IfPropertyIs<Int16>().Attr("max", Int16.MaxValue);
            Editors.IfPropertyIs<Int64>().Attr("max", Int64.MaxValue);
            Editors.IfPropertyTypeIs(t => t.IsIntegerBased()).AddClass("integer");
            Editors.IfPropertyTypeIs(t => t.IsFloatingPoint()).AddClass("number");
        }
 
        private void dates()
        {
            Editors.IfPropertyTypeIs(t => t.IsDateTime()).Modify(x =>
            {
                if (!x.HasMetaData(EditInPlaceBuilder.EDITABLE_ATTRIBUTE_NAME))
                {
                    x.AddClass("DatePicker");
                }
            });
            Editors.If(prop => prop.Accessor.InnerProperty.IsDateAndTime()).Modify(x =>
            {
                if (!x.HasMetaData(EditInPlaceBuilder.EDITABLE_ATTRIBUTE_NAME))
                {
                    x.AddClass("time-picker");
                }
            });
        }
 
        private void validationAttributes()
        {
            Editors.AddClassForAttribute<RequiredAttribute>("required");
            Editors.ModifyForAttribute<MaximumStringLengthAttribute>((tag, att) =>
            {
                if (att.Length < Entity.UnboundedStringLength)
                {
                    tag.Attr("maxlength", att.Length);
                }
            });
 
 
            Editors.ModifyForAttribute<GreaterOrEqualToZeroAttribute>(tag => tag.Attr("min", 0));
            Editors.ModifyForAttribute<GreaterThanZeroAttribute>(tag => tag.Attr("min", 1));
        }
    }

And of course, by using the normal Html conventions to build the Html input tags, we get the jQuery validation integration for our extension properties.

Oh, and because Reflection scanning can be expensive, we cache the PropertyInfo’s for each extension type:

    public static class ExtensionFieldRegistry
    {
        private static readonly Cache<Type, IEnumerable<PropertyInfo>> _newProps
            = new Cache<Type,IEnumerable<PropertyInfo>>(findNewProps);
 
        private static readonly Cache<Type, IEnumerable<PropertyInfo>> _viewProps
            = new Cache<Type,IEnumerable<PropertyInfo>>(findViewProps);
 
        private static IEnumerable<PropertyInfo> findNewProps(Type type)
        {
            return type.GetProperties().Where(x => x.DeclaringType == type && x.HasAttribute<ShowNewAttribute>());
        }
 
        private static IEnumerable<PropertyInfo> findViewProps(Type type)
        {
            return type.GetProperties().Where(x => x.DeclaringType == type);
        }
 
        public static IEnumerable<PropertyInfo> NewProperties<T>()
        {
            return _newProps[typeof (T)];
        }
 
        public static IEnumerable<PropertyInfo> ViewProperties<T>()
        {
            return _viewProps[typeof (T)];
        }
    }

Step 5: Getting data from the browser to the server

One more step (we also do edit in place editing of the extension properties in the UI, but that code is a mess and I’m not showing it to anyone until it’s cleaner). We have the html tags on the browser and NHibernate knows how to persist the fields. All we have to do now is get the data from the browser and marshal it into the new extension property type on the server. The ViewModels for submitting the “new” forms all inherit from this base type that, conveniently enough, has a property for the extension properties:

    public class UpdateEntityModel<T> : IItemRequest where T : DomainEntity
    {
        public Extends<T> ExtendedProperties { get; set; }
        public Guid Id{ get; set; }
    }

I’m omitting some (lots) of code here, but I used an extension point on FubuMVC’s model binding to “fill” that ExtendedProperties property above with this code:

    public class ExtensionPropertyBinder : IPropertyBinder
    {
        // This only applies to properties that close Extends<>
        public bool Matches(PropertyInfo property)
        {
            return property.PropertyType.Closes(typeof (Extends<>));
        }
 
        public void Bind(PropertyInfo property, IBindingContext context)
        {
            var entityType = property.PropertyType.GetGenericArguments()[0];
 
            // If there is no Extends<> for the entity type, do nothing
            if (!ExtensionProperties.HasExtensionFor(entityType))
            {
                return;
            }
 
            var extensionType = ExtensionProperties.ExtensionFor(entityType);
 
            // direct the FubuMVC model binding to resolve an object of the
            // extensionType using "entityType.Name" as the prefix on the form data,
            // and place the newly created object using the specified property
            context.BindChild(property, extensionType, entityType.Name);
        }
    }

Wrapping Up

We’ll see how it goes in the end, but I’m relatively happy with how it all turned out. The end result is that we can just build a very simple class with properties and some attribute declarations, put that assembly in the right spot, and voila!, the right stuff appears on the screen.

Lots of stuff to throw at you, but I’ll try to answer any questions.

Wanna see how Dovetail builds software (or not, it's a free country)?

2010-02-13T03:41:00Z

Chad Myers and I are more or less volunteering to put on a 4 hour session at the 2010 Austin Code Camp (for a variety of reasons this is the first time I've been to it since '06) just presenting an insider's look at some of the project work we're doing in the spirit of our "Opinionated MVC" talk from KaizenConf in '08. We can talk about almost anything but actual business logic, but here's the topics I'm thinking of:

Dovetail's "rules engine." We have a custom rules engine built on the standard Event - Condition - Action pattern that works against our domain model. The E-C-A parts are all composed with StructureMap and the rules configuration is done by an external DSL editor that presents a near English experience for users. It's also very extensible for those pesky customer customizations down the road. I think this is the most challenging project I've ever done by far. Oh, and we can add new "Condition's" and "Action's" to both the engine and DSL without changing one single line in our core Dovetail code. How 'bout them apples?
How we use StoryTeller and Selenium to do automated web testing. Lots of challenges and lessons learned to make testing go faster and be less brittle in an Ajax heavy site.
Using FubuMVC. How it really plays out. Using the Html conventions to really go fast and kill repetitive coding -- and it goes way beyond what anything in MSMVC2 is capable of w/o heavy gymnastics. Advanced model binding. How we get eliminate the "tag soup" problem in our views.
Tying jQuery together with server side conventions and Html helpers. A lot of the pizzazz of jQuery is only unleashed when you combine it with your server side Html generation.
Our "ActionRouter" / Continuation model for some Ajax handling. It's a cool little sample of making an internal DSL pay off dividends
Convention over Configuration from our Domain Model back to the database and forward to the UI
Extension properties. We have a need in our application to allow customers (or really our professional services folks) to add new properties to our system and capture this data on the screen with fullblown validation and edit in place functionality without touching our core code. Lots of Fluent NHibernate and FubuMVC trickery to make it work.

Anything you want to hear about? We'll get it filmed and posted on Viddler or something similar.

Introducing the "Ignite Your Coding!" Podcast

2010-02-10T21:36:00Z

I enjoy the better software podcasts out there, but there aren't really enough good ones out there and some of them would really be better if they contained a little more element of conversation and even debate once in awhile instead of being just a straight forward presentation from the guest. I'm really looking forward to see what those crazy Canucks get up to with the new Ignite Your Coding podcast starting up soon. The guest list and schedule looks pretty good, but the most intriguing thing to me is the interactive nature of the webcast format where listeners can ask questions live. The very first episode is going to be Andy Hunt of Pragmatic Programmer fame with Uncle Bob and several CodeBetter members in between.

You can find more information from Joey Devilla's blog post kicking it off.

I'll be on it March 18th. If you absolutely feel like you need to write what you'd like me to discuss in the comments below, I guess that'd be (very helpful) okay.

“Nested Containers” in StructureMap 2.6.1

2010-02-10T05:36:00Z

This is the first of a promised series of blog posts to explain and demonstrate the new features of the StructureMap 2.6 release. First, in order to use this feature, you absolutely must be on StructureMap 2.6.1 (or 2.5.4). Your friendly neighborhood Shade Tree Developer introduced a bug into the 2.6.0 codebase that makes this feature screw up the parent container (mea culpa).

I want to start with the new “Nested Container” feature. In a nutshell, the Nested Container is kind of like a temporary clone of a Container that’s invoked like this:

            // Let's just say that ObjectFactory.Initialize() has already been
            // called so the main Container is already built and ready
            // to use
            using (IContainer nested = ObjectFactory.Container.GetNestedContainer())
            {
                // pull other objects from the nested
                // container and do work with those services
                var service = nested.GetInstance<IService>();
                service.DoSomething();
            }

What did I do up above? I simply created a new Container (nested) from an existing Container, then pulled a service from the new nested container, did some work with it, then let the C# “using” block auto magically call the Dispose() method on the new nested container object. You might be asking, why do I need a second Container? Well, the nested container has some special properties:

The nested container will track all of the transient objects that it creates. When the nested container itself is disposed, it will call Dispose() on any of the transient objects that it created. A normal StructureMap Container does not track the transient objects that it creates (and nor should it IMHO).
The nested container “pulls” all instances scoped as anything but transients (Singletons, HttpContext scoped objects, ThreadLocalStorage scoped objects, etc.) from the parent container. These objects are not disposed from the nested container.
“Transient” objects are scoped to the nested container. I’d try to explain that, but why don’t I just show the unit test instead:

        [Test]
        public void transient_service_in_the_parent_container_is_effectively_a_singleton_for_the_nested_container()
        {
            var parent = new Container(x =>
            {
                // IWidget is a "transient"
                x.For<IWidget>().Use<AWidget>();
            });
 
            IContainer child = parent.GetNestedContainer();
 
            var childWidget1 = child.GetInstance<IWidget>();
            var childWidget2 = child.GetInstance<IWidget>();
            var childWidget3 = child.GetInstance<IWidget>();
 
            var parentWidget = parent.GetInstance<IWidget>();
 
            childWidget1.ShouldBeTheSameAs(childWidget2);
            childWidget1.ShouldBeTheSameAs(childWidget3);
            childWidget1.ShouldNotBeTheSameAs(parentWidget);
        }

It’s not the most exciting thing in the world, but it’s helpful in some specific scenarios:

Web requests. Inside a single web request I need every object to access the exact same NHibernate ISession instance (substitute the analogue in your persistence tooling of choice). At the end of the web request I may want to tear down and dispose all the services created during that web request – i.e. make damn sure the database connection is closed and cleaned up at the end. I’m not exactly sure how you would use this in ASP.Net MVC (not saying you can’t, just that I haven’t given it much thought), but it’s working out very well for us with a FubuMVC Behavior like I showed here.
Short lived atomic transactions. We use the nested container within our rules engine. Within a single NHibernate ISession and transaction block, we create several object graphs with service location calls to the nested container.* Using the nested container feature made it much simpler for us to “scope” the ISession and even rules state objects within a logical transaction.
User Interface composition. From a twitter conversation with Glenn Block a couple weeks back. Let’s say that you have a distinct area of the UI where you have a long running workflow like a wizard that replaces the controls and Presenters / ViewModels currently active. When those Views, ViewModel’s, and Presenters are created, you probably want those objects to have shared state and layout “region manager” type classes injected into them. Using a nested container for the wizard is “a” way to build those objects with the proper shared services.

Sample Usage

Most of our nested container usage is wrapped up within the class shown below:

    public class TransactionProcessor : ITransactionProcessor
    {
        private readonly object _locker = new object();
        private IContainer _container;
 
        // This IContainer is the parent container from
        // ObjectFactory.Container
        public TransactionProcessor(IContainer container)
        {
            _container = container;
        }
 
        public void Execute<T>(Action<T> action)
        {
            execute(c =>
            {
                var service = c.GetInstance<T>();
                action(service);
            });
        }
 
 
        // This code is used in our codebase as a generic way to invoke
        // a service or action within the scope of a nested container
        private void execute(Action<IContainer> action)
        {
            IContainer container = null;
            lock (_locker)
            {
                container = _container;
            }
 
            // ITransactionBoundary is a Dovetail specific interface / class
            // we use just to manage an NHibernate ISession object
            using (IContainer nestedContainer = container.GetNestedContainer())
            {
                var boundary = nestedContainer.GetInstance<ITransactionBoundary>();
                boundary.Start();
                action(nestedContainer);
                boundary.Commit();
            }
        }
    }

In real usage, we invoke services within a transaction with code like this:

            var transaction = ObjectFactory.GetInstance<ITransactionProcessor>();
            transaction.Execute<DataDriver>(x => x.ClearData());

* Some of you are going to read that sentence and do a kneejerk “…but Ayende says you’re only supposed to do one service locator call in the entire application!” Don’t do the kneejerk thing without understanding the context.

More signs of FubuMVC getting real

2010-02-09T14:52:00Z

Just launched last night: http://guides.fubumvc.com/. The main page has been around for a couple weeks now at http://fubumvc.com/.

It's not that much yet, but I think the existence of *any* documentation at this point is a good indication that we're serious about making the FubuMVC reboot take off.

If you're interested in getting involved, there's a TODO list that Chad & I are trying to keep up with ideas for extending FubuMVC at http://wiki.fubumvc.com/TODO and the developers list is at http://groups.google.com/group/fubumvc-devel.

StructureMap 2.6 (and 2.5.4) is Released!

2010-02-04T15:14:00Z

Time flies when you’re having fun. It’s been almost a year since I’ve made an official StructureMap release, so I guess it’s about time. This morning I uploaded the binaries for the 2.6 release. This release just adds some bug fixes and a couple minor additions to the 2.5.4 release that I made in December but didn’t really publicize. The release notes below are long, but that’s because they represent almost a year’s worth of development. As I said yesterday, StructureMap is most likely moving to GitHub with the documentation going as well. After a massive effort to write documentation early last year, huge chunks of it is already obsolete and there’s been a lot of addition since. I’m hoping that the move to the Wiki will make it easier to keep the docs up. In the meantime, I’ll try to blog a bit about the newer pieces starting tomorrow.

A tiny bit of history. This is the 11th StructureMap release since it debuted way back in June of 2004. Almost nothing is the same. We use it differently, the expectations are different, and very, very little of the original code survives today. At QCon San Francisco in 2008 I talked about what I’d learned from evolving this codebase over so many years and changes.

This release includes a lot of patches from the community, and I’d like to thank all of you for that – especially Frank Quednau and Andreas Ohlund for taking on some nastier things. Josh and Kevin Miller do yeoman duty answering StackOverflow questions (so I don’t have to).

What’s Changed?

New terse, “jQuery-esque” syntax for the Registry DSL. Let’s just write off “ForRequestedType<IFoo>().TheDefault.Is.OfConcreteType<Foo>()” as a well meant experiment, shall we? It’s still in the codebase, but it’s marked as [Obsolete]. Nobody liked it and I thought it was annoying in real life usage. Now, just do: For<IFoo>().Use<Foo>(); My whole goal was to reduce friction. Needs a big blog post
Changed the Registry DSL to make inline dependency configuration be more consistent. Definitely a blog post.
The “CreateProfile” syntax has gotten a lot of complaints for being inconsistent with the rest of the Registry DSL. I basically rewrote it to now be consistent with the “For<>().Use()” syntax in the main Registry DSL. Blog post coming soon….
Nested Container feature for short lived transactional requests. I built this for Dovetail usage, but I think it’s my preferred way to manage object scoping in certain circumstances. I mentioned it just a little bit in my NHibernate w/ StructureMap post a couple weeks back. Blog post coming soon…
The “Model” feature was completely redone. There’s a lot more power, and you can use it to pull services out of the Container and completely remove services from the Container as well. Sigh. Needs a blog post.
Convention based type registration got a lot of work. People are pushing this feature very hard and it had to grow. You can now use the Registry DSL to write conventions. This was improved farther in the latest code drop. Yeah, blog post coming…
Better support for registering services by Type objects for cases when you don’t necessarily know the Type upfront. Big request from several framework authors like Caliburn.
A helluva lot of new features to make working with open generic types easier. Jimmy Bogard blogged about some of it here. I’d like to show how StructureMap’s new features would make writing something like Davy Brion’s Agatha framework a snap. I use this stuff extensively inside of StoryTeller.
Added the lazy Func<T> feature from Autofac. A really great (and cheap) way to support lazily initialized components. Blog post coming.
Completely ditched all Reflection.Emit code. StructureMap now strictly uses dynamically constructed Expression’s that are pre-compiled into cached Func’s. I don’t know if that really makes much difference to users, but it makes StructureMap much, much easier to extend. The container does spin up faster with this mechanism. Makes me happy.
Supports IList<T> and List<T> arguments. It works just like Arrays. That’s been a while coming.
You can set the lifecycle from <AddInstance> if you happen to still use Xml configuration.
The “Lifecycle” code was completely reworked to eliminate shared code
Container.Dispose() was introduced. I’ve put a lot of effort into making StructureMap clean up after itself. Definitely a blog post coming.
ObjectFactory.Container. Slowly, but surely, I’d like to wean people away from using ObjectFactory too much in favor of scoped Container objects. I will NOT be further extending the ObjectFactory static methods to synchronize it with IContainer. Instead, I’m just exposing the ObjectFactory.Container property.
New abilities for IContext like BuildUp() (thanks to Kyle Malloy), getting all instances, and TryGetInstance
TryGetInstance() from Josh
Killed StructureMapConfiguration. Good riddance.
“Forwarding” requests for IFoo to whatever IBar is

Getting StructureMap off SourceForge, Thoughts?

2010-02-03T22:29:00Z

The original discussion for this topic is here: http://groups.google.com/group/structuremap-users/browse_thread/thread/6d579f4e9b508c66

All,

I've never liked SourceForge and it's a PITA for me to use even though it's gotten better over the years. I'd like
to move StructureMap off SourceForge and more importantly, get a real
Wiki site up so that we have at least a fighting chance of keeping the
documentation up to date. On the other hand, I get a significant
number of patches from you guys (thanks for that) and I'd also like a
better way of handling those submissions -- and making it easier for
*you* to get involved.

Right now, Josh and I are thinking about moving StructureMap to GitHub
(you knew that was coming) and trying to use the Wiki support on
Github for now. Granted, Git is weird as hell for those of us used to
SVN, but GitHub has some huge advantages for OSS community
development. I'd *love* to start managing StructureMap patches
through GitHub "pull" requests (or whatever the correct lingo is).

Any thoughts? Volunteers? ;)

Jeremy

FubuMVC Learns to Speak Spark

2010-02-02T17:59:00Z

From Robert the Grey, FubuMVC learns to speak Spark.

I've done the nearly solo OSS thing a couple times to mixed results. I'm painfully aware that good OSS projects have a deeper community of contributors than just one guy, and that's why I'm so thrilled to see this addition come into the nascent FubuMVC reboot from outside the Dovetail office.

Dovetail is Hiring

2010-01-29T21:17:00Z

This is a different project than the one we hired for last time. If you've spoken to us before, please consider this position separately.

We're expanding the development team on our line of existing products. You'll be working on a small team that develops applications for large businesses using some of the latest technology. You will be involved in all aspects of solution development, including analysis, design, development, testing, documentation, and support.

We’re looking for a software developer with demonstrable C# (preferably .NET 2.0 or later) and HTML/CSS experience (ASP.NET MVC is a plus). Any experience with test-driven development or automated unit testing in general is a huge plus. Also, participation in the community (attendance of events, avid blog reader + commenter, or maybe you even have a blog yourself) will put you firmly in the running for this position. We’re looking for people that believe learning and continuous improvement are primary responsibilities of a software developer. We’re hiring motivated people for a terrific opportunity with a team of recognized .NET and agile community leaders.

Our practices and technologies include:

Test-driven development
Continuous integration
Behavior-driven design
Domain-driven design
HTML, CSS, Javascript (jQuery)
ASP .NET MVC
C# 3.0, .NET 3.5, Visual Studio 2008
SQL 2008
Oracle
NHibernate 2.x
StructureMap

Email us and tell us why you’d make a great addition to our team: tech-jobs@dovetailsoftware.com

This is a full-time, on-site position in our Austin, TX office. Please DO NOT contact us for outsourcing or tele-commuting.