MR 3 update / Castle Blade

July 18th, 2011

Fun times! Since I’ve left MS I’ve been working on a real web site/backend/frontend – you know, doing actual work instead of long meaningless meetings, doc writing and one-on-ones with managers setting you up for failure (I wonder if I should make one of my ‘reviews’ public, so you’ll see the amount of BS I had to put up with).

WebSockets

Anyway, the first work was to create a websockets server. That was fun especially since F# offers its async workflow support and MailboxProcessor. It’s fun to think about it. While at MS, one of my friends there wouldn’t stop bitching about how F# is incredibly superior to C#. Gosh, he was right..

The company I’m doing the work for and I are discussing whether we will make the websocket server available commercially. It’s a PITA to implement the protocols, to test them and keep up, since the spec is in progress. So, sorry, won’t be doing all this work for free.

Ideas playground

On the MonoRail end, we’ve been using it extensively and coding up functionality as needed – by we I mean Henry and I. It’s been quite a journey to reassess all the design decisions in MR1/2, and also evaluate what’s out there. I’m sure we learn more from our mistakes than anything else. Mauricio is pushing some interesting ideas on web frameworks that are making me reevaluate our proposed API over and over again. Now that I’m quite familiar with FParsec, the idea of using combinators to compose forms (formlets) is enticing. It’s just strike me as something hard to expose in C#, we would need a different API and I’m sure it would be awfully verbose.

Castle.Blade = ++Razor

I love Razor’s simplicity and tooling support. Achieving simplicity is a major accomplishment, and the guys at the ASP.NET team did it. I remember when Scott Hunter gave us a preview of what at the time was code named Plan9. Awesome work!

I’ve then decided to make Razor the main view engine for MR3. However, when I started to experiment with a better API for our helpers library I bumped into some not-so-nice limitations from Razor. For example, I wanted to be able to express something like:

 Rails |  copy code |? 
1
2
@Form.For(..., {
3
	// this is a block
4
        @builder.EditorFor(m => m.Name)
5
})
6

Well, Razor does support translating a mix of content and code block into a delegate – which is neat. The limitation is that they cannot be nested, and the parameter name is restricted to “item”

 Rails |  copy code |? 
1
2
@Form.For(..., @{
3
        @item.EditorFor(m => m.Name)
4
})
5

The issue is that “item” is not very expression. I’ve spent many hours digging into Razor’s code trying for find a way to work-around this limitation (by using its extension points, not changing their code). At some point it was clear that coding up my own parser and translator would be easier. Castle Blade then came to fruition.

Blade intends to be 100% backward compatible with Razor, and introduces a few (one?) different transition marks to overcome Razor’s limitations. For the example above, we would use:

 Rails |  copy code |? 
1
2
@Form.For(..., @=> builder {
3
        @builder.EditorFor(m => m.Name)
4
})
5

The @=> transition signals that a delegate will be created for the block, and the parameter name is the one that follows. In theory more than a single parameter is supported.

We also support nested blocks, which allows for the something like the following:

 Rails |  copy code |? 
01
02
@Form.For(..., @=> builder {
03
        builder.FormTemplate(@=> t {
04
                <div>
05
                    @t.Label(): @t.Field()
06
                </div>                                                      
07
            });
08
 
09
        <fieldset id="contactForm">    
10
 
11
        @builder.TemplateFor( m => m.Name )
12
        @builder.TemplateFor( m => m.Email )
13
 
14
        </fieldset>
15
})
16

Feel free to give it a try.

MonoRail+++

MonoRail’s 3 goal is based on our my experience and perception of the “state of the union” and trends. If I could put them in three simple statements:

I’m mentally tired of crafting web sites despite huge functionality overlaps (combine/compose). I’m tired of REST being an afterthought to existing websites (rest support from the beginning). I’m tired of frameworks created by people without *actual* website building experience (frictionless).

