/// Friday, November 18

Why not MonoRail?

I almost have the core libraries to start a Boo web framework. Someone in the IRC asked why not build on MonoRail or use Brail? The main reason is the use of NVelocity as the official view engine. Brail emulates NVelocity. They completely missed the point of Ruby on Rails.

NVelocity is a full blown language. Why learn another language? NVelocity isn't object-oriented so you have to do something like this:

<head>
$AjaxHelper2.GetJavascriptFunctions()
$Effects2Helper.GetJavascriptFunctions()
</head>

<body>
Auto completion:<br>
$AjaxHelper2.InputTextWithAutoCompletion( "name", "nameautocompletion.rails", null, null )
</body>

MonoRail pushes two objects into the NVelocity context. These objects provide functions to aid in the creation of AJAX controls. I would prefer to have a controller derived from AjaxController that adds the javascript functions to the header as well as provide additional functions.

NVelocity's purpose is to be a template engine. It interprets a template at runtime to render a view. It might be worth incurring a performance hit if NVelocity provided some advantage. I've shown in a previous article how Boo can be used as a template compiler. In short, the article shows how Boo's compiler attributes let you transform a template into managed code.

How would I approach all of this using Boo? First, using OOP I would derive AjaxController from DefaultController:

class AjaxController(DefaultController):
    // add javascript functions to html
    private def AddJavascriptFunctions():
        pass

    // create an AJAX input text control with auto copmletion
    def InputTextWithAutoCompletion():
        pass

To create an actual controller:

[Template('person.tpl', 'RenderFind')]
class Person(AjaxController):
    def Find():
        RenderFind()

    def Auto():
        // logic to return matches for autocompletion
<!-- person.tpl, compiled as RenderPerson() -->
Auto completion:<br>
$InputTextWithAutoCompletion("name", "person/auto", $Model.Name)

The Template compiler attribute transforms person.tpl into a RenderFind() method. You can add multiple Template attributes. To render a person, call Person.Find(). There is no need to send variables to a template. The template is part of the class and has access to any property, field or method of the class. We're not setting up some context and passing it to an engine like NVelocity does. Person is derived from AjaxController giving this class AJAX functionality by inheritance. As an added bonus, you can debug through the generated code of the template. (Boo does not yet have a #line directive. When Boo does, you'll be able to debug the template directly.)

Are templates the way to go? It's an outdated idea for web frameworks. I may go down the road similiar to XAML, instead I'll use Glade markup. Imagine being able to draw your GUI in Glade and having it run as a web app?

If you want to create an innovative web framework, you have to start with an innovative language and take advantage of its features. That's what ROR did. I think the same can be done using Boo.

Comments:

Very interesting - I like it. There's no way on god's green earth my company will allow me to use Boo, but your logic is sound. We use MonoRail, but only as long as aspx views are supported. It's hard to change big enterprise, you know.
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?