You can get the code for ASP.NET MVC 2 at http://github.com/martijnboland/MvcPaging/tree/mvc2 (mvc2 branch of the MvcPaging repository).

In the recent weeks we’ve seen several control vendors come up with toolkits that target ASP.NET MVC. Personally, I don’t see anything that might make me starting to consider picking one of these toolkits to speed up development. Why on earth would I prefer a wrapper around jQuery UI or shoehorning existing WebForms controls in MVC views?

The beauty of ASP.NET MVC is that it embraces the web as it is and this automatically involves HTML, CSS and Javascript. Don’t be afraid for that. The combination can be so powerful! Why aren’t there any large component vendors for PHP, Rails, Django etc? Isn’t it probably possible that these components are not required to do proper web development?

The control vendors seem to be targeting people who come from a Windows background that don’t want to learn HTML and Javascript, but from my experiences I can say that those people should really stick to WebForms.

There are lots of ‘legacy’ ASP.NET WebForms applications out there in the wild. What if you want to create new functionality or rebuild an existing part with ASP.NET MVC, but you can’t (or won’t) create a separate new project?

The simple solution is to add the default MVC folders (Content, Controlllers, Scripts, Views etc.) to the root of the web project, add references to the MVC binaries, modify web.config and add the MVC GUID to the ProjectTypeGuids in the project file. A major drawback however is that it pollutes the root of your carefully structured application. This post will show you how you can logically separate the new MVC pieces from the existing WebForms app in a single project.

Isolate the MVC bits

  A simple requirement: I want that all my MVC folders reside in the folder /MyMvcApp and I also want that all urls of the MVC app start with /mymvcapp. No interference with my old WebForms app please.

Area’s

About a year ago, Phil Haacked showed a concept called area’s to partition an ASP.NET MVC application. After that, Steve Sanderson came up with an improved version of the concept.

Although designed to partition an MVC application, area’s are also useful when we want to isolate our MVC application from our existing WebForms app. The solution from Steve Sanderson almost completely fits our needs, follow the link for more technical details. The only thing I removed was the usage of an Areas subfolder in the project where all the individual MVC sub-applications. Simply didn’t need the extra subfolder and url of the MVC app is closer to the physical structure.

So, I implemented area’s with a specific AreaViewEngine that can lookup views based on the area name and added the extension to the RouteCollection class to add area information when mapping routes. This is how Global.asax.cs looks:

protected void Application_Start(object sender, EventArgs e)

{

    ViewEngines.Engines.Clear();

    ViewEngines.Engines.Add(new AreaViewEngine());

    // Routes

    RegisterRoutes(RouteTable.Routes);

}

public static void RegisterRoutes(RouteCollection routes)

{

    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.IgnoreRoute("{*favicon}", new { favicon = @"(.*/)?favicon.ico(/.*)?" });

    routes.CreateArea("mymvcapp", "WebFormsMVCDemo.MyMvcApp.Controllers",

        routes.MapRoute("mymvcapp-defaultroute", "mymvcapp/{controller}/{action}/{id}", new { action = "Index", controller = "Home", id = "" })

    );

}

With the ViewEngine and routes in place, we’re able to run the MVC app from the url /mymvcapp. To make sure the WebForms url’s still work, we just have to add some ignore statements in Global.asax.cs (in our case, exclude .aspx and .ashx from routing):

public static void RegisterRoutes(RouteCollection routes)

{

    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.IgnoreRoute("{*allaspx}", new { allaspx = @".*\.aspx(/.*)?" });

    routes.IgnoreRoute("{*allashx}", new { allashx = @".*\.ashx(/.*)?" });

    routes.IgnoreRoute("{*favicon}", new { favicon = @"(.*/)?favicon.ico(/.*)?" });

    routes.CreateArea("mymvcapp", "WebFormsMVCDemo.MyMvcApp.Controllers",

        routes.MapRoute("mymvcapp-defaultroute", "mymvcapp/{controller}/{action}/{id}", new { action = "Index", controller = "Home", id = "" })

    );

}

One caveat: when performing the request for /mymvcapp without controller name (and action), the Default.aspx that comes with the MVC projects was loaded, but area’s seem so cause a problem with the default one. Instead of rewriting the url from ‘default.aspx’ to ‘/’, I had to rewrite to url to ‘Home/Index’:

public partial class _Default : Page

{

    public void Page_Load(object sender, System.EventArgs e)

    {

        string pathToRewriteTo = Request.Path.ToLowerInvariant().Replace("default.aspx", "Home/Index");

        HttpContext.Current.RewritePath(pathToRewriteTo, false);

        IHttpHandler httpHandler = new MvcHttpHandler();

        httpHandler.ProcessRequest(HttpContext.Current);

    }

}

I’m under the impression that I’m missing something very simple, but couldn’t get my fingers behind it, so if you know it, please comment.

That’s it. I created a sample project with both WebForms and an MVC app in a subfolder. You can download it here.