The goals/roadmap/value-proposition were discussed in the past in our development list.

  • Since our underlying runtime (CLR) is keen on static typing then fully embrace it
  • Move forward: embrace HTML 5
  • Simplify special render for different form factors
  • Strive for simplicity, but no simpler

I’ll dive into what’s been done in practice to address each of the above bullets in upcoming blog posts.

15 Responses to “MR 3 update / Castle Blade”

Torkel Says:

Interesting, looking forward to hearing more on MR3!

Danyal Says:

Hammett is back! :)

Craig Wilson Says:

Hammet,
Any reason to continue with MonoRail? While it seems that ASP.NET MVC does most of what MonoRail does, FubuMVC definately goes way beyond and already exists? What do you think of Fubu?

Omer Mor Says:

welcome back hammett!
when did you leave MS ?
I’d love to hear your view on MEF as an ex-insider.

hammett Says:

Hi Craig,
I dislike some of the design decisions of MVC and Fubu. That said, I’m building MR3 for my own use. I happen to release it as an true OSS project ’cause I believe some projects benefit from a community perspective.

Finally, we need to push the limits. Being content with what’s out there isn’t for me. :-)
Cheers

hammett Says:

@Omer, I was interviewed by Zdnet on this topic. Just do look it up.

Dan Quirk Says:

@hammett

Could you possibly use one of your future blog posts to highlight the design decisions which differentiate MR+++ from FubuMVC or OpenRasta say, and what influenced those decisions? Are they, for example, mainly tooling and language preferences that the average user wouldn’t necessarily notice or are they decisions that you feel will have a impact on the frameworks capability, whether it by scalability, extendibility or flexibility, in production? As someone who has several large enterprise codebases using MR in production and looking to start to explore a composition over inheritance MVC framework I would be fascinated to know your thoughts.

Cheers,

Dan

hammett Says:

Dan, I can highlight MR3 design decisions, but I won’t compare them with other frameworks, simply because I dont know them deep enough. It’s a good opportunity for people in the community to do the comparison.

Dan Quirk Says:

@hammett

You must be able to differentiate them to a certain degree or you wouldn’t be able to say you dislike some of the design decisions made on FubuMVC ;)

Seriously though, any insight into your design decisions on MR3 would be greatly received :)

Cheers,

Dan

hammett Says:

Dan, fair enough. My understanding of Fubu is limited to a presentation Jeremy gave in 2010 at MS campus. I didn’t like the Model -> Model style, the fact that you’d have to attach behaviors to control custom serialization. I believe that works for websites that are focused exclusively on html rendering *or* rest, but not both. Anyway, I’ll constrain myself to this comment on the topic.

Ole Marius Says:

How will a scenario where MR3 users with existing MR2 projects using NVelocity wants to move gradually over to Razor look? Will it be possible to run NVelocity and Razor side by side, or is it necessary to create new files for the Razor views? I’ve been looking around for a possible way to switch over bit by bit.

hammett Says:

Havent thought about this one. I dont think we will provide a migration path..

srdjan Says:

“‘state of the union’ and trends” seems to be statefull client (web app) with an all RESTful JSON backend. There are great client side UI frameworks already (angularJS is a good example of what is going on there)…
a brief scan through Monorail 3 repo shows another (but presumably better) server side presentation framework.
Frankly, if you are focusing on having to one up on ASP.NET MVC, Fubu and likes, you may be missing the boat.

hammett Says:

hi srdjan. I completely agree. I also think that web is becoming prevalent for systems to system communication where rendering a html is just one of many forms of “communication”. I’m not sure why you feel we’re no aligned? Do you think we’re competing with fuby/asp.net on the UI front? Please expand your thoughts.

srdjan Says:

Hi, its been a long time :) Hope all is well.
After reading your post, I was left with impression that Monorail+++ is server side MVC Framework with the new server side view engine (Blade). My thoughts are that these days presentation concerns should be client side responsibility. Server side responsibilities should be to simply serve static resources and RESTful APIs…

Leave a Reply