RobertTheGrey

Spark and jQuery Templates learn how to play nice

noreply@blogger.com (Robert Greyling) — Mon, 08 Nov 2010 14:46:00 +0000

A couple of folks are running into trouble while trying to use the recently popular jQuery Templates in combination with the Spark View Engine for one innocuous, simple reason – they both use the ${blah} syntax as placeholders for their magic bits. It is now gaining even more popularity due to Steve Sanderson’s AWESOME Knockout JS library and I’m not surprised – it seriously kicks ass!

I guess somebody didn’t really think the syntax through and have a good look at what was already out there, but I think it’s things like this that really test the metal of a framework in its ability to be flexible and co-exist happily with others. Getting them to play nice with as little friction for the developer is key in getting adoption up in all areas.

The Problem

For this post I’ll be using Rob Ashton’s RavenDB Gallery sample on github since it uses both Spark as a View Engine and jQuery Templates for loading images and details.

Take a look at this view:

<content name="title">Home Page</content>
<content name="scripts">
    <script type="text/javascript" src="~/Includes/js/image-browser.js" ></script>
</content>
<h2>The RavenDB Image Gallery</h2>
<p>
    This is an example ASP.NET MVC application using RavenDB, 
    MVC2, StructureMap, Moq and NUnit
</p>
<label for="searchText">Search</label>
<input type="text" id="searchText" name="searchText" />
<script id="browsing-image-template" type="text/x-jquery-tmpl">
    <div class="browsing-image">
        <h4>${Title}</h4>
        <img src="/Resources/Image/${Filename}" alt="${Title}" />
    </div>
</script>
<div id="image-browser">
</div>

Notice the highlighted lines above are referencing jQurey template values inside the ${ xyz } syntax. The issue here is that Spark gets the first stab at these files, and if it sees the ${ xyz } syntax, it tries to parse the view using the variable it knows about, which will either lead to unexpected results because you have the same variables defined in Spark and in jQuery.templ, or it will fail completely due to a Spark dynamic view compilation error since it knows nothing about ${Title} or ${Filename}.

The Workaround

Now there are already a couple of workarounds that have been used. For example, by using jQuery to load up the templates via an AJAX call will bypass the Spark rendering engine unless it’s specifically a Spark Javascript View, but this means you take the asynchronous hit for something that might not be ideal. Another solution is to use the alternate jQuery Templates syntax which Spark doesn’t recognise. It looks like this: {{= Title }} … pretty ain’t it? Yeah…I didn’t think so either.

One Solution

Well of course the ultimate solution would be for the developer to just throw any old syntax in there and the collective frameworks just figure out which bits to parse and which bits to leave alone, but there are two reasons I didn’t want to try and achieve that. Firstly, the next guy who has to come and read your code may just decide it’s worth it to take a contract out on your life, and I don’t want to take responsibility for that :-). To work out programmatically what the developer wants is one thing, and in a way it’s a nice puzzle to solve, but working with and maintaining that code will not be a pleasant or intuitive experience.

Some might look at the view above and say that they don’t like the fact that a fat script tag has just dropped itself down in the middle our HTML mark-up without an invite. Heck, that’s going to make plenty of developers do a double-take – it’s just not natural and creates a disconnect in the flow of the code. Just like if someone decided to solve a complex algorithm inside an IF statement in the middle of a method, you would expect a good developer who cares about code maintainability and readability to extract that complexity into a different method right? Right?!

Well that’s basically what we’ve done as a first stab at supporting jQuery Templates. That same view above will simply be split into two files, kind of like extracting the complexity into it’s own method. We use an existing feature in Spark called the <include> tag and use the new parse=”html” option which basically passes the contents though without parsing for Spark variables or HTML encoding it. The result looks something like this:

Index.spark

<content name="title">Home Page</content>

<h2>
    The RavenDB Image Gallery</h2>
<p>
    This is an example ASP.NET MVC application using RavenDB, MVC2, StructureMap, Moq
    and NUnit</p>
<label for="searchText">Search</label>
<input type="text" id="searchText" name="searchText" />

<include href="browsing-image-template.htm" parse="html" />

<div id="image-browser">
</div>

And the extracted file can be called anything you like, but as you can see, I’ve named it something useful and given it a “.htm” extension so that we get the benefits of the HTML editor in Visual Studio:

browsing-image-template.htm

<script id="browsing-image-template" type="text/x-jquery-tmpl">
  <div class="browsing-image">
    <h4>${Title}</h4>
    <img src="/Resources/Image/${Filename}" alt="${Title}" />
  </div>
</script>

As you can see now, we’ve also achieved some form of Separation of Concerns where the flow of the original mark-up is undisturbed, and the included template complexity gets its own space to operate in during the writing and maintenance of the code, but when come it comes to the browser requesting the view, it is fully rendered on the server and delivered in a perfect single HTTP stream with all the right bits falling in to the right places.

OK – Now gimmeh teh dllz

It just so happens that you can get the latest via the NuGet package manager direct in Visual Studio. If you just want the raw release package in a zip file, you can always download the latest from here and just login as an anonymous guest.

Conclusion

To be clear, this is only one way of achieving the solution, but I am keen to try it out on the audience that care because there is still a decent sized hole with this method. Namely, the question arises: What if you do want to use some Spark Variables inside your jQuery Templates? What if you do want the view engine to parse things inside there?

Well I’d like to see some examples of that before spending the time figuring out a more complex method of escaping, because I’m not entirely convinced that would be a good or maintainable design. I’m happy to be convinced otherwise, but for now I would suggest that this is a better way…

Until next time,
Robert The Grey

Don’t just get the Spark View Engine - NuGet it now

noreply@blogger.com (Robert Greyling) — Mon, 08 Nov 2010 00:55:00 +0000

For a couple of weeks now the Spark View Engine has been available as a package from the NuGet server but last night it had a bit of a makeover.

If you open the package manager and filter on “Spark” as I have, you’ll see two copies of the Spark Core and the Spark.Web.Mvc packages. The highlighted one is the latest build, and the other is the latest release from a while before that – version 1.1 to be exact. At this stage, I would recommend using the latest build due to a number of fixes and additions that have been added recently.

What’s the difference?

Well, the nice thing about getting Spark via the NuGet Package Manager is that for a new project, it will also automatically bootstrap the view engine code into the Application_Start which means you basically go “File –> New MVC Project”, reference Spark via the NuGet Package Manager, and you’re ready to start creating views and controllers.

All the wiring is taken care of. Well how is that done pray tell?

Well, we’re taking advantage of one of the other packages in the NuGet list called the WebActivator package which we take a dependency on. This allows us to shim in bit that we need for bootstrapping. After installing the Spark.Web.Mvc Package in an empty ASP.NET MVC2 application, the folder structure will look something like this:

Notice the AppStart_SparkWebMvc.cs file there? That looks like this inside:

using System.Web.Mvc;
using Spark;
using Spark.Web.Mvc;

[assembly: WebActivator.PreApplicationStartMethod(typeof(MvcApplication1.AppStart_SparkWebMvc), "Start")]

namespace MvcApplication1 {
    public static class AppStart_SparkWebMvc {
        public static void Start() {
            var settings = new SparkSettings();
            settings.SetAutomaticEncoding(true); 

            // Note: you can change the list of namespace and assembly
            // references in Views\Shared\_global.spark
            SparkEngineStarter.RegisterViewEngine(settings);
        }
    }
}

The Spark bootstrapping code is kept separate from your Global.asax and gets dynamically inserted at runtime by the WebActivator. The two advantages here are that it leads to a nice clean uninstall if you don’t need it anymore, and it also lets you keep the complexity of the Global.asax down. You’ll see once you’ve installed multiple packages that all do their own things to the Global.asax, you’ll be glad they’re all neatly parcelled away for easy maintenance.

Conclusion

I won’t go into too much more detail here, suffice it to say that I’ll be keeping the NuGet feed up to date with the latest Spark builds so that you can always take advantage of the latest features, but we’ll leave some older versions up there for those that prefer a more stable, tried and tested release. Let me know if you have any hassles…

Until next time…
Robert The Grey

Don’t you tell me where to put my damn views – I’ll tell you!

noreply@blogger.com (Robert Greyling) — Sun, 26 Sep 2010 15:17:00 +0000

Ever get the feeling the MVC framework you’re using has more control over you than you have over it? This is a common trend when trying to bring convention over configuration to applications built with the framework. Conventions are great for the most part, Ruby on Rails for example prescribes exactly where *everything* goes and MS MVC adopts this approach too. If you don’t put your views here, and your controllers there, they just ain’t views or controllers, even if they look, act and smell like views or controllers.

FubuMVC works a little differently in that it lets you specify conventions instead of forcing you to adapt to someone else’s opinion of what works. Instead of arbitrarily handling conventions at folder level, you can tell FubuMVC to pay attention to the meta data in your solution. It can trawl through Types or file types or naming of specific files, Types, Methods – you name it. Go down to the level that makes sense to you and there are plenty of examples that can show you how. The beauty is, that once it’s in place, it’s a cast iron convention – and more importantly, it’s your convention – things that work for you or your team, not someone else’s.

So What?!

So what? What the heck does that mean to me anyway? More importantly, who gives a crap? I don’t mind following a prescribed convention defined in Rails or MS MVC – it’s a solved problem then that people much smarter than me came up with, and I can get on with building the website right?

Exactly right! But what if the prescribed convention you’re following, means that as a developer, you’re doing more clicking just to navigate between the views and controllers? And you’re doing more scrolling in the folder tree list just to find related items. And keep having to expend mental energy every. single. time. you’re working on a particular feature. Let’s be honest, you spend a lot of time doing this:

“Where was this view again? Hmph…is that a partial? Where was it again? Click…click…click…Ctrl+Shift+F…” you get the idea.

In my experience, this has led to some of the more lazy developers among us creating massive controllers for hundreds of views, just to get around the problem of having to remember where things are and completely violating SRP in order to get some form of file co-location. When you’ve got a large project with a fairly decent sized dev team, this can get out of hand very quickly, and before you know it, there are broken windows all over the neighbourhood.

Instead, even the controller should be exercising Separation of Concerns – they are not immune and are not special. Controllers are subject to the same laws of good design and way too many developers forget that fact. They consider them to be just some kind of wiring mechanism between views the the real code. That’s rubbish and you know it! Controllers should be short, sharp and to the point.

OK – so where are we going with this?

Well, up until now the Spark implementation on FubuMVC had been hard-wired to work under the same conventions as MS MVC. This wasn’t in the spirit of what Fubu is trying to promote and is very limiting. Thanks to some help from Emil Cardell, he and I paired up and were able to come up with a way to ensure that the Spark View Engine can be used in the same way as the Webforms View Engine can be.

Chad Myers has already created a partial port of the nerd dinner application called fubudinner on github where he’s demonstrated an example of grouping features together under a common folder using Webforms. He’s called his “Actions”, but you can call them what you like - “Controllers”, “Areas”, “Slices” – whatever. Personally I like calling them “Features” because that’s exactly what they are – single isolated pieces of functionality that can be worked on: view, controller, view model – all in one place with no need for mundane mental navigation.

I’ve added to the Hello Spark sample, showing just how easy it is to nest your views alongside your controllers. Notice that you can actually mix and match where you store your files because Fubu’s conventions don’t work upon where your files are stored, but rather around the properties of the files – which means conventions are storage independent.

From the picture on the right, you’ll see the areas highlighted in red are stored according to the MS MVC convention of Controllers in one folder, and Views somewhere else in a Views folder. That means that when you’re working on a particular feature, you’re jumping between these two locations.

Now extrapolate what is only five or six controller-view parings in that sample - out to hundreds. That scroll bar is gonna get a lot thinner and you’re going to need a new mouse scroll wheel pretty soon.

The area I’ve highlighted in green is the new support that has been added. Notice that the Controller, View and View Model are all in the same folder representing the “Fifth Element” Feature. The “AnotherDimension.spark” view is linked by convention to the AnotherDimension method inside the FifthElement Controller because they share the same name and you can add more views that represent other methods of this feature in that folder or sub folders – or anywhere really.

Partials can be added here too, and you can even create a local “Shared” folder for common view components used in multiple views of the feature, or you can still store your shared views in the overall “Shared” Folder and reference them from the Feature folders without any issues.

This give you tremendous flexibility in setting up team conventions that are intuitive and allow a more productive way of working. I’m not trying to convince you to use this strategy – I’m just tying to explain why you should care. And the next time you’re scrolling through hundreds of files because your solution is *that big* after a year of working on it and you’re wondering if there could perhaps be an easier way…well now you know there is.

Sold! How do I use it?

It’s actually easier than you think – just check out the sample. As was the case before, if you have a “Views” folder in your application root, it is included by default. The framework code has now been sorted out in such a way that you only need to include the following in your Registry to add another folder to let Spark know to look there:

public HelloSparkRegistry(bool enableDiagnostics, 
                          string controllerAssembly, 
                          SparkViewFactory sparkViewFactory)
    : base(enableDiagnostics, controllerAssembly)
{
    _sparkViewFactory = sparkViewFactory;

    AddViewFolder("/Features/");

    Actions.IncludeTypesNamed(x => x.EndsWith("Controller"));
    AttachViewsBy(
        actionType => actionType.Name.EndsWith("Controller"), 
        action => action.RemoveSuffix("Controller"));
        
    Output.ToJson.WhenTheOutputModelIs<JsonResponse>();
    Output.To(call => new JavaScriptOutputNode(GetJavaScriptViewToken(call), call))
        .WhenTheOutputModelIs<JavaScriptResponse>();

    HomeIs<AirController>(c => c.TakeABreath());
}

Oh – and you can add any number of these “AddViewFolder” calls, so it really is up to you where you want to store your views, and as you can see, Controllers are located by the conventions in the code above too, so it doesn’t matter where you store them either. Spark and Fubu work together to pair up views with controllers according to your wishes and you get some pretty neat conventions out the other side. You don’t need to tell Spark about each of the feature folders, just tell it about the root folder and it’ll dig through without any further help.

Conclusion

As I said before, I’m not trying to convince you that this is the right way, it’s just another way, and one that I think works very well for bigger teams and large projects. Use it, don’t use it – your call, but at least it’s there for the day you decide this is the way you want to go.

Until next time…
Robert The Grey

Elegant MVC with Spark - The way views were meant to be

noreply@blogger.com (Robert Greyling) — Fri, 27 Aug 2010 13:51:00 +0000

I’ll be doing another online presentation next week. The same guys who organised the very successful mvcconf.com, have asked me to talk more in depth about the Spark View Engine in the MVC space, only this time for c4mvc. It’s a similar format using Live Meeting, but this time I hope to record it locally to avoid the lag from the previous recording.

I didn't quite manage to finish turning Spark all the way up to eleven last time and ended up leaving out some of the more exciting bits and so I hope to give you more than your money's worth in this session. SparkSense will also be used throughout if you'd like to get a glimpse of how it's progressing so come along if you’d like to find out more…

Here are some of the things I’ll be covering this time:

Abstract

Many developers are desperately unsure when it comes to choosing a view engine to use when building MVC applications. A lot of them liked it better when there was only one the choose from with ASP.NET MVC, while others didn’t really like the idea of being saddled with the WebForms baggage they’d heard about or worked with in traditional ASP.NET. Many are now looking to Razor to save the day, but most haven't yet seen what's been sitting right under their noses.

When it comes to the Spark View Engine, you can easily go back to true separation of concerns between View and Controller. Come along and watch demonstrations of seldom used, but powerful features of Spark including:

Bindings support for more elegant looking HTML
Transportation of your views client-side via JavaScript for faster pages
Integration with and migration to FubuMVC
Time permitting – Pre-compilation of views for easy deployment

Watch it with bonus content!

Yes it’s true, the episode is now live for you to watch at your leisure! And I’ve also taken the liberty of adding bonus content that we didn’t quite get to in the talk. If you had a dismal experience in the talk because the bandwidth just wasn’t keeping up with my frantic flicking between screens, then you’ll want to watch it from the start.

For those of you that watched it live, and are not in the mood to watch the whole thing again, here are the details of where I’ve added the new content.

at 37min 20sec is a 6 minute addition that shows the fix for the Spark Bindings Demo that didn’t work properly because of my silly mistake;
at 58min 30sec is a 45 minute long show and tell on exactly how to migrate and ASP.NET MVC project using Spark over to FubuMVC using Spark.

Without further ado, here is the video:

or you can also watch it direct from viddler. And if you want to watch it on the go (iPad etc.) you can download the original 1024x768 (168MB) mp4 version.

I hope you enjoyed it and I look forward to “all sorts” of feedback in the comments.

Robert The Grey

Spark Bindings – are you tired of eating “Tag Soup” yet?

noreply@blogger.com (Robert Greyling) — Thu, 19 Aug 2010 00:11:00 +0000

Since giving my talk at mvcconf, I’ve received numerous requests to talk a little more about the mysterious Bindings feature in Spark. To be clear, it’s only mysterious because it’s the newest feature in the framework and because of lack of documentation – that is until now. Louis Dejardin has outdone himself once again and put a very thorough piece of documentation together for this. I’m not going to rehash the official docs here, but instead suggest

where the practical application of this feature can lead to some very clean looking HTML indeed.

Where we came from

Ever since moving to writing code in Active Server Pages Classic(TM) coming from plain old HTML, I’ve always let out a small grimace every time I’ve been forced to write code in my views. At first it seemed like an awesome idea, and it was, but if you were working in ASP Classic way back when, then you’ll remember how easy it was to tie yourself in knots and burn gaping holes in any deadlines you may once have held dear. And you definitely didn’t want to be the unlucky sod dumped in the support team after delivery. Been there, done that - It hurt…a lot…

Moving to ASP.NET we were shepherded into an event driven “code behind” desktop-programming-esque way of building web pages, but you could still put some pretty compelling spaghetti code in the views that could thwart even the most nimble of code jockeys. Nowadays, we’ve become pretty numb to it, but if you dig deep enough, I’m sure you’ll still feel that pang of regret every time you serve up a fresh bowl of Tag Soup.

And so, we’ve been on this search… nay… pilgrimage to find the ideal mix of beauty, simplicity and power for creating the web user interface effectively without bastardising the mark-up readability, and at the same time, not sacrificing the hooks into the back-end server processes that web pages tend to rely on so heavily these days.

Without further ado, I present thee with Spark Bindings, the latest ingredient in the Spark View Engine picnic basket that will help make your views beautiful once again…

Show and tell

The best way to grok Bindings is to think of it as an IoC Container for your HTML - or a Mapper if you’re not into IoC, and if you’re not into IoC, then shame on you ;). For those with an IoC mindset, you’ll be no stranger to something like this in your Registry:

    For<IFooInterface>().Use<FooConcreteType>();

Or for those who think in terms of mapping

    Mapper.CreateMap<ModelType, ViewModelType>();

Basically you can see where I’m going here and in the simplest sense, Spark Bindings is a substitution engine where in can stipulate that Spark should comb your HTML and perform the substitutions that you specify. For example, you can stipulate that everywhere Spark sees something like:

    <TextBox For=”UserName” />

it should actually use the following HTML Helper behind the scenes:

    Html.TextBoxFor(x => x.@For)

where “@For” is the parameter with value “UserName” you specified in your HTML as an attribute. NEAT! Isn’t it?

You see – this gives you the power to create or use existing HTML helpers of all descriptions in your assemblies that are normally invoked in a single line of code, and instead of polluting your HTML views with code bits and pieces, you can get clean looking HTML like this:

<Form class="form-default">
    <ValidationSummary Message="Login was unsuccessful. 
    Please correct the errors and try again." ExcludePropertyErrors="true" />
    <div class="editor-label">
         <Label For="UserName" />
    </div>
    <div class="editor-field">
         <TextBox For="UserName" /><ValidationMessage For="UserName"/>                
    </div>
    <div class="editor-label">
         <Label For="Password" />
    </div>
    <div class="editor-field">
         <Password For="Password" /><ValidationMessage For="Password" />
    </div>
    <div class="editor-label">
        <CheckBox For="RememberMe" />
        <Label For="RememberMe" />
    </div>
    <input type="submit" value="Log On" />
</Form>

Let’s quickly go through the interesting bits of the example above. The first thing you’ll notice is that it’s very difficult to spot the code – the abstractions (i.e. Bindings) are doing a very good job of blending in with the HTML, you know, exactly the way HTML was always meant to be! ;)

Secondly, I’m sure you noticed that you probably haven’t ever seen an HTML <Form> Tag without and action attribute or JavaScript hook of sorts right? And you definitely know that there’s no such thing as a <ValidationSummary> Tag in the HTML spec right? That’s right, you can both overload existing HTML Tags (with extra attributes or provide conventions for existing attributes) and invent new Tags of your choosing and bind those to the code you’d like to substitute in their place.

Any parameter that you may have for your HTML helpers can be fed through attributes and child nodes. You can keep it as simple as you like, or turn it up to eleven and really unleash the power under the hood here. The point remaining – it will STILL look and feel like HTML, instead of code. I won’t be able to go into all the powerful things you’re able to do in one post, but I hope I can give you enough of a taster that you’ll want to try it out for yourself.

Power of Abstraction

From the above code, you see that there could be absolutely any line of code hiding behind that <TextBox For=”UserName” /> binding. You don’t have to use an ASP.NET MVC helper, you could hook up the FubuMVC HtmlTags implementation instead if that’s what you prefer. Do you see that by binding these, you have just been provided with a way to write your views once, and replace the code bits behind the bindings with an entirely new library of product helpers simply by modifying the Bindings.xml – telerik anyone?

Power to Invent new HTML Tags

Don’t think of it as being limited to making HTML Forms prettier. You can also see from the code above that you’re able to create other HTML Tags you’ve always wanted! If you want a <FizzBuzz> Tag, there’s nothing stopping you. What’s more is that by putting that Tag abstraction in, this give you the freedom to replace your FizzBuzz Helper with your new and and improved FizzierBuzzing Helper at a moments notice throughout your views just by modifying the Binding in the xml. But that’s just the start. This thing has oodles of untapped potential under the hood…

Power to Augment existing HTML tags

Let’s say you’re not particularly fond of the idea of adding a <Link> or <ActionLink> Tag to your arsenal because you think the Anchor <a> Tag in HTML is perfectly good for links, but you’d really like the ability to hook that up to the Html.ActionLink() helper built into ASP.NET MVC or the this.LinkTo() helper built into FubuMVC. Why should you have to go and create a new Tag then? Well, with Spark Bindings, you don’t - just put an Anchor Tag into your view like this:

<a action="Register" title="Register">Register</a>

… and the Bindings will take care of the rest. Notice that the “title” attribute is already part of the HTML Spec for the Anchor Tag, and will simply pass straight through the Spark Bindings parser like magic and render just fine on the other side. You’ll also notice that it does not have an “href” attribute but instead, we’ve invented a new “action” attribute which Spark Bindings will feed into the HTML Helper and get the rendered output from that before rendering to the view.

Simple, but remarkably powerful and tidy.

OK, OK! What does this Bindings.xml look like?

Well, firstly we default by convention to looking in the root “Views” folder but this can be overridden if you like – just check the documentation. Then you start by wrapping all your <element> definitions inside a root <bindings> element. This is best demonstrated by example, so here’s the simple binding for the Label Html Helper:

<bindings>
  <element name="Label">Html.LabelFor(m => m.@For)</element>
</bindings>

Then you can get a little more complex. Here’s the binding for the CheckBox Html Helper:

<element name="CheckBox">
    Html.CheckBoxFor(m => m.@For, 
    new Dictionary[[string,object]]{{"@*"}})
</element>

What the HECK is that freaky looking Dictionary thingy?! Relax, that’s nothing to do with Spark Bindings, that’s the Dictionary parameter that comes with the Html Helper and Spark is just being a good citizen and allowing you to pass that through to the other side and the “@*” is just a wild-card means of passing the values back out the same as they came in. But you can check the documentation for further details.

Next, let’s have a look at how we managed to simplify the Form Html Helper – that one has kept many an ASP.NET MVC developer awake at night:

<element name="Form">
    <start># using (Html.BeginForm("@action", "@controller", 
        new RouteValueDictionary{{"@route-*"}}, 
        FormMethod.@method, 
        new Dictionary[[string,object]]{{"@*"}})) {
    </start>
    <end># }</end>
</element>

There, now aren’t you glad we caught that closing curly brace for you and replaced it with a nice </Form> closing Tag? :)

Power of Overloading

But that’s not all. What if you liked your perfectly good FizzBuzz Helper, and only wanted to change to your new FizzierBuzzing Helper in certain places in your project – well you’ll be happy to hear that multiple overloads are supported for any HTML Tag, which means that all you need to do is create an overload in your Bindings.xml and differentiate the two somehow with a flag or parameter of sorts, and then only add that flag to the parts of the project you’d like to use the second version in.

Here are 4 different Overloads for the standard Anchor <a> Tag and they are ordered from most specific to the least specific in terms of parameters – this is how the Bindings knows which one to pick – it picks the first one where all parameters are satisfied. So you need to put your most specific overload at the top:

<element name="a">
    Html.ActionLink("child::*", "@action", "@controller", 
    new RouteValueDictionary{{"@route-*"}}, new Dictionary[[string,object]]{{"@*"}})
</element>
<element name="a">
    Html.ActionLink("child::*", "@action",
    new RouteValueDictionary{{"@route-*"}}, new Dictionary[[string,object]]{{"@*"}})
</element>
<element name="a">
    Html.ActionLink("@text", "@action", "@controller", 
    new RouteValueDictionary{{"@route-*"}}, new Dictionary[[string,object]]{{"@*"}})
</element>
<element name="a">
    Html.ActionLink("@text", "@action", 
    new RouteValueDictionary{{"@route-*"}}, new Dictionary[[string,object]]{{"@*"}})
</element>

You’ll probably recognise the “child::*” syntax if you’ve ever worked with XPath queries. This is where it gets its roots and it’s nothing to be afraid of. It is basically indicating to Spark that this Binding element definition is not just an element like a self closing <br/> Tag, but that it will contain child content that needs to be processed as well. This allows you to put Spark code or calls to Macros inside your elements in the view. Something I intend to elaborate on in a deep dive post.

For Html Helpers that return void, simply call them by putting a # up front like this:

<element name="Partial">#Html.RenderPartial("@name", new ViewDataDictionary{{"@*"}});</element>

Can I have multiple Bindings.xml in a project?

Ah, so you’re thinking maybe about supporting themes or perhaps want to have elements render differently in different parts of the same site? Well yes you can. Spark provides an IBindingProvider service that allows you to direct how Bindings are located, and this can be done down to a view by view basis. I’ll have to save that topic for another post though since that’s slightly more in depth and you’ve probably already fallen asleep by now ;) Let me know via the comments though if this is a particularly burning issue for you and I’ll see if I can get it done sooner…

Now you’re just being silly!

I’m sure you’re all going to find new and even more interesting ways to use this feature. I can’t take credit for this one and it’s one of the more, shall we say, creative examples that Lou came up with for his ND2010 talk. It’s basically a text colorizer that uses an Html Helper to build <span> Tags of text across a spectrum of colours between a min and max colour that you specify as parameters to the Helper. The Html Helper looks like this:

public static object Colorize(this HtmlHelper html, string text, Color min, Color max, double value) {
    var color = Color.FromArgb(
        Range(min.R, max.R, value),
        Range(min.G, max.G, value),
        Range(min.B, max.B, value));

    var tagBuilder = new TagBuilder("span");
    tagBuilder.SetInnerText(text);

    tagBuilder.MergeAttribute("style", "color:" + ColorTranslator.ToHtml(color) + ";");
    return MvcHtmlString.Create(tagBuilder.ToString());
}

private static int Range(int min, int max, double value) {
    return min + (int)((max - min) * value);
}

and then we invent a new HTML Tag for use in our view – let’s call it <spread> which maps to our new Html Helper, and we add it to our Bindings.xml like so:

<element name="spread">Html.Colorize("child::*", @min, @max, @value)</element>

So now we make a call to our new Tag in the Spark HTML view like this:

<p>You're kidding right? -->
    <var words = "new[]{'O','oo','h',' Lo','ok ','at ','al','l t','he ','pr','et','ty ','co','lo','ur','s'}" />
    <spread 
        min="Color.Green" 
        max="Color.Red" 
        each="var x in new[]{.1,.2,.3,.4,.5,.6,.7,.8,.9,.8,.7,.6,.5,.4,.2,.1}"
        value="x">${words[xIndex]}
    </spread>
</p>

Now what you see above is a little bit naughty – in reality the “words” array will come from your strongly typed view model as something like “Model.Words” and likewise with the array of values, but I put it in the code here so that you can a clear picture of how we got the output you see below. Equally, the “Color.Green” and “Color.Red” values, as a best practice should come from something like “Model.Min” and “Model.Max” so you get the idea right? KEEP THE CODE OUT OF YOUR VIEWS… m’kay?! :)

Doing the right thing presents you with much prettier view code that looks something like this:

<p>You're kidding right? -->
    <spread 
        min="Model.Min" 
        max="Model.Max" 
        each="var x in Model.SpreadValues"
        value="x">${Model.Words[xIndex]}
    </spread>
</p>

And the output…

Nah, that’s just crazy! You wouldn’t actually do that would you? Would YOU?!

In reality, this isn’t necessarily something you’re going to do. What I’m demonstrating here is that you can control your rendering at incredible levels of detail and you can make your rendering subject to functions that you haven’t yet dreamed up! And that because the code is contained in class files behind the scenes, you’re able to control and unit test before they hit a view, and all the view has to do, is call out to those bits, but never has to get involved in the actual thinking.

This my friends is the way MVC views were always meant to be…

Don’t stop now…

I wanted to try and keep this post geared towards beginners or people that just want to get up and running quickly, but I’m not sure I’ve succeeded entirely in that undertaking. It may be worth doing a more in depth post highlighting some of the even more powerful possibilities of this feature, so let me know if that’s something you’d be interested in seeing and I’ll put something together.

But in any case, if you wanted to get the scoop on the syntax and provisions made by the parser for you to extend this feature, then I urge you to have a look at the documentation, set your mind free and start giving your views the makeover they deserve!

Also, if you’re looking for a more complete Bindings sample to play with, you can download it from the slides & samples downloads for the mvcconf talk I did in July.

And before I go, I’d like to say a personal thank you to Lou for creating such an awesome view engine and giving MVC web developers such an amazing experience! This Bindings feature is surely a crowning glory of sorts and I think it gives Spark an edge that really counts. Things are only going to get better…

And finally – look out for Bindings IntelliSense support coming soon to you via SparkSense…

Until next time…
Robert The Grey

I don’t want your stinkin’ code comments

noreply@blogger.com (Robert Greyling) — Sun, 15 Aug 2010 13:11:00 +0000

I just read a fantastic thought experiment being put forward and trialled by Jesse Liberty at the moment. I’ve written this post in support of that effort and to express my gratitude that he is putting his name behind it! I have to say that I 100% agree with his assertions in the article and I’ve been coding like this for the better part of four years now (even on large production systems with > 2 million LOC) without any of the “missing comment bogeymen” coming to get me or my team mates. In fact, existing comments in those systems have bitten us more than once – and hard!

