JSON update, MonoRail musings

Well, the path expression bits I grafted on to Json.NET are now relatively functional, although in terms of code quality, not much to write home about. I added a rule that says, basically, if the first call is “include” then the mode is “exclude by default” and vice versa. My MonoRail controllers currently use the serializer like so:


where “list” is an enumerable of something that holds a reference to a Foo. The resulting JSON looks something like this:

[{Foo: {Id: 1}}, {Foo: {Id: 2}}]

“Json” is a property that holds a “JsonRenderer” which is just a helper that holds a reference to both the serializer and the controller, so we can append the Render() call there.

All in all I’m pretty pleased with this, because it gives me fine-grained control over serialization, and I can nix the dependency between my domain model and Json.NET (which existed purely because I used JsonIgnoreAttribute on a couple of domain classes).

(As for any aspirations to release my changes — I haven’t had the opportunity to ask for a permission, and to be honest, the overall quality of the extension is “good enough for me” but I’d rather not show it to anyone else just yet. 🙂 Once I’m done with the important bits — that is, the application itself — I might try wrapping them up in a form that leaves the original serializer untouched.)

After managing to simplify the serialization, I noticed that a big part of my controller code looks like this:

public void SomeMethod(long fooId)
 Foo foo = FooDAO.Get(fooId);
 // ...

so I figured I should probably do something about that, too. Fortunately, writing a custom data binder for MonoRail is fairly painless.

Now, the same code would look like this:

public void SomeMethod([DAODataBind] Foo foo)

The binder by default looks for an id parameter, the name is determined by the parameter name so “foo” is looked up based on “fooId”. The attribute has a second form, [DAODataBind(“fooBarId”)] which uses the parameter “fooBarId” instead.

The implementation is a bit of Reflection voodoo. First, we use the supplied ParameterInfo to find out the type of the parameter. If it’s not one of our domain model classes, tough luck, but I have a nice exception for you. Next, we dig up the appropriate DAO from our DAOFactory which comes with a handy GetDAO(Type t) method. Finally we invoke the Get method of the DAO with the id parameter, and return the retrieved object.

Surprisingly enough, that worked very nearly on the first try — I made some assumptions about Type.GetMethod(), mostly the BindingFlags that I’d have to use, but once that was sorted out it worked like a champ.

Overall I’m impressed of how easy MonoRail has been to use and extend. At first, the lack of documentation threw me off, but then I just took the plunge and read the source, after which things were a breeze. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *