Castle Monorail

This post is not about some train riding one single track and a big fortified building but about the Monorail MVC (Model View Controller) framework of the Castle Project.

This is not going to be an introduction to Monorail but rather a story about my workflow for this particular project. Although I might write an article about Monorail in the future, for now I will point you to the Castle Project website for information about Monorail.

Last week I had to build a web application for the Van der Werff project, which allows users to view project information online and report malfunctions. The access to the information must be protected from anonymous users and only be accessible for authenticated users. The project information comes from the WCF web service, which also provides the security.

In the next paragraphs you can read how I implemented the application.

Functional Structure

The application has the following structure:

  • Home
  • Contact form
  • Projects

    • Project information
    • Addresses

      • Address information
      • Product information
      • Checklist information
      • Report malfunction form
  • Login

Logical Structure, Controllers & Actions

I started dividing the application functionality into logical groups which became the controllers and each bit of functionality became one or more actions.

The result is:

  • Home Controller

    • Home
    • Contact form
    • Contact form ‘thank you’
  • ProjectView Controller

    • List projects
    • View project
    • View address
    • View product
    • View checklist
    • Report malfunction form
    • Report malfunction form ‘thank you’
  • Login Controller

    • Login form
    • Logout

Home Controller

The home controller was the simplest controller to implement, it contains only three actions. The first action ‘Home’ does nothing more than to render the homepage. The second action ‘Contact form’ renders the contact form. The third action is more interesting, it gathers the information from the ‘Contact form’ validates it and sends it as an e-mail to the configured address.

This was the first time I used the e-mail sender service of the Monorail framework but it was a joy to work with. You can store anything in the PropertyBag and then render an e-mail template like you would with a normal view. After rendering you get a Message object back which you can send.

Here is some sample code:

// set the properties
PropertyBag["from"]    = Settings.ApplicationMailAddress;
PropertyBag["to"]      = Settings.ContactMessageDeliverAddress;
PropertyBag["name"]    = name;
PropertyBag["phone"]   = phone;
PropertyBag["mail"]    = mail;
PropertyBag["subject"] = Settings.ContactMessageSubject;
PropertyBag["message"] = message;

// send the message
Message msg = this.RenderMailMessage(Settings.ContactMessageTemplate);
msg.From    = Settings.ApplicationMailAddress;
msg.To      = Settings.ContactMessageDeliverAddress;
msg.Subject = Settings.ContactMessageSubject;
this.DeliverEmail(msg);

The RenderMailMessage() function does all the magic of rendering an e-mail template and creating a Message object out of it.

After the message is send, the user is redirected to a nice ‘thank you’ view.

Login Controller

The login controller container, do not be surprised, the login functionality. The controller does nothing more than to render the login form, check if the user name and password are valid string (the real authentication is done by the WCF back-end web service), store them in the session and destroy the session when the user logs out.

Project View Controller

The project view controller was surpassingly easy to implement. It does nothing more than retrieving data, managing identifiers and to render the correct view. Actually it does a little more than that: It manages caching and also contains an e-mail form which allows the user to report a malfunction. The functionality is similar to the ‘Contact form’ functionality.

But it really surprised me how simple it is to create such an application. If I had used ASP.NET or PHP it would have cost me a lot more time.

Time

Speaking of time, it took about three 8 hour days to implement the application. That includes writing the style and html layout as well as deploying the application to the server. Some people might still think that 24 hours is too long, but remember: There was a learning curve, for example: I did not know how to use the mail sender service.

Another aspect that cost more time than it could have was: breadcrumbs. I could have hardcoded them, saving myself about 8 hours, but I choose to write a framework to handle them.

Breadcrumb Framework

The breadcrumb framework contains some classes to allow me to define breadcrumb paths easily. Each action can be decorated with a Breadcrumb attribute. An interceptor checks if an action is decorated with the attribute and adds it to a manager class if it does. Then on the view I can use a ViewComponent which renders the breadcrumb path. Simple, clean, nice!

Although the framework needs a lot of tuning, it something I am considering donating to the Castle framework. I just hope I can find the time to do it.

Conclusion

Castle Monorail is a powerful MVC framework which allows it users to develop web applications rapidly. It is very extensible as well: Most, if not all, components can be swapped out and be replaced by others.

The integration with Castle MicroKernel makes it even easier to develop complex applications. Combine it advantages with its ever growing user base/developers base and you have yourself a winner, well that is my opinion anyway :) .

That is it for this post. I hope you enjoyed the read, if you did, please let me know and if you did not, please let me know too. Bye

Sources

  1. [1] Castle Monorail
  2. [2] Castle Project
  3. [3] Castle MicroKernel