Why?

Because as Jesse asserts, writing code without any comments forces you move away from the “write once” phenomenon and mentality. Uncle Bob says it best in his book (Clean Code) so I’d very much recommend that as a good reference. I agree that it seems ~~bloody impossible~~ tough at first, but this way of working is going to save you hours of heartache and more importantly that of your co-workers and those that come after you’re gone. “Do unto others” remember…

Let’s face it

Most comments you consider putting in code are either:

Stating the bleedin’ obvious (I’m looking at you Method Arguments)
Put there because you’re too lazy to refactor the code as demonstrated in Jesse’s article and the comments
Enforced by stupid corporate coding standard mandates that are still stuck in the 90s
Stale (and sometimes actively harmful) by the next check-in or 6 months later

Comments are an addiction, and it’s about time you kicked the habit. You only have so many keystrokes in you before you die, why spend them writing useless comments instead of useful code?

Going even further

There’s a reason I didn’t just write this up as a comment on Jesse’s post and that is because I really want to drive this particular point home. I would go even further than Jesse did, and remark that his experiment is doomed to fail. That’s because (and I admittedly don’t have enough info from the article) he’s missing a key ingredient in the formula that makes this experiment a success.
When you find the insane need to write a comment about the “why” of the code at the top of a method for example, or even worse inline – the simple fact is, you’re missing a Unit Test, or a BDD specification – depending on your preference. I’ve found after four years of executing on this experiment that you cannot possibly include all the “why’s” in the code structure because you end up with too many levels of abstraction which only end up being in place to talk about the “why”.
Now that’s fine for certain functional areas of the code, but you cannot possibly justify the time or man power to go all the way through. And besides, we found that you reach a tipping point where the human brain starts to find those heavily sequential abstractions hard to comprehend and piece back together in logical terms, which means you’re back to square one again – unreadable code.
Instead, why not raise a unit or integration test to prove that your code executes on that business rule or fact? That way, when other developers come to familiarise themselves with the code, they can open the code under execution and the exercising unit test code side by side, and get a really good idea about what the programmer who wrote it was thinking. They get the “What” and the “Why” in terms of source code that is easily refactored, debugged, augmented and added to over time without a ~~useless~~ comment in sight.
You see, the unit test is the “why” form of abstraction written in such a way that directly exercises a section of code, and it is the way in which it is written that gives it unique power to ask the “why” questions – something that is very difficult to replicate inside the code under test without implementing some kind of internal DSL. The very existence of the unit test means you can remove that complexity from your code and just let it execute the “What”.

OK enough with the philosophy – gimme an example!

Some folks just want cold, hard ~~facts~~ examples. Fair enough, I can understand that, but you need to understand that there are a billion permutations here and what I’m really trying to get the reader to do is ask the question: “Why am I thinking about putting a comment in here?”.
With that in mind, there’s no point in me putting an example up (since Jesse’s is perfectly adequate to illustrate the point) when people will in any case, just spend time analysing the code pointing out what I “got wrong” or how they would have done it differently. If that’s what you’re thinking about, then you’ve already missed the entire point of the article.

Exception to every rule

One thing I live by is that there is always an exception, and in my case this is true for what I call placeholder comments. These comments take a common shape:

//TODO: Rob G Make sure this goes into the logging pipeline when it’s finished
//BUG: Joe B – this is where [Issue:12345] is breaking the JSON call – Rob G needs to fix it after [Issue:9876] fix goes in
…and my personal favourite
//TAUNT: Rob G, do you realise that this section of code broke the build on Friday after you left for home? Team is looking forward to a beer next week on you after you’ve fixed this – Thursday any good?

That last one very much depends on the sense of humour in your team, but most importantly, these are short lived comments that DO NOT hang around in the code, but are too complex to write a unit test for – they may require many unit tests or simply make use of an orthogonal concern such as logging.
Tools like Resharper have windows in Visual Studio dedicated to tracking exactly these kinds of comments with a view to solving them quickly. They are also convention based and can quickly be searched for when you come in the next morning. Context sensitive messages can be left for fellow developers without the need for email, and I feel that this is one way you can get comments to work for you, rather than against you.
The only other exception I’m barely willing to accept is if you’re developing a public facing closed API that you HAVE TO produce documentation for otherwise they just won’t pay you. That’s a fair request and you can work that into your pricing, but let’s be honest, when was the last time you opened that .CHM file for someone else’s API and got any true value out of it that couldn’t be gotten more easily by writing a unit test invoking the API? And was the .CHM even up to date?

Conclusion

So ultimately, I’d like to say that if you don’t write unit tests (or have BDD specifications or similar), then please do write comments in your code – it’s the only way we’re gonna find out about the business rules you tried to implement in the code when we’re paid to come in after you’re gone to fix your mess. And it will be exponentially messier for each and every time you’ve blindly gone in there and changed the code without updating the corresponding comments – and don’t say you remembered to update them… I don’t believe you.
Anyone else found a good use for code comments…leave a comment ;) (pun intended)
Until next time…
Robert The Grey

SparkSense gets its first outing

noreply@blogger.com (Robert Greyling) — Mon, 09 Aug 2010 19:58:00 +0000

Well well well, some say “it’s about time”, but personally I say “it’s too soon”, but then again, that’s exactly what they say a beta period is for. There is so much work on the back burner here that I could just keep going for ages in my little cave, but I think it’s important to give SparkSense a little air, even if that means it only ends up being pushed back into its box.
My expectation is that the current beta version is not fit for use in a production sense – in other words, you’re not going to be that much more productive than writing Spark in a plain text editor providing you know the API fairly well. It’s not going to break or overwrite your code or anything like that, but I am still working on making sure it stays out of your way.

For this beta release, I have put a few “catch all” exception blockers in the code to basically make the experience a bit more pleasant. I remove these for development and fix as I go along, but I’m sure you don’t want Visual Studio telling you that an exception occurred in the plug-in every 5 minutes. These do still happen behind the scenes, but the nice thing is that SparkSense recovers from these without needing a restart, so if you do by any chance see one pop up, SparkSense will reset on the next keystroke.
If someone (currently going through a temporary, insane bout of masochism) would like a version without the safety net and would like to help me track down scenarios under which exceptions are thrown, then feel free to get in touch and I’ll get you a copy of the plug-in.

Supported

Basically, the current Spark API is supported and the plug-in will dig through your project and views finding partials, global & local variables, content areas and macros you’ve defined. The trouble with doing IntelliSense this way around (i.e. Spark API rather than C#) is that the VS2008 plug-in exclusively targeted C# IntelliSense, and now it’s gone! In exchange you get Spark API IntelliSense, but that might not be good enough for you.
So along with bug fixing and adding to the current features, the next big item on my list is to provide static C# IntelliSense so that you’ll have access to successfully compiled code from inside the views for which I’ll be using the DynamicTypeResolution bits.

Not Supported

There are always going to be unsupported bits in a beta release. If you see something here that you can’t do without, then it’s better that you don’t use the plug-in at all. I’ll be ticking these off my list one by one with each release.

As I said, C# IntelliSense in the HTML view is not currently supported, but it’s next on my list.
Also not supported yet are macro parameters.
I’ve built a lot of the signature recognition but I’ve turned it off for this release since it’s giving a few false positives that I need to fix first.
I’ve got a custom presenter in the wings, but I’ve turned it off until we really need and can use it.
Bindings support is also very high up on my list since it’ll be an invaluable feature as people begin to see the true power in them.
Custom settings support – things like reading from your project config for custom prefixes and binding providers etc.
Namespace prefixed elements – this will be fairly trivial to add once I’ve got the API bedded in.
I want to take community feedback on syntax highlighting which will change the colour of the tags and elements depending whether it’s plain HTML or Spark specific – not sure if this is valuable.

If you see anything that’s not on this list, but clearly missing, then please let me know and I’ll add it post haste!

Installation

I’ve managed to load the plug-in up into the Visual Studio Gallery and so you can just search for Spark from within VS2010 and it should be installable.

How to use it

Well, after it’s installed, you’ll need to ensure that you associate all *.spark extensions with the VS HTML Editor. This is how we make sure that we still get HTML and JavaScript support when editing, and we basically augment the completion session based on what is happening around the cursor. I’ve chosen a fairly simplistic icon set from the fantastic Yusuke Kamiyamane Fugue Icons Collection. This may change in future, but for now it suites its purpose.
You’ll notice in the screen grab below that I’ve used the (Alt+period) shortcut to filter Spark items only and it is showing some Partials (denoted with a “P” icon) and of course Spark specific elements (denoted with an “S” icon).

When we don’t have any HTML completion, then only the Spark completion options show up without the filter. This is the case below where Attributes are denoted where they are found with an “A” icon.

Where we’re able to predict the values of an attribute, as is the case with content areas, they will also show up with a context aware icon. This feature will get a lot more polluted when C# IntelliSense is completed.

Currently, the only IntelliSense available in the ${} syntax are variables and macros. This will of course also be subject to massive expansion once C# IntelliSense comes online.

Other than that, give it a whirl and let me know how it goes…

Bugs (Update)

It’s probably worth noting that Spark already has issue tracking in place – it would be wise if issues were logged in the same place so that they can be properly managed.

Conclusion

I intend to release updates every time I’ve either fixed a major bug or added functionality that I or the community think will be useful. As you probably know, getting all the plumbing working for this kind of thing is the tricky part. Adding features is a lot easier when you’ve got a pipeline setup ready to receive them. I look forward to pushing out updates fast and furiously mainly because I know that there’s a lot more to be done before we can say that SparkSense is actually a useful tool.
Until next time, Robert The Grey

Pragmatic Spark – Turning it up to eleven

noreply@blogger.com (Robert Greyling) — Wed, 14 Jul 2010 20:02:00 +0000

This is the title for the talk that I’ll be doing at mvcconf.com on 22nd July 2010. Registration was closed due to enthusiastic bombardment in the blink of an eye really, but you’ll be glad to know that they say the sessions will be recorded – and trust me, there are some crackers there you’ll want to watch for sure if you’re thinking of or already are working in the MVC space on Microsoft technologies. Hopefully mine goes well enough and I’ll post a link to the recorded session on here when it’s available. But if you are attending, or are interested in the agenda of my talk before watching the recording - you know, just in case it’s a waste of time :), then have a look below:

Abstract

Many developers are desperately unsure when it comes to choosing a view engine to use when building MVC applications. A lot of them liked it better when there was only one the choose from with ASP.NET MVC, while others didn’t really like the idea of being saddled with the WebForms baggage they’d heard about or worked with in traditional ASP.NET. When reviewing alternative view engines, mostly the reasons I hear for not using them are all along the lines of:

Lack of documentation
Lack of training material
Lack of example applications, especially “real-world” parallels
No Visual Studio tooling support such as IntelliSense etc.

Very seldom has it been a case of “My boss won’t let me”. Well, when it comes to the Spark View Engine, I intend to help close that gap considerably and help developers make informed decisions when deciding on parts of their technology stack. Spark is already 90% there on the documentation front, has a metric ton of training material and examples out there, albeit hard to find and centralize and I’m currently getting ready to put the first beta of Visual Studio IntelliSense support for Spark out for ~~guinea-pig~~ public consumption. Come along if you’d like to find out more…

Agenda Points

Time permitting, these are the things I’d like to cover during the session:

Visual Studio Integration – SparkSense stretches its legs
Getting your Spark on – From setup to solution structure to layout design
Implicit Partials – By convention, not Html.RenderPartial
Macros – The hidden power tool of the view
JavascriptViewResult – Getting your view logic client-side for free
Output Caching – Pick a shape, any shape – Donut Sir?
Bindings – No not Model Binders, something much more interesting
Hand-holding with FubuMVC – oh how nicely they play together

In closing

If there’s something that you’d particularly like to cover in this session that I haven’t mentioned above, then you’ve got a small window to get your requests in and I’ll see what I can do. Otherwise, I hope you enjoy(ed) it and I look forward to “all sorts” of feedback in the comments.

Update

The slides and code examples from this talk can be downloaded from here, and the recording can be viewed here. Unfortunately the quality leaves a lot to be desired since the recording was going across the Atlantic which resulted in a fairly delayed experience. I would guess that the visual is about a 5 second lag behind the audio which is unfortunate because I've actually seen it accidentally change the meaning of something I said once or twice.

In addition, there were two pieces I didn't actually have time to get to in the time slot which were JavascriptViewResult and FubuMVC integration. As a result, I'll be doing this same talk again on 1 Sept 2010 for C4MVC and this time with lessons learnt, I'll be recording locally to produce better audio/video and I'll be able to focus more on the pace in order to get all the content in.
Until next time
Robert The Grey

Is Razor just a wolf in Spark’s clothing?

noreply@blogger.com (Robert Greyling) — Sun, 04 Jul 2010 23:41:00 +0000

Coming soon

ScottGu just announced the pending arrival of the new View Engine for ASP.NET codenamed “Razor”. This has been met with some diametrically opposed views (no pun intended) and there are definitely three camps emerging – those that hate it, those that love it, and the rest that just look like they’re watching a tennis match with very little emotional investment.
I read the announcement with intrigue and mixed emotions if I’m honest, and so, in order that I can stop banging on about it, I decided to get it off my chest and put down my current thoughts.

Disclaimer

Razor is not even out yet, but will be in beta soon we’re told – and so for goodness sake, please take this writing as it is meant: Constructive feedback on what we’ve been told so far about it, and hopefully some of these ramblings will feed into the product to make it better and change some of the things I’ve spoken about below:

First the good points

You have to give credit where it’s due, and it looks like from the screenshot that the team is adding default support for Spark and NHaml to the project/view templates tooling – exciting news indeed since that will at least give them a fighting chance!
The design goals for Razor that ScottGu mentions include that it’s “easy to learn” and “has a low concept count”. I think this is very true for current webforms MVC developers and will be a big plus point. Getting rid of the markers (<%= %>) is indeed a welcome change and making it smarter about multi-line code blocks using minimal markers will be a great time saver and improve readability in a massive way!
I don’t think the point about being “unit testable” will carry much weight with the large majority – but you never know, it may be the start of a general trend for the average developer in the .Net realm. But don’t go holding your breath now you hear? The part about “works with any text editor” is just marketing fluff, c’mon Scott, I expect better from you :) – I can write webforms or a C# class in notepad too you know – but I won’t, and neither will Razor users.
But by and large, those who are used to working with webforms in MVC will find the transition pretty refreshing I would have thought. This will be giving the hundreds of thousands of “walled garden” Microsoft developers some exposure to a what is undoubtedly going to be a better view engine overall than webforms – that in itself is justification alone as far as I’m concerned.
That particular group of developers are the kind that are never likely to read this blog post or try Spark, or fire up bash and push their changes to github, or know how pleasant it is to crank open a Ruby on Rails or FubuMVC project and have the conventions lead you unerringly towards your goal – a finished and tested product. Why stop them then, getting access to a view engine that is clearly going to beat the pants off of webforms?
Simple answer – don’t – they should move, and they will. If anything, it’s going to open the eyes of many developers to the possibility that more than one view engine is even possible! I was lucky enough to be brought up in a fully bilingual environment and I fully understand the benefits of the knowledge of more than one and how powerful that can be. It made picking up a third and fourth spoken language very easy for me where those who have never been exposed found it very challenging as an adult.
I’m willing to bet that the same thing will happen here, and that by promoting a second view engine (Razor) will awaken those developers to the idea of perhaps exploring even further than that! Once you know two, the third is a piece of cake. Then go ahead and provide good tooling support and it’ll be a dead cert!
But wait, there’s more! Two words: “The Enterprise” – Razor will no doubt come with the big blue badge of approval, and because of that, large companies (and the developers that work for them) will be able to adopt something better than they’ve got today. This is a step in the right direction folks, let’s not lose sight of that. The Enterprise is a big ship with an even bigger wheel, and it’s never been easy to turn that sucker.

