Greetings all!

It’s been a while I know, and there are a couple of reasons for that. I’ve been in the process of relocating my little family from London to Swansea in Wales which has knocked most of September’s plans out the window and I’ve had to steal little bits of time on trains, here and there to work on cozwecan.com. But enough about all that…

As you may have seen from my previous post, I’m using ASP.Net MVC on the front end. As I’ve been working along, the specifics of implementing the various views have (as you’d expect) been getting more and more complex as I add more functionality. This I don’t mind. It’s when it gets complicated that I start to worry. I don’t think I could put it more succinctly than Dru Sellers did:

It is ok if something is complex so long as it is not complicated.

complex: composed of many interconnected parts; compound; composite

complicated: difficult to analyze or understand

The Latest Hurdle

There are many things that can cause complication on a project, the one I want to highlight now is that of the View Engine that comes built into the ASP.Net MVC 1.0 release. One could have seen this coming when one of the most popular things that made it into the MvcContrib project was the concept of SubControllers. One of the primary reasons for this was so that controllers could be “stacked” in order to return cross-cutting concerns to a single View, but keeping the logic separated. But the out-of-the-box experienced kinda expects you to throw all of those cross-cutting concerns into one controller. The need for this was apparent to some and not unknown to the ASP.Net MVC team, but they just didn’t have it on their radar as a v1.0 goal. I’m not one to complain though, it’s still my platform of choice, and for good reason – the extensibility points are absolutely superb! If you don’t like a particular piece, swap it out with something you prefer – it’s the very thing that makes MvcContrib viable! But I digress…

On with the…umm…well…’View’

Microsoft have this big problem see – they’re not trying to make everyone happy, they’re trying to keep everyone (read: existing customers) happy, and so they’ve chosen (OK – been forced somewhat) to stick to this strong paradigm they’ve <%enclosed%> themselves in for the last few years. In short, the View Engine that comes built into ASP.Net MVC is…well…how to put this delicately…it just doesn’t cut the mustard when it comes to separating concerns on large, functionally rich websites. Others have said far worse!

The problems with the View Engine are not immediately apparent. This is because it’s a lot like erecting scaffolding up the side of an old building. The walls look straight and you think erecting it shouldn’t be too difficult, and so you begin one piece at a time. The problems don’t show themselves when you build your first view output, or the second. They start creeping in surreptitiously, and when next you look back, you realise your scaffolding is leaning outwards because the building actually leans out over the street! Let’s be clear, there’s nothing wrong with the building, it’s been standing like that for years! Your scaffolding is what needs to be adaptable to the circumstances when something is not “normal”.

You know that if you go much higher, the scaffolding is just going to get top heavy and come crashing down, and instead of undoing the hard work you’ve already done and moving it a few feet back from the ground up, you bolt it into the wall so that it can’t fall backwards, and you can go higher. When you eventually get to the top, you’re left with a tightly coupled mess that cannot be adjusted one way or the other because it has become completely dependent on the building for stability, and the building on it for maintenance. This relationship can only end in tears…

Where to from here?

To be clear, from the beginning I have always wanted cozwecan.com to be success story for ASP.Net MVC in a very direct manner. I wanted to be able to say that MVC gave you everything you needed, without having to fish around for bits and pieces to finish the work. That probably means I have tried for a little too long to cut the corners off this square peg called a View Engine. I have always been open to ideas though and looked at various alternatives to try and help along the way. I’ve tried to go extreme in the convention-over-configuration approach by using FubuMVC. And I’ve also looked at just replacing the View Engine with something like NHAML or NVelocity for example, but I still found too many friction points that meant staying with the standard framework wasn’t any worse – something always eventually got in the way, or I had to jump through hoops-a-plenty, and those would eventually catch on fire…and I’m pretty sure there were ninjas in there sometimes too.

I really needed to find something that could offer real solutions, not tiresome workarounds to things like partial or donut caching, and elegant means of creating reusable parts that I could pepper around the site. Something that didn’t make the HTML look like it just threw up on itself, leading to tag soup and maintenance nightmares. Something that was more simple, but gave me more control and was still quick to work with. Something that could just be good at being a View Engine and stay the hell out of my way at other times!

Not asking for much eh?!

Queue the angelic chorus!

It was when Karl Seguin announced that CodeBetter Canvas had been altered to use Spark, my ears immediately pricked up! “There’s no way that this could be just another view engine!” I said, and that was when I committed to taking a deep and meaningful look at the Spark View Engine developed by Louis DeJardin. Yes, I had previously heard of it and had seen it back when it was part of the MvcContrib project early on, but I must be honest, I didn’t think it was going to bring anything more to the party than NVelocity did. Turns out that NVelocity (and other factors) were big contributors to the final design. A final design, which I must say, is PURE GENIUS in its simplicity!

I’ve been using it for 3 days now and I didn’t beat around the bush either. I wanted to know very soon if this thing was going to work for me, so I went in straight for the pain! Well…so far it has been like getting an epidural to be honest, and I feel fuzzy all over! It seems that everything I have a need for, has documentation available or somebody has already blogged about it! Writing out .spark files for various concise pieces of output, only to have the Engine sew them up beautifully together during the page lifecycle has been an absolute pleasure, from a building, migration and refactoring point of view! You won’t see any samples in this post because there are many better ones already out there, but I plan on doing a series where I show small things that Spark is doing for me that I couldn’t do elegantly before – and if I find any more hoops, I’ll talk about those too.

Conclusions

So, you may be asking why I’ve bothered to publicise this small, particular niche of the website. Well, because nobody should have to get as far as I did with the wrong built in View Engine only to find they’re going to be throwing away weeks of code. Luckily here Spark has come to the rescue once again, because without me having that expectation, it already supports the <% %> syntax for this very purpose – to ease migration. So I’m happy to say I haven’t lost the premise of most of my views, but I will be able to reengineer the paradigms behind them now more elegantly.

Secondly, I don’t think Spark gets enough publicity – Microsoft have HIRED the guy for goodness sake and it’s still got relatively low adoption rate. It’s nothing to do with Lou himself – I mean he’s largely responsible for building the damn the thing, and documenting the hell out of it – so why lump him with the marketing too?! That’s OUR job as bloggers now and I’m really stoked that the Herding Code lads have picked this one up and ran with it! I’ll do what I can, but it’s more important that developers learn that they can build better websites by switching.

I’ve never met Lou personally, but I sure do hope he donates his brain to science in about 90 years or so. He’s a FREAKIN’ GENIUS man! But he’s not going to tell you that. He has taken what seems to be such a complex problem and turned it into something so simple that it makes us mere mortals feel like we’re wielding Poseidon’s own trident spewing pure, beautiful and maintainable mark-up into views that now truly live up to their potential as once described in Fowler’s definition! Keep up the good work Lou, your efforts are truly appreciated here…

For the most part though, I really just wanted to make sure developers understood that I’ve been to hell and back hand-in-hand with the built in View Engine, and I didn’t want you to have to go through the same pain. Seriously, stop what you’re doing and play with Spark for a day and don’t discount it until then – it’s an absolute WINNER!

All the best!
Rob G