But times have changed. Both platforms are moving. PHP now has a whole bunch of application frameworks (Zend, CakePHP etc.) that encourage good application design and also since PHP 5, the programming language has improved a lot. On the other hand, with the release of ASP.NET MVC, it has become much more easy to render clean HTML and we can finally leverage all the cool client-side toolkits that are out there without having to work around the quirks of Web Forms. 

So, with this movement, we see that both platforms grow towards each other. More and more developers come to have a look over the fence to see what’s happening at the neighbours place.

Two concrete examples:

• I’m consulting a little at a PHP shop that is moving towards .NET. They found Visual Studio and C# very cool, but the Web Forms issues regarding clean HTML etc. made it an absolute no-go. ASP.NET MVC is what made them switch.
• Just watched the ASP.NET MVC Mix 09 presentation of Rob Conery (Microsoft) and he showed lots of things that were clearly inspired by how PHP apps like WordPress work.

I like this movement! As a .NET developer, I find it very refreshing and inspiring to mix and mingle with ‘the other side’. There is a lot we can learn from each other to make better web applications.

This morning, I was shocked when I found out how much the development of my pedalboard went through exactly the same stages as the way I’m building ASP.NET web applications. First let’s see where I’m coming from:

In the picture above you can see a large yellow device. This is the Line 6 Distortion Modeler. It claims that it can produce all the classic distorted guitar tones that you’ll ever want and to a certain extend this is true. The sound is alright and the possibilities are huge. But also: the output (sound wise) that this device produces is always less than the original pedals that it’s trying to emulate. Also, the switches are a little bit unreliable and cause a little gap when changing sounds. I tried to fix this, but the device is very inaccessible and doesn’t lend itself very well for modifications or extensions.

Less is better

These days I’m back to where I came from: two simple pedals that don’t have a gazillion options but just do their work and are very efficient:

On the left we have the Proco RAT and on the right it’s the Digitech Bad Monkey (‘told you we’d have some guitar-geek talk in this post, remember?). These guys are simple, reliable and their output is just the way I want my distortion to sound without losing dynamics and tone. Full control!

So, what does this have to do with ASP.NET web development?

Nothing of course It just struck me that at about the same time I switched from ASP.NET Webforms to MVC, I also changed my pedalboard to accomplish the same result: making the end result better with a more simplistic approach. The yellow monster in the first picture is like Webforms with ASP.NET AJAX where I have a love-hate relationship with. The two pedals in de second picture feel like the MVC and jQuery combination (loosely coupled, only connected with a little patch cable), that brought a lot of fun lately and work very well for me.

Yeah, great analogy, NOT! I didn’t subscribe to read this blah about some guitar thingy.

Well it just something that went through my mind this morning and writing about it also gives me a chance to post some crappy gear pictures, like it or not. Here’s another one for free:

P.S. the empty spot above the pedals is normally reserved for my Electro Harmonix Memory Man Deluxe but this drama queen is broken at the moment and deserves a single post of its own.

My biggest gripes are:

• The whole development experience is awful. Yes, you can create custom webparts, but I’ve yet to come across the one that isn’t a big ball of mud. Also, the entire cycle of compiling, deploying and testing takes way too long to be productive at all. One minute is pretty common. Gosh, I wonder why all these projects are late every time ;
• The HTML output is a mess. Not so much a problem for intranets, but for public sites it is. With a zillion tweaks, it is possible to fix it, but then again, no wonder these projects are late every time;

I’ve been thinking how to improve this situation. Sure, I could say: “just don’t use SharePoint for your public web sites”, but companies are going to push everything to Sharepoint anyway. The whitepapers and consultants will tell them that everything is possible and it’s from Microsoft, so it’s a safe bet. We (as in Microsoft developers) simply have to deal with it the next years.

A Cunning Plan

First: let’s focus on publishing sites. I want to have:

• Clean standards-based HTML;
• Clean url’s;
• The ability to add custom applications as a feature without being restricted to webparts, or even better: develop applications standalone and deploy to Sharepoint when they’re ready;
• Leverage the SharePoint infrastructure (sites, lists, security, etc);

Looks impossible but is it really?

Couldn’t we not drop in System.Web.Routing, create a special SharePointRouteHandler, that sets up required sharepoint infrastructure and delegates the request to a Controller to have ASP.NET MVC within the SharePoint context? I think it’s hard and complex, but not impossible. We could leverage all strong points of ASP.NET MVC like separation of concerns, testability, clean HTML together with the huge foundation that SharePoint offers.

Plan B

Microsoft is already working on this situation and the next version of SharePoint will address the situation properly.

Now, please tell me that I’m a: ambitious, b: naive or c: completely insane .

You can download the updated demo here.

• Validation in ASP.NET MVC – part 1: basic server-side validation
• Validation in ASP.NET MVC – part 2: custom server-side validation
• Validation in ASP.NET MVC – part 3: client-side validation with jQuery validation

In the previous posts, I described how we implemented model-based validation on the server-side in Cuyahoga with ASP.NET MVC and as the icing on the cake, we also added some client-side validation (also model-based).