Spark’s clothing

OK now let’s talk turkey - it’s painfully obvious that Razor has gotten many of its design cues from the Spark View Engine. I’m not only talking about code, because that’s clearly what most people think of first when they hear it said. I was vey careful when I chose the words “design cues”, but I’m pretty sure I’ll be roasted alive if I don’t give concrete examples, and I will, so just calm down for now…
The Spark philosophy is to “blend in” with HTML so that it looks cleaner and can stay out of your way. Now I’m not suggesting that Razor will “get in your way” – no, but it will be obvious which parts of the code are HTML and which parts are Razor blocks – just like it is in webforms today. That’s fine, many people actually prefer it that way.
I’ve heard people say that their designers get confused by seeing HTML tags (Spark) that they don’t recognise and so don’t know what to do with them. I disagree, but it’s a fair comment, and I think there’s no arguing that this particular thing comes down to personal preference, team composition and developer knowledge and skill.

Code oriented vs. Mark-up oriented

Many are saying that Razor and Spark are two sides of the same coin. Razor would appeal to the more code oriented developer, whereas Spark would appeal to the more mark-up oriented developer. I’m not quite sure what that means, but it sounds like a bit of a ~~load of crap~~ cop-out if I’m honest. My feeling is that if you’re a web developer, you work with code, and you work with mark-up. The goal you’re seeking to achieve is separation of concerns, which means business logic does not belong in the view.
“Now which do you think is more likely to keep the business logic out of the view – Mark-up oriented, or Code oriented?”
And yet insistence that Spark is all about HTML mark-up extensions clearly comes from those without much experience with Spark. Spark can also be written in such a way as to define all the display logic via a code oriented means. Being able to do this doesn’t mean it’s a good idea, it’s just a testament to the power and flexibility of Spark.
Spark does this using the statement marker #, which you can change from # to an @ in your Spark configuration if you’d like it to look Razor-like, but there is a clear and present danger inherent in doing this and it is only provided in Spark for completeness and for the times when that edge case is really biting you hard! By bringing C# and VB to the view, you are dishing out a copious amount of rope for inexperienced developers to hang themselves (and those that follow) with.
This is nothing new – I see it every day in webforms. All this new syntax is going to do is encourage even more developers to (unwittingly) embed more of their business logic in their views because now it’s actually capable of looking somewhat tidy, whereas when <%= %> were strewn throughout the view, they would tend to use it sparingly, partially just because it looked so ugly. Now it’s gonna look pretty – fantastic news! </sarcasm>

Enter the wolf

What this basically boils down to is answering the question of whether or not the View Engine is being true to the “V” in MVC.
If you’re querying DateTime.Now.Year == 2010 in your View, you’re doin’ it wrong! For heaven’s sake, that comparison should be a property on your view model! And don’t say it’s just an example – people actually do this!
Well - you might say - if Spark and Razor are both capable of allowing the developer to make those mistakes, then it’s the developer’s fault since neither view engine can prevent it! That may be true, but what’s also true is the spirit in which it’s done.
Spark actively discourages this behaviour by limiting the syntax it recommends you use in the view, and providing powerful ways with which to work with the concerns of the view model and display logic – but it tries hard to stop you there, and that is a good thing! You should be doing the rest in the “Model” and “Controller” parts!
Razor actively sells it! It SELLS the fact that you can write code in your view as a good thing! And in the same way that warning leaflets were not handed out at the door with webforms, Razor will find its reputation equally tarnished by developers who just don’t know any better! IF you use Razor correctly, in the true spirit of MVC, you won’t find a use for half of the code blocks they’re pushing. Your views will actually look very HTML-esque with very few code blocks, and those code blocks will be true to working with the view model and display logic. Why then sell the fact that you can write code in there? Rather spend your time training developers in the right way to do it…

Apples with Apples (and Oranges)

A promised, I’m going to compare and contrast Razor and Spark with examples. Now I don’t want to speculate about Razor, and so I’ll be using those provided by ScottGu in his post rather than making them up. I’m also not going to labour this point too much because it’s not the point of the article. The point is giving developers the tools and understanding to execute the MVC pattern effectively with an exceptionally high degree of future maintainability. We know from bitter experience that writing a heap of code in your view does not achieve this goal:

Razor	Spark in code	Spark in mark-up
Loop through a list of products
<ul> @foreach(var p in products) { <li>@p.Name</li> } </ul>	<ul> #foreach(var p in products) { <li>${p.Name}</li> #} </ul>	<ul> <li each=”var p in Model.Products”> ${p.Name} </li> </ul>
If Statements
@if(products.Count == 0) { <p>Sorry - nothing</p> } else { <p>Got it!</p> }	#if(products.Count == 0) { <p>Sorry - nothing</p> #} else { <p>Got it!</p> #}	<p if=”products.Count==0”> Sorry - nothing</p> <else> <p>Got it!</p> </else>
Layout/Master page selection
@{ LayoutPage = ”Products.cshtml”; }	There’s no point really, but can be specified in code by the Controller	<use master="Products"/>
Rendering specific sections
@RenderSection(“header”, true) @RenderBody() @RenderSection(“footer”, true)	#Content[“header”] #Content[“body”] #Content[“footer”]	<use content=”header” /> <use:body /> <use:footer />
Section definitions
@section footer{ <div>home footer</div> }	No point in code for something this simple, but Spark has two concepts: <content> and <section> left as a research exercise – you’ll love it ;-)	<content name=”footer”> <div>home footer</div> </content>
HTML helpers
@Html.LabelFor(m => m.ProductID)	#Html.LabelFor(m => m.ProductID)	${Html.LabelFor(m => m.ProductID)}

And so on…I could go on, but is there any point? As for the “Declarative HTML Helpers” mentioned in ScottGu’s post, I could also go into a long diatribe about how that is completely covered (and then some) by using the power behind Spark Partials and Section declarations as well as Macros, but I won’t because I think I’ve already made my point.
All I’m trying to do here is just show those people who can’t be bothered to do the research, but feel like they can speak with authority when they say that Razor and Spark look nothing alike.
Nuff said…

Open Source

Now I know this is gonna sound crazy, but hear me out – no wait, I can’t suggest it – forget I said anything…let’s just move on. Oh, really? Oh alright then, but I’ll whisper in case someone hears… what if…shhh…what if Microsoft asked if they could pick up and contribute to the refinement and expansion of Spark for example? Heck, the primary author works for them after all!
I know…silly idea isn’t it? Don’t tell anyone I mentioned it please. In all seriousness though, there’s no doubt in my mind that this conversation came up internally, but I don’t think the real reasons for deciding against it will be forthcoming any time soon.
I’m mostly confused because it boils down to resourcing. It stands to reason that Microsoft has put ‘X’ resources full time onto this project. Those resources had to start from scratch and (I’m willing to bet body parts) took many design decisions from Spark (and probably NHaml and NVelocity). Given the similarities, and since Spark already supports the things that Razor does (albeit slightly different), I can only imagine that they didn’t do it because they wanted ownership of their own thing, or were fearful about partial ownership (and therefore not total control) of an existing OSS code base.
I’m all for the idea of building things of value, and I’m fairly sure that Razor will end up being just that, but I fail to see why Microsoft didn’t see the value already out there (as they did with jQuery) and put their oversized and underused muscles behind it. I’m trying my best to reserve judgement right now because this thing hasn’t even come off the showroom floor yet, and perhaps there is something huge that we don’t know about that has prevented this scenario from playing out – but that remains to be seen. Perhaps the way they’ve done it is a good hook for control library vendors to get stuck into it?
Or, maybe this will just go down as yet another opportunity they’ve missed to earn their stripes in the OSS community at large – I mean, what the hell else is codeplex.org for anyway?! In the end, the truth will out, so for now it’s a waiting game…

Conclusion

As you can see, I still think the jury’s out on this one, and we’ll have to wait and see what comes out further down the line. I know that many people in the adjacent Ruby and Java communities etc. are of the opinion that very little innovation has been forthcoming from Microsoft in the last few years and I tend to agree to some extent, but something that I’m acutely conscious of (working with large Enterprises almost daily) is that they are massive ships, and take an absolute age to turn in any direction. For better or worse, this has been (and probably will be for some time) Microsoft’s key area of focus.
One thing is certain in my mind though – ScottGu is a leader and an innovator and I think he’s the right guy to be driving this kind of thing. He is a ship turner and there are very few people out there who can lay claim a title like that. So I’ll give them the benefit of the doubt for now and in the end, having more choice can’t be a bad thing and if that’s all this ends up being, then so be it.
I do however personally think, that Microsoft should stand up and say a big public “thank you” to the NHaml, NVelocity and Spark developer communities for solving this View Engine problem for them on the ASP.NET platform and paving a fairly easy path to what could be a successful product. The absolute height of arrogance would be claiming Razor as their own de facto brainchild.
There, now I feel much better…
Until next time
Robert The Grey

SparkSense: Getting started - where’s a plumber when you need one?

noreply@blogger.com (Robert Greyling) — Tue, 25 May 2010 12:31:00 +0000

This post is part of a series and you may want to read them in order.

First things first

If you’re gonna be building an extension to the Visual Studio 2010 Editor, you’ll be needing a couple of resources – and little did I know how scarce those would turn out to be. Microsoft have started what looks like, could be a promising set of documentation around extending the VS2010 editor. There are err… how can I put it… a few obstacles to overcome though when wading through it all.

For example, the information surrounding the code examples and API descriptions they’ve put together run about as deep as a river through the Atacama Desert. They skim over details where elaboration is crucial to understanding, and they elaborate in other areas which just end up stating the obvious. Sometimes it feels like there’s a chimp mashing the keyboard on the other side of these documents.
The code samples themselves are also of appalling quality, violating about as many SOLID principles as you can count on two hands…oh wait, there are only five. But then again, I guess we can’t expect them to everything for us – we need to earn a crust somehow. Just take it as a word of warning, that significant refactoring will result from a copy+paste job from here if you want to produce something maintainable.
Another big problem I have with the documentation is the MEF imports. Don’t get me wrong – I’m a massive fan of MEF, but when one of the code examples for say, creating an IVsTextViewCreationListener for signature recognition, they expect you to somehow know (by osmosis) that you’ll be needing to let MEF know to bring along an instance of IVsEditorAdaptersFactoryService for moral support. And what does an IVsEditorAdaptersFactoryService do exactly pray tell? I shit you not, MSDN has this to say:

“Represents a factory service for creating editor adapter objects, and mapping between the adapter and the underlying new editor objects”

Aha…well why didn’t you just say so? That kind of sentence could easily end a game of “Architect Bingo” midstride. I don’t know about you, but this just doesn’t cut it for me when it comes to proper documentation, and building software this way can only be compared with walking through a cave blindfolded, being led onward by a sadistic mute, never indicating when the ceiling suddenly slopes.
I’ve come to expect this kind of rubbish over the years from MSDN in general, and I’m not sure why I thought this time would be any different. As luck would have it though, and as I said in my introduction post to this series, there has been some brave pioneering in this area before me.

No shortcuts

I’m afraid it’s true though that until a decent book comes out about this stuff, you’re pretty much going to be stuck with blog posts and knee deep code wading sessions. The best I can do here is outline a skeleton structure to start with and hope that the MSDN documentation catches up one day – although I’ve probably got more chance of falling pregnant. Other than that, it’s code spelunking where others have gone before.

Moving parts

Depending on what you’re planning to deliver with your IntelliSense Engine, there may be various pieces you may be looking at. I would like to deliver SparkSense with the following components to start with:

Statement completion – basically dig out all the right keywords and variables to use at the right times when writing code;
Signature recognition – documentation that appears while writing code providing API assistance when it comes to known terms;
Quick Info – tooltips that provide simple documentation about elements when hovering;
Custom Presenter – This allows for better filtering of Spark keywords from HTML keywords etc.

Plumbing bits

In order to get the meat of your particular code going, there are a few bootstrapping items that need taking care of. For each of the moving parts above, the VS Team have provided some hooks to get in on the VS Editor pipeline. There is at least a measure of consistency here when it comes to the API at least in terms of convention which is promising.
You’ll be using MEF to listen for specific signals, and then at that point, use those listeners to pull in additional services and spin up the implementation instance for the particular piece you’re working on. I’m trying to use general terms here in order to emphasise the conventions being used. Those familiar with Service Location breed of patterns should find it fairly simple. Let’s go through some concrete examples:

For statement completion you’ll derive from ICompletionSourceProvider and use that instance to instantiate your own derived ICompletionSource.
For signature recognition you’ll derive from ISignatureHelpSourceProvider and use that instance to instantiate your own derived ISignatureHelpSource.
For quick info you’ll derive from IQuickInfoSourceProvider and use that instance to instantiate your own derived IQuickInfoSource.
For a custom presenter you’ll derive from IIntellisensePresenterProvider and use that instance to instantiate your own derived IPopupIntellisensePresenter (and IIntellisenseCommandTarget for keyboard support).

Seeing a pattern here? Now that we have a Provider and Source, you’ll be able to actually build and provide things like completion lists and tooltip information by implementing the Augment* methods in each of the I*Source interfaces. But there’s a missing piece here – how do we actually hook into the key strokes and mouse move events that get fired moment to moment in the editor. Well, that’s a different bit of bootstrapping you need to setup. They’re not quite as convention based as above, but it’s close enough:

For both statement completion and signature completion you’ll derive from IVsTextViewCreationListener and use that instance to instantiate your own derived IOleCommandTarget.
For quick info you’ll derive from IIntellisenseControllerProvider and use that instance to instantiate your own derived IIntellisenseController.

Lost? Still thinking it’s a little fluffy? OK, here’s an example of the statement completion implementation of the some of the above interfaces for SparkSense just to give you something a little a more concrete:

namespace SparkSense.StatementCompletion
{
[Export(typeof (ICompletionSourceProvider))]
[ContentType("spark")]
[ContentType("HTML")]
[Name("Spark Tag Completion")]
public class CompletionListener : ICompletionSourceProvider
{
[Import]
internal ITextStructureNavigatorSelectorService TextNavigator { get; set; }

#region ICompletionSourceProvider Members

public ICompletionSource TryCreateCompletionSource(ITextBuffer textBuffer)
{
return new CompletionSource(TextNavigator, textBuffer);
}

#endregion
}
}

namespace SparkSense.StatementCompletion
{
public class CompletionSource : ICompletionSource
{
private bool _isDisposed;
private ITextBuffer _textBuffer;

public CompletionSource(ITextBuffer textBuffer)
{
_textBuffer = textBuffer;
}

#region ICompletionSource Members

public void AugmentCompletionSession(ICompletionSession session, IList completionSets)
{
SparkSyntaxTypes syntaxType;
IViewExplorer viewExplorer;

session.Properties.TryGetProperty(typeof(SparkSyntaxTypes), out syntaxType);
session.Properties.TryGetProperty(typeof(ViewExplorer), out viewExplorer);

CompletionSet sparkCompletions = SparkCompletionSetFactory.GetCompletionSetFor(session, _textBuffer, viewExplorer, syntaxType);
if (sparkCompletions != null) completionSets.Add(sparkCompletions);
}

public void Dispose()
{
if (_isDisposed) return;
GC.SuppressFinalize(this);
_isDisposed = true;
}

#endregion
}
}

