After a while working on it, I converted the scratchpad for the routing documentation into a proper patch for Castle’s website. Gauthier Segay also contributed some sections, and I hope we can now provide some fixed, formal information on Monorail’s current routing system. Thank you to Markus Zywitza for applying the patch.

If you see something that looks incorrect, or something that’s missing, then you can help fill in the gaps by patching or just writing it up and someone else will try and create a patch for you.

The next missing docs I plan to address are the fluent registration API for Microkernel, but there are a lot of features I’m not 100% on. Alwin has been doing some great work here so that patch will probably be coming pretty soon. In the meantime, any contributions would be gratefully received!

Recently I’ve set up a network attached storage computer on my home network. As well as providing RAID storage for all the devices in the house, it acts as a central download server for everyone to use. Key to this strategy is SABnzbd, a Python application which downloads binaries from newsgroups, and which sits on the server as a daemon, grabbing files on a schedule or when we ask it to. The functionality of this software is incredible, but more than that, there is a great deal of documentation for each feature directly linked from the web interface. This enabled me to set up advanced features such as RSS feeds, categorisation, and post-download scripts, in order to shift SABnzbd from being handy to indispensible.

This post is not about SABnzbd though – it’s about documentation. My latest project has been a very quick CMS solution using Monorail, and I’ve been taking advantage of the new features available in Castle’s trunk. The new routing in Monorail, the fluent API for component registration in Microkernel, and more new features, have all been making my life easier… once I’ve figured them out. I’m in awe of the people who have produced these features and I’m not adverse to digging round test cases where I can, in order to find out how to use them.

However, it would unarguably be better if the Castle documentation reflected these new changes. It’s understandable that the documention lags behind these features, and since I don’t have the intimate Castle knowledge needed to contribute to fixing bugs or adding new code, I figured it’d be good to try and work on this documentation. Castle uses an XML based documentation format which is just fine for final docs, but not that great for scrabbling down notes and filling out information. For that, I’ve decided to use the using.castleproject.org wiki, a site designed to hold tips and tricks for the Castle Project.

I’ve set up a simple system of tagging which allows people to search out stuff in need of documentation and then tag it when it’s complete. At that point, I plan on converting it into a patch for the official Castle documentation. In this way we can get the rapid prototyping of a wiki combined with an easy route to formal documentation. I think barrier for entry is a definite problem for contributing on many projects, and documentation can be a good place to start. For Castle, I’m trying to make even the barrier for entry for even that documentation very low. So if you can help out with the routing documentation or the validation documentation or anything else that’s missing or incomplete in the main Castle docs, please pitch in and try and help!

(Also published on my LosTechies blog)

At the moment, the Castle Project is actually host to a number of separate projects. Monorail and Active Record for example, work extremely well together but Monorail does not require Active Record; the same can be said for Windsor.

Previous releases of Castle have contained all of the child projects in one package. In future, this may not be the case. The Castle PMC have decided to split each project off, while still keeping them under the Castle banner. This has the immediate advantage than a Windsor release does not have to wait for a Monorail release, which is surely going to increase the mobility of Castle as a whole. While some sections may lag behind for a while, segments are free to move at their own speed.

It’s been a while since a full Castle release, and I feel that many developers wait for such releases before adopting a project. More frequent official versions of the Castle components could increase adoption and interest in the overall brand, which can only be a good thing.

I’m starting work on a new project on Monday and I’ve got full control of all development aspects. With that in mind, I’ve been thinking of how I can get to beta status as quickly as possible – finish main development and get to the stage where the client is reviewing minor details. This is dependant on a combination of my skillset and the tools I’m going to use. I’ve got:

• Existing Plastiscenic.Commons code and project structure for quick setup
• C# 3.0 to remove some boiler plate code (automatic properties for example)
• Monorail to develop with fewer LOC in the main app
• NHibernate for low friction database work
• ExtJS for rich backend
• Strong cross-technology skills to integrate the above