Now, everything can be found in the Cuyahoga SVN sources but I have to agree that it can be a daunting task to check out the complete sources and find all pieces of the validation puzzle. Therefore, I’ve created a little sample application with everything from the previous posts combined.

Hopefully, this will make things a little bit clearer. You can download the sample app here. Visual Studio 2008 and ASP.NET MVC Beta are required.

Enjoy!

• Validation in ASP.NET MVC – part 1: basic server-side validation
• Validation in ASP.NET MVC – part 2: custom server-side validation

In the first two parts, I showed how you can perform validation on the server side with Castle Validation attributes and extend that model with custom validation logic. With this, we have everything we need to properly validate our model.

For a better user experience though, it would also be nice that we could re-use (part of) our validation logic on the client-side. Luckily, lots of others have already looked into this and the only thing I had to do was to throw everything together and stir it a little bit .

The ingredients are:

• The jQuery validation plugin (an obvious choice, since we were already using jQuery in Cuyahoga);
• Monorail client-side code generator for jQuery validation (originally contributed by Gildas, but also many credits to the Castle Monorail guys for creating such a flexible infrastructure);
• Model-based Client-side Validation for ASP.NET MVC (very inspiring blog post by Steve Sanderson).

How it works

1. The client-side validation is called via an HtmlHelper extension method ClientSideValidation:
   <%= Html.ClientSideValidation(ViewData.Model, “my_form_id”)%>;
2. The HtmlHelper extension requests an instance of a BrowserValidationEngine that returns the client script for validation;
3. BrowserValidationEngine has a reference to an IValidatorRegistry instance that returns all (Castle) validators for the given model;
4. For each validator, the referenced IBrowserValidatorProvider generates the appropriate client script;
5. Finally, all generated client script code is combined and sent to the browser in a single javascript block.

The existing Monorail codebase proved to be of great value and could be used almost seamlessly. The only difference is the way the client code is generated. Originally, the validators generated css class attributes for the Monorail form helpers, but we don’t have those with ASP.NET MVC, so all client code is generated as jQuery validation rules.

Below, you can see the output of the validation helper for the new user form in Cuyahoga:

<script type="text/javascript">

$(document).ready(function() {

    jQuery.validator.addMethod('notEqualTo', function(value, element, param) { return value != jQuery(param).val(); }, 'Must not be equal to {0}.' );

    jQuery.validator.addMethod('greaterThan', function(value, element, param) { return ( IsNaN( value ) && IsNaN( jQuery(param).val() ) ) || ( value > jQuery(param).val() ); }, 'Must be greater than {0}.' );

    jQuery.validator.addMethod('lesserThan', function(value, element, param) { return ( IsNaN( value ) && IsNaN( jQuery(param).val() ) ) || ( value < jQuery(param).val() ); }, 'Must be lesser than {0}.' );

    jQuery.validator.addMethod('numberNative', function(value, element, param) { return this.optional(element) || /^-?(?:\d+|\d{1,3}(?:\.\d{3})+)(?:\,\d+)?$/.test(value); }, 'Not a valid number.' );

    jQuery.validator.addMethod('simpleDate', function(value, element, param) { return this.optional(element) || /^\d{1,2}\-\d{1,2}\-\d{4}$/.test(value); }, 'Not a valid date.' );

    $("#userform").validate({

        rules : {

            UserName: {  rangelength: [1, 50] , required: true },

            Password: {   required: true , rangelength: [5, 50] , equalTo: "#PasswordConfirmation" },

            PasswordConfirmation: {   equalTo: "#Password" , rangelength: [5, 50] , required: true },

            FirstName: { rangelength: [1, 100] },

            LastName: { rangelength: [1, 100] },

            Email: {   required: true , rangelength: [1, 100] , email: true },

            Website: { rangelength: [1, 100] }

        },

        messages : {

            UserName: {  rangelength: "The username must be between 1 and 50 characters" , required: "The username may not be empty" },

            Password: {   required: "The password may not be empty" , rangelength: "The password must contain at least 5 characters" , equalTo: "The password must be the same as the confirmation password" },

            PasswordConfirmation: {   equalTo: "The password must be the same as the confirmation password" , rangelength: "The password must contain at least 5 characters" , required: "The password confirmation may not be empty" },

            FirstName: { rangelength: "The firstname must be between 1 and 100 characters" },

            LastName: { rangelength: "The lastname must be between 1 and 100 characters" },

            Email: {   required: "E-mail address may not be empty" , rangelength: "E-mail address must be between 1 and 100 characters" , email: "Invalid e-mail address" },

            Website: { rangelength: "The website url must be between 1 and 100 characters" }

        }

    });

});

</script>

which results in this:

Summarizing validation

In this series of posts, I showed how we deal with validation in Cuyahoga and ASP.NET MVC. Personally, I think the nicest part of it is that we have our validation rules centralized and we only have to add one line of code to the view to enable client-side validation.

The code can be found in Cuyahoga SVN and more specifically in the validation sections and the ASP.NET MVC manager. I’ll try to make a standalone sample project with all the validation stuff somewhere in the near future.