Phew! OK, now we’re getting somewhere. This is a snippet of what’s going on under the covers so I wouldn’t try and make too much sense of it unless you’re planning on looking at the rest of it. Soon I’ll be publishing articles that focuses on each of the areas above. Notice the use of [Import] and [Export] attributes which help MEF recognise the code as a plug-in and in need of certain services. I know it may seem fairly overwhelming, but implementing one of them is very similar to another, so just focus on one at a time.

The Code

As of this writing I am currently maintaining two separate projects. As I stabilize and unit test the pieces, I am integrating them into my public fork on github. What’s not public is currently incubating in a private branch so that I can properly test it. I’m happy to say though that most of the big problems now have solutions and so with a bit of testing and filling out, we should have something useable fairly soon, in fact I’m hopeful that’ll happen before I complete this series. Personally I wouldn’t advise you to actually use the plug-in for Spark development until it’s officially available from the Visual Studio Extensions Gallery, but if it’s the code you’re more interested in, then feel free to come along for the ride.

Conclusion

So that’s a brief look into to the plumbing required when setting up an editor extension like this. There are quite a few moving parts to consider, and rather than post all the code here for those that are interested, it’d be far better for you to consult a living, breathing code base so that you’re not referring to stale information. Either way, I hope it helps get you part of the way there.
Until next time, Robert The Grey

Building an IntelliSense Engine for Spark in Visual Studio 2010

noreply@blogger.com (Robert Greyling) — Sat, 08 May 2010 12:07:00 +0000

Spark IntelliSense : I hereby dub thee SparkSense of the vs2010 district!

Background

Turns out there are a fair number of folk using the Spark View Engine these days, and not just in the Microsoft ASP.NET MVC space. Those that are in that space however, pretty much exclusively work in Visual Studio and there have been many concerns voiced in the Spark community that the lack of IntelliSense features built into the editor are potentially hampering the uptake of Spark as a primary choice of View Engine for MS MVC applications. I’m not sure how true that is, but there are a number of other benefits to be explored…

Documentation can only get you so far…

I feel the same pain as most of the Spark developers, having to constantly keep the documentation open in a web browser and referring back and forth making many mistakes that increasingly affect my workflow and productivity. And whilst the Spark documentation is pretty good by open source standards, there are a number of subtle and hidden features that are not really discoverable right now without ploughing headfirst into the source code. In addition, we all know that documentation is always playing catch-up because there are no unit tests that fail when it gets out of sync.

Productivity

IntelliSense, whilst considered a crutch by many of the hard-core types out there, has a proven track record of raising discoverability of an API and improving coding accuracy specifically in areas like HTML, CSS and JavaScript, where we don’t have a compiler to check up on us, and more often than not, we spend our time flicking between code and browser until we’ve well and truly worn out the ALT+Tab and F5 keys.
My hope is that SparkSense can plug some holes that naturally occur here, and also give one of the best view engines I have ever worked with a fighting chance and more adoption in the greater Visual Studio community. If can shave just a few minutes a day off of developer workflow interruption by building this, then it will have been worth it!

What’s a developer to do?

I recently co-founded a start-up called cozwecan.com and given that Scott and I will be knee deep in Spark and vs2010 for the foreseeable future, it made sense to have a look at what the new vs2010 Editor extensions had to offer. Overall, I must say I’m pretty pleased with the new API, but once again, documentation has let the side down and is more sparse than reputable politicians, and discoverability doesn’t even feature at all I’m afraid to say!

With a little help from my friends…

Needless to say, I moved past that and whilst I’d like to take credit for this exercise, I couldn’t have gotten this far without standing on the shoulders of some pretty tall blokes. I couldn’t find anyone who had singlehandedly gone as far as I’d like to see SparkSense go, but I found some that have done bits and pieces here and there:

Their selfless contributions to the community at large in this area have been and continue to be an invaluable resource for me! And in the spirit of open source, I have borrowed ideas from their work, and hopefully my contributions made in the same spirit can help someone else in their endeavours into what can only be described as the wasteland of Visual Studio Editor extensions developer documentation. Thanks a bunch for your hard work guys and unwittingly helping me plough on through!

So what’s on the menu?

Rather than wait until I’m completely done building this thing and forgetting about the issues I faced on the journey, I’ve decided to document that journey here and break up the key development areas just as Mike did, since his series was incredibly informative and useful to me. I’m a fair way through coding already, but there’s still a long way to go before V1.0 and I’m still reeling from some of the pain points I’ll mention in the series. Since this was a learning exercise for me, I thought others might benefit from that format too and so my intention is to post regularly over the next few weeks covering the following topics as I try and get this puppy out the door:

Getting started – where’s a plumber when you need one?
Our old friend COM and the Visual Studio DTE
Working with the Spark Parser, Grammar and Compiler
Adding Statement completion
Adding Quick Info and Signature Recognition
Making a better Presenter for multiple completion sets
Dealing with parsing performance headaches

I hope this breakdown will be informative for you, but if there is something in particular you want covered and I haven’t got it listed above, then mention it in the comments and I’ll see what I can do. I’ll occasionally update the list above and announce on twitter as I publish each section or you could also subscribe to the feed if you prefer.
Until next time… Robert The Grey

Spark learns to master the Fubu View

noreply@blogger.com (Robert Greyling) — Fri, 12 Feb 2010 01:39:00 +0000

I swear I’ll eventually run out of crazy titles that include the names “Spark” and “Fubu”, but until then you’ll just have to take what you can get :)
In my last post, I talked about getting FubuMVC up and running with Spark as the view engine of choice. That dealt with all the bootstrapping stuff and getting a basic “hello world” example off the ground.
This time we’re digging a little deeper by bringing to bear the powerful 3-pass layout rendering system built into the Spark View Engine. I’m also going to talk about using Spark Partials, mainly showing that they will now work in conjunction with FubuMVC.

The goal

As I said last time, Spark is very opinionated, and if you work with those in mind, you can pretty much get a lot of complex wiring-up for free. The Spark documentation talks about 4 ways (conventions) in which a master layout can be defined and automatically picked up in Ascending order of importance (number 4 wins every time):

Application.spark file in the Shared or Layouts folders
A [ControllerName].spark in the Shared or Layouts folders (Pssst….the convention is to strip off “Controller”)
Naming the Layout as an argument when returning the View – I’ve deliberately not added support for this method because I feel it’s a code smell. Disagree with me? Then just say so and tell me why, and I’ll think about it ;)
Naming the master layout in the .spark file using the <use master=”MasterOfTheUniverse” /> syntax.

The goal here for me was to ensure that people familiar with using Spark on Castle MonoRail or ASP.NET MVC projects could pretty much hit the ground running when it came to working with their Views in terms of Master Layouts and Partial use.
FubuMVC has its own opinions on how partials and layouts are derived, but for now they are separate. I’m not quite up to speed yet on how it all works, but if there is a gap that Spark isn’t filling, then I’ll be making use of the Fubu way where it makes sense. For now though – if you’re coming from a Spark background, you should be able to use it very comfortably.

How do I use it?

Well, I’ve tried to make it as easy as possible. I’ve created a fork of my own from the main FubuMVC-examples repository where you’ll be able to see all the code I’ll show below. One day I hope to have this integrated into the main branch, but for now you’ll have to get it from my fork.
I’ve taken the liberty of compiling the latest dlls from the Spark integration work on my fork and put them in the lib folder. After creating a standard ASP.NET Web Application, You can reference them along with all the Fubu bits like so:

Project setup

Here are files we’ll be working with for this example:

From the top

Once you’ve done a few of these, it really does start to get easier. Start with the Global.asax which is as empty as ever given that I’ve following my pre-built conventions discussed in the last post:

namespace MasterAndPartialViews
{ 
public class Global : SparkStructureMapApplication 
{ 
}
}

Next I like to go straight for the controller. For this example I chose a simple question-answer app that I can build out more and more as I find more things to write about. For now though, it’s only demonstrating this particular topic. Two methods on the controller – easy:

using MasterAndPartialViews.Models.Question;
namespace MasterAndPartialViews.Controllers
{
public class QuestionController
{
public QuestionListViewModel Ask()
{
return new QuestionListViewModel();
}
public AnswerViewModel Answer(QuestionInputModel model)
{
return new AnswerViewModel(model.Question);
}
}
}

The models I’ve used are also fairly simple, although at this point you could see them calling out to a Repository or Data Service somewhere:

using System.Collections.Generic;
namespace MasterAndPartialViews.Models.Question
{
public class QuestionListViewModel
{
public List Questions = new List
{
"What is the answer to life, the universe, and everything?",
"What is the first decimal place of Pi?"
};
}
}

namespace MasterAndPartialViews.Models.Question
{
public class QuestionInputModel
{
public string Question { get; set; }
}
}

namespace MasterAndPartialViews.Models.Question
{
public class AnswerViewModel
{
public AnswerViewModel(string question)
{
Answer = GetAnswer(question);
}

public string Answer { get; set; }

private string GetAnswer(string question)
{
switch (question)
{
case "What is the answer to life, the universe, and everything?":
return "42";
case "What is the first decimal place of Pi?":
return "1";
default:
return "I used to know that one. Hmm, let's see...";
}
}
}
}

At this stage, our code compiles, but we haven’t added any views. Let’s have a look at what the handy FubuMVC diagnostics are telling us so far – Hit F5:

We create the two Spark files (Ask.spark and Answer.spark) as per the controller method names and place them inside a folder (see project layout above) decided by conventions already configured. The files can be blank, but as long as they’re there, they’ll be picked up by the conventions. Hit F5 on the browser this time:

OK – now that we’ve established that FubuMVC has spotted our views and bound them to the correct Actions, we’re ready to start mucking about with the layouts and partials. First let’s take a look at the Ask.spark view:

<viewdata model="MasterAndPartialViews.Models.Question.QuestionListViewModel" />

<QuestionList questions="Model.Questions" />

<form action="Answer" method="POST">
<div>Ask your question: 
<input id="SomeId" type="text" width="500" name="Question"/>
<input type="Submit"/>
</div>
</form>

You’ll notice I’ve specified that it is a strongly typed view using the <viewdata> Spark convention. Now the view has access to dig into the ViewModel.
Next you’ll notice an Html tag called QuestionList. “What the HELL is that ?!?!” You may ask…Well that’s our partial, and that fact that we’ve used the Spark convention of naming the partial (see project files above) starting with an underscore means that we can refer to it as a native Html tag and the vIew engine will pick it up as part of the rendering pipeline. We can also “feed” it part or all of the ViewModel coming in to help it construct itself. Here is the _QuestionList.spark in the flesh:

<!-- expects a list of questions as an input from anything that uses this partial –>
<div>
Here is the list of questions you can ask:
<ul>
<li each="var question in questions">${question}</li>
</ul>
</div>

The Answer.spark view is just a simple display that has a strongly typed ViewModel of its own:

<viewdata model="MasterAndPartialViews.Models.Question.AnswerViewModel" />
<div><h2>The answer is: ${Model.Answer}</h2></div>
<div><a href="/Question/Ask">Ask another...</a></div>

There you have it – partials for a start. Trust me, you can go so much further with them, and I plan on putting a few more complex samples together to demonstrate everything from separation of concerns for your views up to doughnut caching techniques for the more extreme optimizers among us. We’ve only just begun!

Mastering the Layouts

Following the conventions at the top of this post, and looking at my project layout above, you’ll see I have two layouts defined: Application.spark, and Question.spark. Given the order of preference rules at the top, the layout that the whole site with use is Application.spark, except for views that are tied to the Question Controller – all of which will use the Question.spark layout instead as an override. The two layouts look like this:

<html>
<head>
<use content="head" />
</head>
<body>
<div><------- I'm from the Application Layout Begin -------></div>
<use content="view" />
<div><------- I'm from the Application Layout End-------></div>
</body>
</html>

<html>
<head>
<use content="head" />
</head>
<body>
<div><------- I'm from the Question Layout Begin -------></div>
<use content="view" />
<div><------- I'm from the Question Layout End-------></div>
</body>
</html>

The output of the Ask view looks like this:

You can then employ override rule number 4 to the layouts by changing the Question.spark layout like so:

<use master="Application" />

<html>
<head>
<use content="head" />
</head>
<body>
<div><------- I'm from the Question Layout Begin -------></div>
<use content="view" />
<div><------- I'm from the Question Layout End-------></div>
</body>
</html>

And then you have an output that contains one layout wrapped within another like so:

Of course it doesn’t make sense to have two <html> elements etc nested inside one another, but you get the idea – you can stack layouts inside one another as they make sense to build up a page like Lego(TM) blocks. The possibilities are endless here and I really think this post is getting a bit long. If there are specific scenarios you’d like to tackle, but can’t figure out how, then I’d be keen to put an example like that out – so let me know. Either way, I hope you find this useful…

What’s next?

As you’ll see from my code samples above, I’m using POHF – Plain Old Html Forms. Whilst this is not necessarily a bad thing, many of you will be used to HtmlHelpers if you’ve come from ASP.NET MVC background or perhaps some other for of fluent html tag building or convention based mechanism. Well as it turns out, Jeremy Miller been working on just such a mechanism for FubuMVC – but alas, this only works with the standard Webforms View Engine code at the moment. I see this as the area can possibly provide another piece of integration, and I’m probably gonna focus on that next. If you disagree, or have a particular show-stopper that’s preventing you from using the Spark View Engine on FubuMVC, then by all means get my attention and I’ll see what I can do. That goes for you too Jeremy, Chad, Josh, Mark et al :) Let me know where you think I should focus regarding this work…

Conclusion

I haven’t been able to test everything regarding partials and master layouts, but I’m hoping that with just a few people using it, they can discover if I’ve left anything out and shout for help. I’d be very keen to plug any holes if they’re found, but for the most part, I’ve been using it to put something together the way I have using ASP.NET MVC before and I’ve pretty much plugged all the holes for my personal use – now go find me some more! ;)
Until next time… Robert The Grey

Spark learns to speak Fubu

noreply@blogger.com (Robert Greyling) — Tue, 02 Feb 2010 01:08:00 +0000

About three weeks ago, I heard that the FubuMVC framework was undergoing a reboot of sorts, and the team are driving an effort primarily by means of a call for help – or a call to action if you will. FubuMVC natively supports the Web Forms model for page generation, but I’ve always wondered what it would be like to use Spark as the View Engine of choice on FubuMVC, and so I figured that I may as well give it a go!

Opinionated meets Opinionated

As you may already know, FubuMVC favours a convention over configuration (to the extreme) approach to building your MVC application, and on the other side we have Spark which has its own ideas (opinions) about how views should be stored, discovered and created. Luckily for me, this was not a case of “the unstoppable force” meets “the immovable object” – quite the opposite in fact! Both frameworks present strong opinions, which are categorically weakly held – which made my life much easier when integrating the two. I got to decide which parts of FubuMVC I thought were a better approach and vice versa. It doesn’t necessarily mean I’m right, but at least I got to choose.

Needless to say, if you disagreed with my approach, you could also go ahead and replace the bits I’ve written as default integration points with your own strategies and conventions. But assuming you just want to see it working, here’s how you setup a basic Hello Spark Application:

The Project

Assuming you’re using Visual Studio and not something more hard-core (like notepad), fire up a bog standard new ASP.NET Web Application - no not an MVC application, and no, not an empty MVC application either – although you’re welcome to do that if you’re willing to fix your references. You may need to adjust references anyway, so it’s easier if I just show you that you end up with something roughly like this:

Bootstrapping

