Wow.  This was only posted 6 hours ago and i feel like I'm the last to hear the news.

I'm havin alot of fun with Balsamiq Mockups today.  Here's my latest endeavor, I'm still learning so it's not great but it did help get over a hump with the project i'm working on.

via Tobin, i decided to check out Balsamiq Mockups.  Wow.  This tool is frickin awesome.

Food Tracker

As part of starting a cross fit program, I'm tracking(trying to anyway), I want to get better at tracking what I eat.  Since I suck at coming up sample project ideas, i figured that a food tracking app would be a good way to play around with ASP.NET MVC and MonoRail as a sample application.  I had come up with a sketch of the input form this weekend, but this morning the one I did with Balsamiq's online tool came out WAY better.  Check out the sketch:

The tools is surprisingly fun to use.  There are a ton of controls to pick from and anything you choose you can customize the text and data.

The grid in my sketch was a snap to set up, drag a grid, type in what you want for the header text, and a few rows beneath and you're done.

The designer also hasguidelines, so when you drag a control, similar to Visual Studio's WinForm designer, you get the vertical and horizontal guidelines that help you make stuff look good.

Anyway, if you have drawn diagrams of screen layouts before on paper, it's worth takin a look at.

 

 

 

 

 

 

 

OK.  So I added some server side rule checking as a backup to the client side stuff.  In order to test this out, I had to turn off client side validation.  Right now it only returns a list of validation error messages, but I have some plans for that mechanism.  The controller method that handles the form post now looks like this:

 

	[AcceptVerbs("POST")] public ActionResult Edit(int id, Customer customer) { customer.ID = id; if (!Model.IsValid(customer)) { ViewData["errormessages"] = Model.GetErrorMessages(customer); return View(customer); } RepoFactory.Get<Customer>().Save(customer); return this.RedirectToAction("index"); }
1 2 3 4 5 6 7 8 9 10 11 12 13

The only change i made to the Customer class so far was that I added a custom model binder attribute to the customer.  That attribute looks like this:

	public class CustomerBinder : IModelBinder { public object GetValue(ControllerContext controllerContext, string modelName, Type modelType, ModelStateDictionary modelState) { NameValueCollection form = controllerContext.HttpContext.Request.Form; return new Customer { FirstName = form["FirstName"], LastName = form["LastName"] }; } }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