Are there any additions to this that you use to accelerate the development process?

I should file this under “things that are probably a design pattern but I’m not sure exactly what kind”; it seems like one of those typical things that you will naturally stumble upon when using the Repository pattern and indeed when you start to separate out your query logic.

DetachedCriteria is an “offline” version of the NHibernate Criteria class, used to build up Criteria where an NHibernate Session is not available. The NHibernate documentation has more on how to use DetachedCriteria on its own, but I want to talk about inheriting from it to create a simple custom finder class.

Say we have a Active Record Person class, with height and weight properties:

[ActiveRecord]
public class Person : ActiveRecordBase
{
    [PrimaryKey]
    public int Id { get; set; }
    [Property]
    public int Height { get; set; }
    [Property]
    public int Weight { get; set; }
}

The height and weight properties are simplified, and I’m using C# 3.0 automatic properties for clarity. I want to search for a Person based on their height and weight, so to do so, I’ll create a new finder class:

public class PersonFinder : DetachedCriteria
{
    public class PersonFinder(height, weight) : base(typeof(Person))
    {
         Add(Expression.Eq("Height", height));
         Add(Expression.Eq("Weight", weight));
    }
}

A simple class, but it clearly states its purpose. Here’s how it could be used:

Person.FindAll(new PersonFinder(200, 300), new Order("Id", true));

For me, the advantage of this code isn’t just in reducing what you have to type. Instead it is in the readability and discoverability of the code.

I guess this applies to any IoC container, but you get the idea. How would you describe Windsor to a newcomer in just one sentence? I just wrote:

Windsor is a way of passing in different classes to code that is going to use them, it helps you write applications that are very flexible and testable.

But that was pretty off the cuff and I’m not really satisfied with it. Give it a go, it’s pretty hard.

Recently Plastiscenic has been asked to quote for a fairly large project, and if it comes off I’ll have the chance to work on it from the ground up, using whatever technologies I think are best suited.

(more…)

I’ve blogged before about the enabling features of Monorail and Active Record, part of the Castle stack. Another piece of software which is making my development life a pleasure is ExtJS – a collection of javascript goodies created by Jack Slocum and his team – and when these three things come together, watch that coding fly…. I’ve created a screencast in which I demonstrate how easy it is to build a paging, sorting, filtering, AJAX-powered grid using ExtJS and Castle, and you can watch it here. It’s 20 minutes long but filled with goodness – and a couple of hacks (forgive me . Don’t forget to check out all my past screencasts too.

UPDATE: As requested in the comments, you can MonorailExt1 VS Project directory of this.

Ayende quickly posted something called HotSwap, which is a little snippet of code which uses a FileWatcher, Windsor, and on-the-fly code recompilation to increase your productivity. With ASP.NET, building your code changes causes an appdomain restart, and you will typically have to wait a few seconds for the appdomain to come back up before the browser will display your changes. This basically means that when working with ASP.NET, there are no quick code changes – you always have that four second wait till you see the effects.

HotSwap resolves this by building your code for you when it detects a change. Using Windsor it can swap out the old assembly containing your code and replace it with a new dynamically created assembly containing your new code – all automatically. The key advantage of this is that it’s all done in-memory, and none of the DLL files in the bin directory change. This means that you won’t trigger an appdomain restart and your changes can be seen almost instantly!

I was really impressed and excited by this approach so I did a very quick screencast on the topic. I was using the Castle RC3 MSI, and created a project with Windsor integration enabled. This code only works for your controllers at the moment, but a lot of the time that’ll be where you need this kind of productivity boost.

Ayende – cheers for this, and I’m sorry if I pronounced your name wrong as I’ve only seen it written down!

UPDATE: I’ve uploaded the HotswapTest Project from the screencast. You’ll probably need the Castle RC3 MSI installed to build it.

Hammett reports that Castle RC3 is now available. There are loads and loads of changes in this, new Controller test stuff, JSON support, new validation on the server and client – it’s a great release. Get Castle RC3 now.