The default IoC Container for FubuMVC is StructureMap, although I believe work is currently under way to swap out with one of your choice. Regardless, it stands to reason that you’d want to put some bootstrapping code in there. Wanna get a sneak peak at my Glabal.asax? Yup – that’s it – all wrapped up nice and snug…

namespace FubuMVC.HelloSpark  
{ 
    public class Global : SparkStructureMapApplication 
    { 
    } 
}

“What?” you may ask does that SparkStructureMapApplication contain then? Well, not much really – it inherits directly from HttpApplication and the important bits are as follows:

public virtual FubuRegistry GetMyRegistry() 
{ 
    return new SparkDefaultStructureMapRegistry(EnableDiagnostics, 
    ControllerAssembly, ViewFactory);   
} 
protected void Application_Start(object sender, EventArgs e) 
{ 
    RouteCollection routeCollection = RouteTable.Routes; 
    SparkStructureMapBootstrapper.Bootstrap(routeCollection, GetMyRegistry());   
}

Most of it is standard stuff. The ControllerAssembly helps tell us where to look for actions and views and the ViewFactory finds and describes them. The bootstrapping comes next, and I’ve provided a default SparkStructureMapBootstrapper that you can use as long as you like the same conventions as I do:

public class SparkStructureMapBootstrapper
{
    private readonly RouteCollection _routes;

    private SparkStructureMapBootstrapper(RouteCollection routes)
    {
        _routes = routes;
    }

    public static void Bootstrap(RouteCollection routes, FubuRegistry fubuRegistry)
    {
        new SparkStructureMapBootstrapper(routes).BootstrapStructureMap(fubuRegistry);
    }
    
    private void BootstrapStructureMap(FubuRegistry fubuRegistry)
    {
        UrlContext.Reset();
        ObjectFactory.Initialize(x =>
        {
            x.For<ISparkSettings>().Use<SparkSettings>();
            x.For(typeof(ISparkViewRenderer<>))
                .Use(typeof(SparkViewRenderer<>));
        });
        var bootstrapper = 
            new StructureMapBootstrapper(ObjectFactory.Container, fubuRegistry);
        bootstrapper.Bootstrap(_routes);
    }
}

The important points to note here are the usage of the default FubuRegistry and StructureMapBootstrapper which do most of the heavy lifting in terms of building the object graph across the application. You can still wire up your own classes here though as I’ve done with SparkSettings and SparkViewRenderer.

Create some views and controllers

For this simple application, I’m not going to go into too much detail regarding view and controller creation. Suffice it to say that you can view and download the code yourself right here. To get this going, you can see the files I created for this small web app in the folder structure above. We have Application.spark which is our primary Master page:

<html> 
  <head>   
    <title><use content="title">Default Title</use></title> 
  </head> 
  <body> 
    <div id="header"> 
      <use content="header"> 
        <div>no header by default</div> 
      </use> 
    </div> 
    <div id="main"> 
      <use content="view"/> 
    </div> 
    <div id="footer"> 
      <use content="footer"> 
        <div>no footer by default</div> 
      </use> 
    </div> 
  </body> 
</html>

I’ve followed my preferred method of organising Views and Controllers. With FubuMVC, there’s nothing stopping you from putting them any which way you like because the entire assembly is scanned regardless and a mapping of routes, views and actions are built by associations that you get to establish in code – or you can just use the defaults :)

First you add a Controller like so:

public class FireController 
{ 
    public FireViewModel Create(FireInputModel model) 
    { 
        return model.GotALight() 
                   ? new FireViewModel {Text = "Light 'em up!"} 
                   : new FireViewModel {Text = "Light 'em up anyway!"}; 
    }  
} 
public class FireInputModel 
{  
    public bool GotALight() 
    { 
        return true; 
    }  
} 
public class FireViewModel 
{   
    public string Text { get; set; }   
}

Next, you implement a view (Create.spark) to go with the “Create” controller method like so:

<viewdata model="FubuMVC.HelloSpark.Controllers.FireViewModel" /> 
<content:title>Let the Sparks fly!</content:title> 
<content:header>What do we wanna do?</content:header> 
<h1>${Model.Text}</h1> 
<content:footer>That's right baby!</content:footer>

And then you hit F5 like so:

Behind the scenes

I’ve created the integration work which contains all the glue between the Spark View Engine and the FubuMVC pipeline in a separate assembly for the moment, the source code for which you only really have to go in if you’re curious, but you don’t need to if you just want to start building with Spark. It’s not yet integrated into the main Github branch, but I hope that after some scrutiny and more additions that I make, that we can find a more permanent home for it.

What next?

My next port of call is to get master pages and areas properly supported. I haven’t yet delved into how areas and slices work in the FubuMVC code, and so I was reluctant to do any work in this area until I at least got the basic page lifecycle done. Spark also has it’s own implementation of partials as well as caching and so I’m going to have to explore those parts a bit more before I decide who’s opinion is stronger. I haven’t started on it yet, so if you want to give me your two pennies, I’d be happy to take notice.

Cudos

Jeremy, Chad, Joshua and the rest of the gang have done a great job on the framework so far! There are more extensibility points and configurable bits than there are spikes on a blow fish – a veritable candy shop of choice – and yet just going with the defaults will get you going in no time at all. I hope this post, and the examples to come will help you learn more about these fantastic frameworks – and do let me know if there is something specific you’d like covered here… I’m always looking for ideas.

Till next time,
Robert The Grey

Windows Azure Functional bits and tooling comparison

noreply@blogger.com (Robert Greyling) — Sun, 06 Dec 2009 16:43:00 +0000

This is post is part of an ongoing series I am writing about Microsoft’s new Windows Azure platform. Feel free to read that first for an introduction to this.

Scalability and Reliability

Each of the vendors provide various services in their offerings, many of them common. The first thing they’ll tell you is that they provide the means of infinitely scaling your application and ensuring high availability. These points are not worth debating because I’m fairly certain that they can all live up to that promise, and I’m even more certain that at some point in time, they will all break that promise – and some have already had the opportunity to do so.

What we really need to dig into here is: assuming that high availability and scalability have been removed from the equation as problems areas – how else does the cloud make your life easier than regular hosting? That’s the real question here, as well as how it pertains to Windows Azure versus the other providers.

When it comes to comparing Windows Azure and the competition, there are quite a few areas I’ve delved into. What’s the one thing every developer dreads when they start a new project? Well…actually deploying the project of course! If they manage to get that far, most projects would already have put plenty of thought and planning in to architecture, resilience, performance and so on…right? Right?!

Well at least you hope they have – but one thing that generally always gets left as an afterthought is deployment – mainly because it is often mistakenly diagnosed as “the easy part”. Yeah – about as easy as grilling your rib-eye with a box of matches – you could do it, but not without a seriously good plan, and even then it’s gonna go wrong more often than it’s gonna work out. And you better be prepared to eat a rare steak!

Deployment – the hard way

Of the competition I’ve evaluated, Amazon Web Services and GoGrid are like the irresponsible parents in the group. They basically hand you the keys to the Ferrari without making sure you’ve passed the driving test first. As with everything else, this can be both a good and a bad thing. If the kids are self-disciplined and responsible then the parents are just seen as ultra-liberal and have no need to worry. If not, well then they can expect to be putting in a hefty insurance claim pretty soon.

When it comes to having full control of your own VM (or many), they’re basically trusting you to know exactly what you’re doing when it comes to all aspects of the machine – from networking, security, patching, stability and installation – and that’s all before you’ve even managed to get your application on there – not to mention upgrades.

Now that’s fine if you really get enjoyment from that fine grained level of control. Some developers get a kick out of putting their network admin hat on sometimes – hell yes, I freakin’ love doing that stuff! They also give you the ability to set your machine up the way you want, and then persist that as a custom image from which you can boot up multiple instances as and when you need them – sweet!

I really loved doing that and the power and flexibility it gave me was seriously awesome…for about 6 weeks, at which point I had downgraded it to “pretty cool”, and a short time after that, to “Seriously?! Again?! This is becoming a royal pain where the sun don’t shine”. I had all the power and flexibility in the world at my fingertips, but still couldn’t derive a click-once deploy scenario that spun up a new instance perfectly.

I can honestly say that if you want to go this route, make sure you have a network admin at the ready who loves this kind of stuff, because in the end – if you’re serious about cloud deployment, you’re gonna need someone full time on this kind of task. It absorbs more time on the project than a dry sponge in the desert - at noon!

Deployment – The Easy Way

And now we come to the other side of the coin. Both Google App Engine and Windows Azure are able to provide intelligent deployment mechanisms because of the tight control they ~~lord~~ keep over the environment. This again can be a good and a bad thing because these parents want to sit in the back seat while you go on your hot date. As long as you can live within the controlled experience they provide, and are willing to make some sacrifices in that department, they promise to take all the heavy lifting on for you, and leave you free to focus on the one thing that really matters here – your application!

Both Windows Azure and Google App Engine provide a classic “staging and production” deployment scenario. You can upload your changes and test them separately from the live running instances, and once you’re happy, you can just swap out the instance you want “live”, and roll back instantaneously again of course if everything goes hay-wire.

This provides a pretty comfortable experience during a time when stress levels have traditionally been pretty high in corporate environments. Nobody wants to damage their brand, so this kind of thing is a bare minimum really.

Windows Azure takes the science of deployment another step forward to allow for a lot more flexibility and have basically found a way for you to ensure there is zero downtime between upgrades – barring of course you doing something stupid ;-). Microsoft announced a new feature called Rolling or In-place Upgrades at PDC2009 which allow you to more effectively control the life cycle management of your application by making use of upgrade domains to isolate instances.

This really does allow for the hardcore among us to come up with some pretty creative and safe ways of deploying changes that affect portions of large systems – many of which I’m sure we’ll see in the cloud some day.

Storage

All of the providers provide some kind of blob storage, and most provide the equivalent of table and queue services and storage. GoGrid is the only one lacking in the latter, but make up for it in the former by giving you 10GB free blob storage straight away.

Amazon give you 1GB of storage and 1Gb in bandwidth free per month, Microsoft aren’t charging yet, so it’s tough to tell, and Google have similar free quotas for new starters. You can expect these to fluctuate dramatically over the next few cycles as they jostle for position. Either way, it’s good for the consumer.

One really neat thing that Amazon have provided is a Transact-SQL-like interface on top of their SimpleDB service and Google have done something similar with GQL which really makes things a lot easier for those trying to transition from a relational world. Microsoft have gone the whole hog and put the real thing – SQL Azure – in the cloud for those who just can’t do without.

Overall I’d say it’s a pretty even race at the moment between the big three and it’ll take some pretty big innovations to distinguish themselves as the leader – but who are we kidding – it’s probably going to come down to price, isn’t it?

The Developer Experience

Again I’ll start with the VM providers. GoGrid don’t really go out of their way to encourage developers to get onto their platform, but Amazon seem to be pulling out all the stops lately to try and achieve this. They’ve recently come out of the stone age and announced a new revamped SDK for .Net for connecting to and using their web services. It’s jam packed with great samples and at least they did it for VS2008 this time.

That, I’m afraid is where all help stops from them. After that you’re on your own. There is no such thing as a local or disconnected development environment or sandbox where you can test or develop your code. Everything needs to be against the cloud environment. I know the general consensus these days is that you’re “always connected” anyway, but I’m sure they’d be surprised to find out how often that’s not the case.

Google App Engine and Windows Azure however, have done incredibly well by taking the full development life cycle into account! Both provide a disconnected means by which you can develop and test your application locally over pretty much all the available services.

This, to me, is the way it should be if you want developers to pick your platform and run with it. The minute there are barriers to entry, developers will probably try and find the path of least resistance. Price can be, just such a barrier to entry as well and so it’ll be interesting to see how the pricing fluctuates over the next year or so.

Diagnostics and Performance profiling

Windows Azure hasn’t even launched yet, but already I feel they are are leading the pack by a massive amount in this department. Google App Engine is a distant second with their online dashboard which gives paltry stats that are more relevant to them rather than the health of your application. Amazon, as expected, can only provide services from the outside such as CloudWatch which can help you automatically scale your instances up. That’s great, but can it tell you why you were forced to do so?

It’s fine if you nailed a slam dunk in some viral marketing campaign, and you got more virtual feet than Time Square on New Year’s Eve, but what if that’s not it – what if there is some kind of runaway memory leak in your application – sorry, you’re on your own…again – and we can’t really blame them, they did give us the keys to the Ferrari after all…

Microsoft have pulled out all the stops on this one – there is a seriously good and friction-free developer experience that comes with logging, tracing and diagnostic collection and the API they’ve provided is incredible! This thing enables all sorts of cloud and desktop driven scenarios for diagnosis, scaling, throttling, you name it, and I think there are partners queuing up left, right and centre to deliver something in this space.

Conclusion

This post is getting a little long, but if there are any specific areas you’d like me to cover in more detail, or things I may have failed to mention – drop me a comment and I’ll get right on it!

Taking a view across all areas, for now, from the perspective of what I want and need for cozwecan.com, it’s looking more and more like Windows Azure is going to provide everything we need…everything except cost effective pricing unfortunately.

I know it’s a tired subject, but in the end, it doesn’t really matter how good your cloud is – when there are cheaper and proven business viable alternatives with Big names out there – you can bet your Ferrari you’ll be losing plenty of business to them…

Until next time,
Rob G

Windows Azure Pricing – it’s always all about the money

noreply@blogger.com (Robert Greyling) — Sat, 05 Dec 2009 20:04:00 +0000

This is post is part of an ongoing series I am writing about Microsoft’s new Windows Azure platform. Feel free to read that first for an introduction to this.

Storage

Let’s cut to the chase, everyone wants to know how much data they can store up there and for how much. Hosted solutions are woefully inadequate in this department. They treat their hard drives like bars of gold instead of the cheap storage units they’ve become. ISPs just can’t (or won’t) compete with the cloud providers in this area. Don’t believe me? Just try asking for a price on 6 terabytes of space on their SAN. That’s why rackspace now do both managed hosting and cloud hosting. They knew they couldn’t compete just using the old model.

I’m not going to list pricing of each provider since that kind of detail changes too often as they seek to compete, suffice it to say that they’re all pretty much in the same ball park at the moment, which means you’re not going to choose on that basis. GoGrid however, have again raised the stakes by offering the first 10GB of cloud storage for free! Google gives you a measly 500MB, but that’s still better than Amazon S3 who start charging immediately, and unfortunately, it seems Microsoft are following suit by charging from the gates.

I’m really surprised Microsoft has not decided to blow the competition out of the water – they are by far the biggest of the bunch, and they have the perfect opportunity to undercut prices and provide generous starting quotas given they have come to market a fair bit later. But they haven’t so far, which basically means they can only compete on features - let’s see where that leaves them…

In fairness though, they haven’t started charging at all yet, but there’s currently no indication of whether or not you’re going to get discounts to help you get started – and that being the case, I’m afraid it is keeping a lot of potential customers at arms length.

Bandwidth

Every single little byte that travels to and from your cloud solution is going to cost money (or quota). Many traditional hosts will give you free incoming bandwidth which in my view is a substantial saving! So far, it seems that GoGrid are the only ones who have adopted this for their cloud offering as well. It does ~~piss me off~~ bug me somewhat that I have to pay money just to get my application and supporting data up to the cloud. Isn’t it enough that I’m agreeing to go into business with them in the first place?! I’m almost tempted to host with GoGrid on principle for that reason alone.

I think it’s a stupid stealth tax which you wouldn’t normally incur with traditional hosting, and I feel that cloud providers could use this as a competitive advantage. Other than that, the providers are pretty much on a par with their pricing.

Outgoing bandwidth – fair enough, traffic is traffic and you can’t expect to get that for free if you plan on running a business, and all the parties are once again, on par with one another. Disappointing really…