And the customer class looks like this(i updated the validation attribute constructors to match the changes i made.

	[ModelBinder(typeof(CustomerBinder))] public class Customer : IModel { public int ID { get; set; } [ValidateLength(3, 30, "First name must be between 3 and 30 characters in length.", true)] public string FirstName { get; set; } [ValidateMaxLength(30, "Last name is required and cannot exceed 30 characters.", true)] public string LastName { get; set; } }
1 2 3 4 5 6 7 8 9 10 11 12 13

and the server side validation ends up rendering the following view(reminiscent of lammo validation summary in webforms):

This one bugs me.  Scott Guthrie has a huge post on some new form stuff that comes with preview 5.  Great info there.  However, looking at the validation examples, you can see that the validation depends on on checking business rules and throwing exceptions if any of the rules fail; then in the controller you catch a general System.Exception, update some stuff for the view, and return the same view.  Why is this bad?

Well, an exception didn't really occur, it was made up because of failing a known business rule.  So basically, now you're using the throwing of exceptions to guide your workflow which makes your code hard to test and hard to follow.  I wouldn't  normally comment on something like this, but I saw another example of this by Stephen Walther here. 

People, please don't throw exceptions in non-exceptional situations.

OK.  So why is it, that most of the validation examples I see for ASP.NET MVC always include allowing the user to submit potentially invalid form fields to the server?? 

If your validation "framework" requires you to submit a form to the server prior to being validated, then your framework sucks.  Period.  Definitely have the server side validation.  Server side validation exists to double check that you didn't fuck up and miss something on the front end with client side validation.

 I implemented a VERY lame outline of something that I would expect from a framework.  Simple attributes are applied to properties that are bound in the view.  My example expects that you are using jQuery.  This is not good. 

A validation framework that works on the client, should not care about it's implementation but should have a default implementation. So it shouldn't care if you're a jQuery fan, or prototype fan, or not a fan of javascript at all;it should establish some common methods that you are free to implement yourself.

If Microsoft were to implement a good validation framework, here's what I would require from them.  Zero installation.  Requiring that you install the Enterprise Library to get any sort of validation bennies is absurd, please stop doing this.

The framework would default to Microsoft's home grown javascript library, but with VERY little effort, could be switched out with prototype, jQuery, or any javascript framework you want.

Here's my scratch project trying to come up with a better validation framework.  It's tied to jQuery, which I don't like.  It looks for any element(i've only concentrated on an input element of type="text", so it doesn't do much) that contains a 'validate' attribute.  then inspects other css classes that have been tacked on that indicate some sort of validation to perform on the element.  I'm thinking of also sticking other attributes on the element when it's generated, not XHtml-ish, but oh well.

It's based on attributes that implement my IModelValidator interface which looks like this:

	public interface IModelValidator { bool Validate(object value); }
1 2 3 4

The ValidateRequiredAttribute tests to make sure a value exists and looks like this:

	public class ValidateRequiredAttribute : System.Attribute, IModelValidator { public bool Validate(object value) { if (value == null) return false; if (System.Convert.ToString(value).Length == 0) return false; return true; } }
1 2 3 4 5 6 7 8 9

ValidateMaxlengthAttribute checks to make sure the length of a value does not exceed a max value:

	public class ValidateMaxLengthAttribute : System.Attribute, IModelValidator { private int _maxLength = 0; public int MaxLength { get { return _maxLength; } } public ValidateMaxLengthAttribute(int maxLength) { _maxLength = maxLength; } public bool Validate(object value) { if (value == null) return false; return System.Convert.ToString(value).Length <= this._maxLength; } }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Implementing the attributes on a model should look something like this:

	public class Customer : IModel { public int ID { get; set; } [ValidateRequired(), ValidateMaxLength(30)] public string FirstName { get; set; } [ValidateRequired(), ValidateMaxLength(30)] public string LastName { get; set; } }
1 2 3 4 5 6 7 8 9 10

There were some quirks in my last bare bones mvc project.  Some stuff wouldn't work when rendering views in the browser.  Long story short, I needed this:

 

	<system.codedom> <compilers> <compiler language="c#;cs;csharp" extension=".cs" warningLevel="4" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"> <providerOption name="CompilerVersion" value="v3.5"/> <providerOption name="WarnAsError" value="false"/> </compiler> </compilers> </system.codedom>
1 2 3 4 5 6 7 8 9

 Anyway, here is the new project template.

.aspx.cs and .aspx.designer.cs

These files are not needed in asp.net mvc views, but when you add the default mvc pages supplied with the mvc install, you will get them by default.  I decided to play around with removing them completely and remembered that there are some things to consider when adding views to your asp.net mvc application(and this also applies to "old school" webforms style apps).

@Page Directive and Web.Config

Most, if not all of the attributes of the @Page directive can be set sitewide in the web.config via the pages element and the compilation element, eliminating the need for the @Page directive altogether.  The important attributes are Language, MasterPageFile, and Inherits.

Weird Errors

Removing the @Page directive however causes some weird errors to appear in the errors list. They appear to be indicating some VB.NET type errors(note the End Namespace reference below). They don't affect anything, they are just annoying.

Beware: Master Pages Everywhere

This is one to think about, maybe.  Everytime you add a new mvc view content page, you have to pick a master page.  If you did this on every single view content page and then decide you want to use a different master page, you would have to go to each view content page and change the name of the master page file.  Unless of course if you decide to just replace the contents of one master page.

Sometimes you want the ability to test different master pages concurrently.  Perhaps you are coming up with several site designs you need to show your customer to let them pick which one looks best.  This requires easily switching master pages files.  You can do this in the web.config in the pages element. After specifiying a base page for all view pages and the master page file, the element would look something like this:

	<pages pageBaseType="System.Web.Mvc.ViewPage" masterPageFile="~/Views/Shared/Site.master"> <namespaces> <add namespace="System.Web.Mvc"/> <add namespace="System.Web.Mvc.Ajax"/> <add namespace="Microsoft.Web.Mvc"/> <add namespace="System.Web.Routing"/> <add namespace="System.Linq"/> <add namespace="System.Collections.Generic"/> </namespaces> </pages>
1 2 3 4 5 6 7 8 9 10 11 12

Really Stupid Example

In my example for this post, one of the layouts looks like this:

And the other layout looks like this:

The point is that none of the content pages needed to be touched, just the web config, to display completely different layouts.

Here's the source code for the example(based on Mvc Preview 5) for this post.

Here's the upgrade for my previous bare bones preview 4 project template.  Follow the directions here to install the template.  Download the template here.  The difference in this template is that i left the references to to the assemblies to their default install location(where the preview 5 installer places them by default).  Also added in jQuery to the content folder and master page reference.