Compute

This is where the real hidden (or hard to pin down) costs lie when it comes to cloud hosting. Google really do have right idea here. They charge per CPU core hour which translates to the actual time taken during the processing of a request! Simple and unambiguous – this will literally scale with your business and does not charge you for “idle” time.

Unfortunately all of the others charge you per hour to have the machine up and running – even when there is no traffic. Just a green light on the box – you’re paying for that! Now when it comes to Amazon EC2 and GoGrid, this is understandable because their model is basically to provide you with a virtual machine instance which it seems they have no other choice but to charge you for.

Most surprisingly, Microsoft seem to have gone for this model as well, but since their application deployment model is much more akin to Google’s, they’re basically shooting themselves in the proverbial foot. Not only will they be directly compared with Google App Engine, but they will also be an order of magnitude more expensive for the same apples when it boils down to cold hard numbers.

If you’re thinking in terms Azure’s “Web Role” or “Worker Role” instances, they’re basically classifying each one of those as its own VM – which means you pay the cost of that particular VM being up and running. Compare that directly with an Amazon VM, it’s basically a windows machine (for example) that you can run IIS on, and put 10 websites up if that’s what you want to do. Clearly neither are redundant until you run two instances but you get the picture – Amazon is going to work out cheaper by miles in this scenario.

This for me, makes Windows Azure a complete non-starter I’m afraid. The fact that you pay for the privilege of spinning up a web application on IIS in the cloud is ridiculous! Luckily they haven’t gone commercially live yet and are still taking feedback. Guess what the number one feedback item is – yes this ridiculous method of charging. For their sake, I really do hope they sort this out before commercial availability, otherwise, commercial viability is going to be the question on everybody's lips.

Content Delivery Networks

CDN functionality is available from all of these providers and it’s a bit of a premium service. Unnecessary it seems, until you really start noticing your application take off on a global scale, and serving your content ~~fast~~ close to the speed of light becomes a requirement, not just a feature!

Easy to configure, but you better be prepared for your cloud application to start costing a fair bit more money per month! Either way, it’s something that start-ups are probably not going to leverage right at the beginning, but it’s nice to know they’re available if you need them.

Azure-Spark!

If you didn’t already know about Microsoft’s fantastic initiatives for getting start-ups going, have a look at their WebsiteSpark and BizSpark programmes. These basically provide free software and services (everything a growing business needs) at a cost of $100 – which is only payable at the end of three years. By that time, you should have a fairly good idea of whether or not your start-up is going anywhere. There are a few qualifying criteria, so take a look if they’ll work for you.

What I’d very much like to see is the launch of something similar for Windows Azure. Let’s call it “AzureSpark” for instance, and this could provide (similarly to the BizSpark programme) free or significantly discounted Windows Azure bits for 3 years which could definitely see a start-up get going in the cloud.

This would create significant buy-in to the Windows Azure platform on the start-up’s behalf who would not want to take everything down after 3 years to change providers if it was working well. This could be a truly symbiotic relationship, and if anyone can afford to take this bold step, it’s Microsoft. This move alone would cement my choice of cloud provider as well as many other start-ups out there I’m sure. Not to mention all the talk it would create in the cloud-space, but this certainly could be a curve ball that other cloud providers probably couldn’t counteract with ease.

What about the little guy?

Clearly this wouldn’t work so well for the hobbyist programmer out there who just wants a cost effective long term solution, so lets not forget about them Microsoft – m’kay?

Right now Google App Engine will be getting all of these guys because of the “no risk and no cost” up front option – and it’s these people that will be hauled into the boardroom meetings in their day jobs being asked to recommend a provider they trust and have tried out. You’ll be surprised what word of mouth coming from well-connected developers can bring your way – just sayin’…

Conclusion

For me at the moment, it’s all still up in the air. I have high hopes for this platform when it comes to pricing, but at the moment, the competition are already well established, ahead on numbers and support AND looking like they’re gonna be cheaper to boot!

The ball is in your court Microsoft… should I bother picking up my racquet?

Here’s hoping…
Rob G

Windows Azure - clearly the inferior cloud platform…right?

noreply@blogger.com (Robert Greyling) — Sat, 05 Dec 2009 20:02:00 +0000

Says who?

This is the feedback I’m getting time and time again when chatting to technical types about the various cloud offerings. But is it though? Really? Most people I’ve spoken to haven’t been able to articulate exactly why they say that. Upon digging a little deeper into their reasoning, two major themes have come up every time:

Windows Azure is late to the party and are too far behind the competition
and it’s Microsoft - duh!

Well I hope I can be forgiven for not basing my business upon those two weak opinions. They firstly lack any substance or reasoning, but they also lack depth in evidence. This is the main problem – most people just don’t know if it’s gonna work or not. And so they default to one of these two positions – or both!

If you have other reasoning, then I’d be interested in hearing it, but due to the lack of evidence out there, I felt this was necessary, even if it is just for me to work through my reasoning with clarity – and hey, while I’m about it, I may was well put it out there…

A while ago, I decided I couldn’t dismiss it out of hand, but back in the early CTP days, it wasn’t really possible to compare apples with apples. Leading up to and since the PDC2009, things have taken a big enough step I think where comparisons can now start being made. Below is the result of my investigation so far.

The competition

Firstly, I can only really speak about competition that I’ve actually tried out. There are more of them out there, but I don’t feel comfortable talking about things second hand. And so, the ones I have personally evaluated are:

Given the fact that the website I’m building is based on the ASP.NET MVC framework, it’s pretty much a given that Google’s offering cannot help me in it’s current form. I’ve kept it in here for the simple fact that I think they’ve gotten plenty of things right and it therefore still bears comparison, which I’ll mention from time to time.

First – a brief comparison to traditional hosting

Only one of the cloud providers can compete with regular shared hosting from a pricing perspective I’ve found – and that’s Google with their generous free quota, but it is of course never going to support a thriving business, but it will support a fairly static one. I’m not entirely sure that the cloud providers are after the kinds of folks who would use shared hosting effectively. I think it is unlikely that they will grab much of the micro-website market – people who just want a home page for their restaurant that shows the menu and a phone number, and maybe a map for directions. So far Google can do it, but none of the others are competing in this space.

In addition, if you are just planning on putting up a “home page”, you won’t be making the best usage of the resources available to you. The cloud was built for scalability and processing power in mind, easy global deployments via CDNs with all the gadgetry behind that to support running a business online. If you don’t need that, then shared hosting is probably your best bet.

There is a slice of the market however, that feel rather cramped, and would love to grow out of the shared hosting scene – but for those people – many of them young start-ups – having a dedicated server with an ISP is prohibitively expensive, and even worse, it’s nowhere near resilient, and completely riddled with single points of failure.

That’s when they start down the arduous path of redundant database servers, then a web tier with load balancing, and before they know it, they have their own private little web farm and are probably going out of business in the next six months because of the massive overheads.

This is the perfect moment for a cloud hosting salesman to step up to the plate. Giving you multiple machines, at the drop of a hat, with fully redundant data solutions and scalability of the gods – this is what they were born to do…at least that’s what they tell us.

The Cloud Comparison

This post is already getting a little long, and there’s a fair bit to come. If your mind is starting to wonder off, then by all means stop right here, but if you’re still interested at this point and would like to read about the comparisons I’ve made to date, then feel free to click on your topic of interest which I’ve separated into a series below:

I’ll try to update these to keep them fairly current, but inevitably things change over time and I can’t keep up with all of it – I encourage you to do your own investigations and if I’ve gotten something wrong, or it has changed drastically, then let me know in the comments and I’ll be sure to update it.

For now, take care…
Rob G

Teaching JavaScript how to render your views using Spark

noreply@blogger.com (Robert Greyling) — Tue, 03 Nov 2009 00:54:00 +0000

This post applies to Spark View Engine version 1.0.3 and up (to my knowledge)

This is a little known, and (currently) just about “undocumented” feature that I feel deserves more kudos purely because of the sheer breadth of its possible applications. I first read about it on K. Scott Allen’s blog, but even after reading that I didn’t quite realise how significant this would end up being, and more importantly, how difficult this is to achieve using the Web Forms View Engine. I also experienced a few difficulties in wrapping my head around, and using the technique. My first attempt was a dismal failure for two reasons:

Firstly, I didn’t even get what it (the technique) was supposed to be doing – it just looked cool
Even when I thought I knew what it was doing, I was way off in my understanding, I thought it was meant to do “x” when it was actually doing “y”

About now, you’re probably feeling somewhat like I did at the time: A little lost, but that this could be an important nugget waiting around the corner. As such, I’ll try my best to explain this by remembering what it felt like to be in my shoes before I grokked it, and even now I’m not entirely sure that I do. Here goes:

Same old same old…

OK – to describe this clearly, I think I’m gonna have to drop in about a thousand words here first:

Let’s say you’re trying to build the view above. This is actually a mock-up of our photographer list (modelled similarly to the very simplistic user list I really like on StackOverflow.com). On the face of it, this seems fairly simple to build as long as you’ve got a decent grasp on HTML and CSS, and of course already have the graphics. But yes, that’s only on the face of it. Let’s take it a bit further by saying that you have a very long list of photographers and don’t want any post backs in order to page through them. In that case you’ll want to lazy load them as the user pages through them right? Or what about collapsing 4 columns down to 1 when a photographer is clicked with the resulting space taken up by the photographer’s details? Chew on that one for a while…

OK – easy so far, we’ve got some HTML, CSS, Graphics and a little bit of jQuery to handle the AJAX lazy loading and innerHtml replacement bits. Can you see the gaping hole yet? If you can – then pretend you can’t, so we can dig a little deeper…

Ask yourself : “What exactly is that AJAX response going to look like?”. Well, first guess is that it will return the exact required Html that makes up the “next page” of photographers in the list. If you think about it, that particular Html will contain two things:

Structure - all the divs and stuff that make it look pretty. (if you think that’s pretty of course)
and Data - the actual names and details of the photographers – most of mine above are of Latin decent ;-)

Secondly, even if you use RenderPartial and do it over AJAX, you’re still rendering the same “Structure” out multiple times, and only the “Data” is changing. Let’s call a spade a spade here – that’s just plain inefficient!

Injecting “the ability to render” Views client-side

What if we could get all the divs and pretty stuff down to the client only once (at page load), and just send requests for data (say via JSON) back to the server and completely short circuit the rendering cycle. Well you can – easily – with Spark!

Spark has a built in mechanism for taking any partial view that you have code for on the server side, and that you may use in various places, and without changing a thing, it can percolate that rendering capability as a JavaScript call that can be called at any point on the client side. Time for some code that shows 1, 2, 3 *magic* me thinks:

1. Make use of an awesome Spark View Engine asset – the JavascriptViewResult inside the PhotographerController:

2. In the same Controller, make sure you add a method that will return the appropriate data to you, like so:

3. If you’re new to Spark, then just add this next bit to your master page in the head section, otherwise best practice is to add it to a Spark Section called “head” in the Spark View which gets rendered during the Spark life-cycle:

See what we’re doing there? We’re adding our View from the Controller as Script – Spark takes care of the rest…

4.And finally – I use jQuery to make a JSON server call:

I’m not sure it needs much more explaining because it’s just so simple (and yes I didn’t get it at first because I was neck deep in web forms paradigms and couldn’t pull my head out!), but I’ve highlighted the points of interest in the code. This last one in particular – that Spark.Photographer._ListPage.RenderView call is actually a JavaScript function that got rendered down to the page because of the script tag used in (3) above. That means that I only need to call the server for data (which comes down in incredibly efficient JSON), and the user can happily page through until the end without that view needing to be rendered again.

Taking it another step further

At the beginning I mentioned loading the photographer detail this way too. Think about it, if I collapse the columns from 4 down to 1, and fill up the remaining space with photographer detail, the column that’s left can be clicked on to load another photographer, and the next hyperlink could be used to either scroll through the photographers one by one, or to scroll one column at a time – it’s up to you! All that would require is one more View (the detail view) created as per the example above, rendering capability sent down to the client, and from then on, only data calls going backwards and forwards. Did I hear someone say…”Gmail-esque” ?

The key here is that there are no postbacks and it feels very responsive because the data calls are tiny, and the power of the desktop is being put to good use, and we’re even applying the DRY principle to our server calls ;-)

Warning and Closing Thoughts

As is the case with everything, overuse can too quickly lead to problems. If I were you, I wouldn’t turn this into your new hammer and go on a nail hunting expedition. Used wisely, I have found this technique to be very helpful in scenarios where lots of different data is coming back, but is continuously using the same views. Page transitions are a breeze for related data (e.g. All about photographers) and play very nicely with tools like jQuery. But I still use postbacks to move between Controllers say, it’s kind of a boundary I’ve set myself. You don’t have to, you could build your entire app using calls like these, but I tried that for a day once, and I’m still a little cross-eyed as a result.

Remember, keep things simple, and make use of all the tools in your belt at the right times, and you’ll be able to keep a tidy ship when it comes to your code. This is a particularly shiny tool that I like to use, but don’t use it too often, lest it lose its shine too quickly…

All the best,
Rob G

Adventures in the land of Spark

noreply@blogger.com (Robert Greyling) — Tue, 03 Nov 2009 00:51:00 +0000

Welcome to what I hope will be an informative list of Spark View Engine “How To’s” and hopefully show a little bit about how it has helped me whilst building cozwecan.com.

I’ll prefix each post with the version that it applies to in order to make it easier for you to decide the applicability for your scenario. If there are drastic changes between versions, then I may consider writing a new post on it, but small changes (if I happen to use them) may just come in the form of updates to existing posts.

In my previous post, I spoke about Spark and the ASP.Net Web Forms View Engine and contrasted the two. In this series I’ll also try and describe the way in which you would attempt to achieve the same goals using both engines, hopefully clarifying why it is that Spark is my View Engine of choice.

I do feel however that I need to put a specific disclaimer in here at this point: I am by no means a expert on the Spark View Engine, if you’re looking that – his name is Lou! I can’t even really say that I’m an expert on the ASP.Net MVC Web Forms engine, but I have been ~~fighting~~ using it since the early previews. I figure there’s a gap in the market here for somebody to “do it better” and I believe Spark is the one I’ve been waiting for.

One thing holds true, and will always hold true concerning these posts: I am first and foremost a creature of least resistance – yes that’s right, I am it. I used to seek that path, but having developed a severe dislike for anything that puts up a barrier, I’ve pretty much found over the years that I’ve been on it more often than not, and I’ve developed a certain knack for spotting things that will hurt more than a root canal, and separating them from things that are as simple as falling off a log.

I enjoy seeking out the simple ways in which to achieve a complex goal. Tools form a very large part of this, and the posts in this series best illustrate how Spark has made my life simple when building web applications. I hope you enjoy them:

All the best
Robert The Grey

cozwecan.com Lights Up with a Spark under the hood

noreply@blogger.com (Robert Greyling) — Sun, 27 Sep 2009 21:06:00 +0000

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

Why we need the Cloud - Traditional Hosts: FAIL and you!

noreply@blogger.com (Robert Greyling) — Thu, 30 Jul 2009 09:04:00 +0000

Howdy all!

Today we're going to tackle a particularly tough subject - and by tough, I mean it in terms of getting concrete data regarding the most important thing to a young Start-up: costs!!

OK - so I want to get our new website on-line, and I want to do it as quickly and as easily as possible in order to start "doing business". I guess this is where I'd need to define what "doing business" means to us.

If your website would serve as more of an auxiliary sales channel, or information portal, or just a means of getting your Name in lights, then the rest of this article isn't really going to apply to you. That's mainly because with a little research, you can pretty much sign up with any of the cheap hosting deals out there today, and get away with it.

What I'm referring to here, is when the life and soul of your business lives and dies by the internet, and this applies directly to us at cozwecan.com.

Here are some of the things I've thought about when it comes to this:

Applications & deployment

Unless you're planning on spending the money on a dedicated server or two at a traditional host, you'll more than likely be on shared hosting of some description. This will limit your deployment and application options. For instance - let's say that you choose your host based on the fact that they offer the .Net v2.0 framework on Windows upon which to deploy your site.

Everything is peachy until .Net v3.5 comes out and you want to use some of the new language features. Well, you'll have a better chance of lighting a cigarette in a thunderstorm, than getting them to advance their upgrade plans. Host-hopping seems like the only way to go about ensuring your upgrade path on your terms - but then again, that could be why they like to lock you into these 12 and 24 month contracts...I wonder...

Google App Engine and Microsoft Windows Azure have similar characteristics to those mentioned above, but with very important distinguishing features. As a start, there are no lock-in contracts, you get to deploy on the latest respective frameworks, which are frequently updated in lock-step with those that are using them and the infrastructure that you leverage can span multiple servers, not a small fraction of one!

Scalability and ease of deployment are the obvious benefactors here then. But you do still have the situation of running in their sandbox with access to only the bits they will allow. This can be problematic for some. With Amazon EC2, you get total freedom to run riot on the one or many servers you spin up. But therein lies the rub - run riot you will if you're not careful! With great freedom comes great responsibility, and you'll need to be willing to setup and keep tabs on all your deployed servers if you go that route.

But look what I'm getting at here: With cloud providers coming along, the start-ups among us are beginning to get ACTUAL choice, where traditional hosts only ever gave me the ILLUSION of choice.

Bandwidth

Most traditional hosting providers will include a nominal amount of outgoing bandwidth in your package and this would be fine for most small businesses I'll admit. The problem here though is similar to that of public transport - just try taking the bus on a day when you really really need to be on time for a meeting...you know where I'm going with this, right?!

The day your teeny tiny start-up hits some form of publicity bubble via which ever medium you care to imagine, is the day you're really really going to want your website to be up. And I don't mean up as in it exists somewhere... I mean up like a honeymooner's prick!

To achieve this, you're firstly going to want to avoid what many traditional hosts still do to this day. As soon as you reach your outgoing bandwidth cap, they throw up a nice error message saying that you've exceeded your allowable quota. Nice! Especially when you're trying to get your brand new start-up off the ground. Others employ a less evil, but just as damaging tactic - instead, they set your cheque book on fire with exorbitant pricing per MB over quota. Need I go on?!

Cloud providers seem to have seen right through this farce, and they've all come up with their own pricing, but none the less pricing based upon usage and this is a MUCH more sane approach for a start-up in my opinion. The other hidden gem here is scale - most people don't see that one is missing until it's too late. But enough about the pipes already! I'm sure the dinosaurs will begin catching up - it's just a matter of time, or market forces...whichever comes first.

Storage

I've often heard it said: "Disk space is cheap!" Oh yeah? Try calling up a hosting provider and ask them for 6 terabytes on their SAN. Then ask them if it's fully redundant (Pssst - that means 12 or 18 terabytes total now if they'll do it for you). Then ask them how often they'll back it up for you. Then ask (and I'd take a seat at this point if I were you) how much it's going to cost you. Lastly, ask them if you can pay as you grow?

Just a quick glance over at Amazon's cloud storage solution (at the time of writing) reveals the following:

$0.150 per GB – first 50 TB / month of storage used

$0.140 per GB – next 50 TB / month of storage used

$0.130 per GB – next 400 TB /month of storage used

$0.120 per GB – storage used / month over 500 TB

That's FIVE HUNDRED TERABYTES!!! Not that we would ever use that much disk space in our wildest dreams, but c'mon...these solutions are clearly leading the way when it comes to modern day requirements, while your traditional host is still stuck in the dark ages charging you a premium because they had to go buy some extra hard drives.

Heck, Google gives you the first 500MB storage free if you go with them! I estimate that for our first project we'll need between 3 to 6 terabytes in the first 18 months, so unless the traditional hosts can compete at those kind of levels, going with cloud storage is a no-brainer.

Scalability and Reliability

Obviously if you throw enough money at the solution, you're going to end up with something that satisfies both of these criteria. I'm certainly not against going this kind of route as a long term goal for two reasons: firstly, I'm comfortable in the hosted world with racks and servers you can touch and feel - I love it! Secondly, the cloud still needs to prove that it can stay up 24/7! Amazon have already failed in this department, and so have Google for that matter.

But managing your own machines does come at a price, and I'm not just talking about the price tag...hardware failures are a bitch and cannot be predicted. Don't even get me started on shared hosting!! Not even the mighty Amazon and Google cloud offerings can get it right all the time. But let me ask you this then - who do you think will learn the most from hardware failures and downtime: Google, Amazon, or me? Why me of course...just kidding!

I'd bet some fairly vital body parts that the cloud providers (although young today by hosting standards) are learning from these mistakes and putting contingency plans in place as a matter of utmost urgency to prevent PR meltdown. Not because they care about little old me, but because they care about their brand! And I for one would much rather have it that way.

I think a few speed bumps here and there are more noticeable in today's world of course, but that can only work in our favour. Start-ups have historically struggled to get viable low cost solutions to scale and reliability.

Conclusion

Traditional Hosting is cheap until you want something more than the standard package. Extras cost...well...extra! And from a pricing perspective it commonly ends up in what I call: Scale Fail! Start-ups don't have the money to burn on a rack with a beefy server that won't hit full potential in the first year, and may never get a chance at all!

Once you clear away the Vaseline-edged, rose-tinted, misty-eyed view of the world, estimating the success of your start-up needs to be based in reality, and whilst renting a big juicy server is fun and can cause significant overload to your saliva glands, I guarantee that you'll start feeling the sharp, sour, pang of regret approximately, no exactly 3 months in! Been there....done that.

I'll caveat it all of course with this one simple fact: I've never put anything substantial in the cloud before and I have no idea if it's going to work, but one thing is for sure: the costing model sure is a hell of a lot better from what I can see, and there are enough successful cloud projects out there already for me to be confident enough to have a fair crack at it. For these reasons and more I'll get to in future posts, we at cozwecan.com need the cloud - perhaps more than it needs us...

I'd be interested to hear if you have any particular views on this topic, and next time, I'll be going into more detail about the choice(s) of cloud solutions I'll be going with for cozwecan.com

Over and out!

Rob G

The cozwecan technology stack

noreply@blogger.com (Robert Greyling) — Thu, 25 Jun 2009 22:28:00 +0000

Greetings all!

I know we've been a little quiet lately, but that's because we've just had a great two week vacation visiting family overseas, and catching up with my sister Frankie (co-author on the cozwecan blog) in South Africa. We didn't get as much work done as we might have liked, but at least we can say we did literally "unplug" for a few days. I don't think the value of that can EVER be over estimated. I feel refreshed and ready to get back to work...

So without any more rambling, let me introduce you to the cozwecan.com technology stack as it stands in development today. I'll tell you when it changes next week, and then again the week after that ;-)

The website

The website technology I've chosen is the ASP.NET MVC Framework - is there an acronym for the word "Framework"? Coz then I could just say it in one massive acronym...awesome! Version 1.0 has just recently been released, but I've been playing with it since the early CTPs.

The dynamic bits and pieces

No dynamic website today, worth its salt, is without some form of established JavaScript Framework. Or, you could go ahead and roll your own if you think it's a good idea. If you do though, I'm afraid the Dr. Cox in me just has to force his way out thusly: "Any other day I’d say no, but today I'm gonna go ahead and just say no." - been there, tried that - no thanks!

My personal weapon of choice is jQuery, but I can also highly recommend MooTools and YUI. I've used all three and they all do a good job of abstracting the various browser nuances, but I generally come back to jQuery for two reasons: I love the fluent chaining paradigm, and it has a kick-ass plug-in extensibility model. I'll go into more depth on another post about how I'm using jQuery on cozwecan.com.

The languages

Well, I'm pretty sure you've guessed already that it's a .NET platform, and yes, C# is my language of choice for this project. However, there just so happens to be a rather chunky piece of work coming up that is very suited to a more functional approach. As you can imagine with a photography site, there are a lot of image processing and background tasks that have nothing to do with the website work flow, and I'm still trying to decide whether to go for something like F#, or if I should rather take this opportunity to see what .NET 4.0 and the DLR and some of the more dynamic approaches might offer. I'm open to suggestions here, and I'll certainly be blogging about my experiences in this arena.

General Storage

OK, so it's a photography based website. Needless to say, we're going to need a gig-or-two here and there to store said media. Ahem.... all right, all right, so we're going to need TERABYTES dammit! Where, pray-tell does one go to fulfill such lofty aspirations? Well one thing's for sure, you can't go to your traditional hosting providers, but that's a topic for another blog post. Long story short, I've got two possibilities on the table: Amazon's S3 and Microsoft's Azure Blob Storage. I'm already leaning towards one of these, so stay tuned to find out which one and why...

The Database

This one is a little tougher, of course there's Microsoft SQL Server, which I have worked on for many years and have tons of man hours spent troubleshooting and grinding away bottlenecks. It'd be a shame not to put any of that experience to good use it seems. Or maybe I should try something new? What about the cloud solutions on offer? If I'm going for Microsoft or Amazon on general storage, why not take advantage of their Table Storage or Simple DB respectively? Can you feel it? I can! Feels like yet another blog post for discussion... how excitin' !!

and of course – work flow

Due to the asynchronous nature of some of this solution, there will be a need to spin up some queues for worker processes. Of course there's trusty old MSMQ, or the shiny new Azure Queues, and of course, the already well established Amazon Queue offering. I'll be looking into each one of these discussing the pro's and con's before making a decision.

What about hosting?!

This doesn't strictly form part of the technology stack, but since some of the technologies on the table are quite specific, this may lead me down a path that presents very few hosting choices. Azure in its current form springs to mind. I need to be very careful of this because it doesn't just work like a LEGO set where I can pick and choose the pieces with a guarantee that they will work or host together. I'll definitely be discussing the advantages and pitfalls in more detail soon.

But until then, feel free to ask questions here regarding the technology choices, or you might have some suggestions. Either way, I'd be keen to hear your thoughts...

Until next time...over and out!

Rob G

Let's get technical!

noreply@blogger.com (Robert Greyling) — Sat, 06 Jun 2009 21:28:00 +0000

Hi everyone,

Thanks for coming along. In this post, I'm going to outline the kinds of technical articles I plan on publishing here. Hopefully that'll help you decide if I intend to cover anything in the near future that may be of interest to you and hopefully, if I get some feedback I'll have a good idea of your order of preference...your suggestions or requests are most welcome!

On with the show

When building a new website (or any software product), a good portion of my time at first is spent just researching the different applicable technologies out there - both "established" as well as "up-and-coming".

Depending on when you plan on launching the site, it can sometimes be advantageous to piggy-back the timing of your release on top of that of a larger company's brain child. As an example, Microsoft is currently promoting the virtues of their new cloud offering - the Azure Services Platform currently in CTP. If your product is good enough and happens to show off the advantages of using their platform, then there can be an opportunity for early adopters to get some "free marketing" if they play their cards right. Unfortunately, from what I've seen, this often comes down to being in the right place at the right time, or knowing a guy, who knows a gal, who knows....well, you get the idea.

But that doesn't stop you from trying to hitch a ride on roller blades right behind their victory parade. You should be persistent with your activity in the community space around the technology you've chosen, and take advantage of the many ways you can get noticed these days. This will all help build momentum towards promoting what you've got to offer. Well - that's the theory anyway, and that's the main reason I've decided to talk about my wanderings through the technological landscape, where I've stumbled a few times (who am I kidding - many times!), and those are probably some of the most valuable things I've got to talk about.

Not for one second am I trying to tell you that I've made it to the other side of the landscape. Quite the opposite in fact - I'm still knee deep, and loving every minute of it. I have now chosen this place as my home, and wish to remain here for many years to come. I know it may sometimes be wild and unpredictable, but I'd like to think I've learned how to survive by foraging for sustenance the first few years, and then by learning to hunt proactively as my experiences taught me. One day I hope to be included at the top of the food chain here - but I certainly hope that doesn't happen too soon because I really do enjoy the adventure - and I hope that you enjoy coming along for the ride...

Topical by nature

Without further ado (and yes, I know it's been quite an "ado" up until now), here are some of the topics I intend to cover in due course...

Firstly, I'll be introducing the cozwecan.com technology stack of course, and this will set the basis for many of the articles to follow.
I'll talk about considerations surrounding hosting, both traditional and cloud-based and how that can affect the bottom line.
I'm also going to delve into actual code, design and best practices that I've adopted as part of my toolbox over the years. I don't pretend to have invented them, but I'm a firm believer in standing upon the shoulders of giants, and I've learned a great deal from the leaders in our community.
I tell you a little more about some of the tough technology decisions and choices I've made along the way and why I made them. There are still a fair few to make though - so perhaps you can help!
Short articles specifically written "for dummies" - and I count myself in that group too! There's nothing worse than trying to dig into a new technology and all you can find are complex examples that assume way too much! So I'll share with you what I've learned using a simplistic approach and you get to tell me if it works or not!
Spotlights on specific bits of technology and tools I've used to make life a little easier. I like to dabble with many different platforms, but I've been making money using .NET, so you can probably expect that to be the main flavour here. I'd like to expand on that some day though....who knows?

I think that's a fairly broad and adequate description of where I think my posts will take you. If that floats your boat, then I look forward to discussing it with you.

Look out for them coming your way...

Rob G

RobertTheGrey

Spark and jQuery Templates learn how to play nice

The Problem

The Workaround

One Solution

Index.spark

browsing-image-template.htm

OK – Now gimmeh teh dllz

Conclusion

Don’t just get the Spark View Engine - NuGet it now

What’s the difference?

Conclusion

Don’t you tell me where to put my damn views – I’ll tell you!

So What?!

OK – so where are we going with this?

Sold! How do I use it?

Conclusion

Elegant MVC with Spark - The way views were meant to be

Abstract

Watch it with bonus content!

Spark Bindings – are you tired of eating “Tag Soup” yet?

Where we came from

Show and tell

Power of Abstraction

Power to Invent new HTML Tags

Power to Augment existing HTML tags

OK, OK! What does this Bindings.xml look like?

Power of Overloading

Can I have multiple Bindings.xml in a project?

Now you’re just being silly!

This my friends is the way MVC views were always meant to be…

Don’t stop now…

I don’t want your stinkin’ code comments

Why?

Let’s face it

Going even further

OK enough with the philosophy – gimme an example!

Exception to every rule

Conclusion

SparkSense gets its first outing

Supported

Not Supported

Installation

How to use it

Bugs (Update)

Conclusion

Pragmatic Spark – Turning it up to eleven

Abstract

Agenda Points

In closing

Update

Is Razor just a wolf in Spark’s clothing?

Coming soon

Disclaimer

First the good points

Spark’s clothing

Code oriented vs. Mark-up oriented

Enter the wolf

Apples with Apples (and Oranges)

Razor

Spark in code

Spark in mark-up

Open Source

Conclusion

SparkSense: Getting started - where’s a plumber when you need one?

First things first

No shortcuts

Moving parts

Plumbing bits

The Code

Conclusion

Building an IntelliSense Engine for Spark in Visual Studio 2010

Background

Documentation can only get you so far…

Productivity

What’s a developer to do?

With a little help from my friends…

So what’s on the menu?

Spark learns to master the Fubu View

The goal