So what am I doing now? I moved to the "Global Consumer ISV Team", which is part of DPE (our evangelist arm), but rather than being managed out of the UK I report into Microsoft Corp in the US via the Server and Tools business. 

I am responsible for business development with the EMEA partners on an exclusive list of top consumer brands... so in practice that translates to working with these brands to identify mutually beneficial opportunities, projects, approaches, marketing, and networking that lead to their successful adoption of the Microsoft platform in key competitive arenas such as Phone, Tablet, and Cloud.

Bottom line? I'm playing with gadgets, talking to people, and sending emails, all with a focus on cool consumer-facing technology: pretty much what I love the most and do the best anyway. Keep in touch if you worked with me already, and say hello if I cross your path in my new role! Chances are I'll still blog once in a while, but that'll likely be on slightly different topics. Let's see what happens...

Our latest coinciding of ideas was a way to automatically inject HTML attributes for fields rendered as part of your model with Html.EditorFor. We’ve just blogged about it on our team blog – Adding Html Attributes in Templated Helpers, published the code on the MSDN Code Gallery under UkadcHtmlAttributeProvider, and pushed a working version to NuGet under UkadcHtmlAttributeProvider.

Have a read of the blog post to learn more. To try our solution just use the NuGet command;

Install-Package UkadcHtmlAttributeProvider

A few examples of attribute provider delegate registrations are below. Do let us know if you like the approach!

Output the aria-required attribute for required fields;

HtmlAttributeProvider.Register(

   metadata => metadata.IsRequired,

   "aria-required",

   "true");

This results in the following HTML for a string field;

<input aria-required="true" class="text-box single-line" … snip … />

Output an HTML 5 Custom Data Attribute (CDA) when the field contains a URL;

HtmlAttributeProvider.Register(

   metadata => metadata.DataTypeName == "Url",

   "data-url",

   "true");

 This results in the following HTML for a string field;

<input class="text-box single-line" data-url="true" … snip … />

Output the Square Root of a value of a number field as an HTML 5 CDA;

HtmlAttributeProvider.Register((html, metadata) =>

    {

        if (metadata.ModelType == typeof(Int32))

            return new[]

            {

               new KeyValuePair<string, object>(

                  "data-sqroot-value",

                       Math.Sqrt(

                          Convert.ToDouble(metadata.Model)))

            };

        return Enumerable.Empty<KeyValuePair<string, object>>();

    });

 This results in the following HTML for an Integer field;

<input class="text-box single-line" data-sqroot-value="4.58257569495584" … snip… />

OK so that last one is a bit arbitrary – but there’s a huge amount you can do here. Think of tab indexes, URLs for Ajax callbacks, CSS classes… the list goes on.

Head over to the blog post to read about how it works. And check out Stu’s follow-up post on some good real examples.

   1:  public static MvcHtmlString Region<TModel>( 

   2:     this HtmlHelper<TModel> html, 

   3:     Func<TModel, object> content) 

   4:  { 

   5:     var result = content(html.ViewData.Model); 

   6:     return html.Partial("_Region", result); 

   7:  } 

This accepts a Func<TModel, object> which is the Templated Razor Delegate. This is quite simply a snippet of Razor syntax that is executed to return markup as “result”.

   1:  @Html.Region(@<text>@Model.WelcomeMessage</text>)

I’ve combined my HtmlHelper extension with a partial view named _Region, stored in the Shared folder;

   1:  <fieldset class="demoregion"> 

   2:      <legend>A Region</legend> 

   3:      <div> 

   4:          @Model 

   5:      </div> 

   6:  </fieldset>

This would be way neater if I could use an @helper under App_Code, but in MVC 3 that feature doesn’t support using HtmlHelper, so you couldn’t use Html.Textbox in the template, for example.

The code is attached – easy huh?

My blog posts on doing conditional validation in MVC have always been popular, and I’m frequently surprised by where I find that code – customers often say to me “we found some guys blog with some code to do the validation we needed” and sure enough it usually turns out to be mine!

There are two problems though – firstly, my code was always intended to be a sample to get you started, and that meant I’d not written a comprehensive set of tests. Secondly, there are all sorts of validation cases that developers need that I hadn’t covered.

So I decided to refresh the code base, both with additional validators and with a pretty decent set of tests. The first Alpha (i.e. incomplete, probably buggy, etc, etc you have been warned ) release of this code is attached to this blog post.

What’s in the box?

There are four main topics included in the box;

• Conditional required validation. This is the most common requirement, and is often used for forms that have optional sections.
  • RequiredIfAttribute. This attribute says “this field is required if some other field has value X”. It is used as [RequiredIf(“OtherField”, “TargetValue”)]
  • RequiredEmptyIfAttribute. This attribute says “this field must be empty if some other field has value X”. It is used as [RequiredEmptyIf(“OtherField”, “TargetValue”)]
  • conditional-validation.js – a JavaScript file to does the above in the browser to match the server-side implementation
• Dependency validation. Sometimes the value of one field depends on another.
  • RangeDefinedByFieldsAttribute. This states “this field must be between the values in X field and Y field”. It is used as [RangeDefinedByFields(typeof(Int32), “MinField”, “MaxField”)].
  • There is also script in conditional-validation.js to do this in the browser.
• Validation groups. Sometimes a field is only relevant if the user clicks one of the buttons available; perhaps if they click Delete none of the edited fields must be entered.
  • RequiredForButtonAttribute. This states “the field is required if they user clicks button X”. It is used as [RequiredForButton(“ValidationGroupName”, “ButtonName”)]
  • RequiredEmptyForButtonAttribute. OK, you probably get the point now. I’ll let you infer what this does!
  • Html.SubmitForValidationGroup. To “play nice” with the RequiredForButtonAttribute and RequiredEmptyForButtonAttribute we need to ensure the buttons are created correctly, and we need a hidden field. This HtmlHelper extension handles this for us, and takes the form Html.SubmitForValidationGroup(“ValidationGroupName”, “ButtonName”)]
  • validation-groups.js – This JavaScript ensures that client-side validation groups work as well as server-side.

Note that all of these pieces work both server-side and client-side (in the browser) if you use the JavaScript included in /Mvc.ValidationToolkit.Harness/Scripts/MvcValidationToolkit/*.js.

Also, note that they all have MSTest unit tests and automated WaTiN UI tests that exercise both the JavaScript and Server implementations of each feature. I’m positive it needs more tests (for example different data types).

What do I need from you?

I must emphasise that this release is a preview. So what next? Well I want to know a few things;

1. What do you think? Is this useful?
2. What validators are missing?
3. What bugs have you found?
4. What testing priorities are there?

Please comment on this post if you’ve answers to those questions. But I also want to know where this should live and how it should move forwards. I would consider setting up a codeplex project if there were a few strong MVC & jQuery developers that wanted to add to and evolve the library. Or is this drop enough to get you started? Let me know your thoughts.

In the mean time, I may blog on using the attributes a little more if I get the chance.

Go Get It

To have a look at the code, download the attachment to this post and have a look in Readme.txt – the only thing you need to do is grab a couple of NuGet packages and everything should work. Note: if you’re running the WaTiN tests, run Visual Studio as elevated else you’ll just get timeouts.

Mvc.ValidationToolkit.Alpha.zip

“Project Silk provides guidance for building maintainable cross-browser web applications that are characterized by an intentional design, rich interactivity, and a responsive user interface (UI), resulting in an immersive and engaging user experience (UX). Such applications take advantage of the latest web standards, including HTML5, CSS3, and ECMAScript version 5, and modern web technologies such as jQuery and ASP.NET MVC3“

The highlights are mine -  because it is key to understand that this guidance isn’t just about code structure and separation of concerns, but also covers making your UI really sing. Check out the guidance here;

Landing Page:

http://msdn.microsoft.com/en-us/library/hh396380.aspx

Roadmap to navigating the guidance:

http://msdn.microsoft.com/en-us/library/hh404078.aspx

A video showcasing the output!

https://channel9.msdn.com/posts/Project-Silk-Mileage-Stats-Application

If you’re doing MVC and jQuery, you’ve got to check it out…

Something I’ve been wanting to blog about for a while now is “Project Silk”. This is Patterns & Practices latest round of web development guidance. Karl Shifflett  is the man at the wheel, so be sure to check out his blog. Silk is all about getting the structure of both server-side and script code right, and building truly outstanding interactive user interfaces with the latest and greatest tools on the Microsoft platform. That means they’re using MVC 3 and jQuery to create an appealing and enjoyable experience when using the fully complete Reference Implementation they’ve built… I think it looks great.

I hope to blog more on some of the detail of what they’ve been working on soon, but don’t wait for me – go check it out on codeplex here; Project Silk

Much of the work has gone into building jQuery UI “widgets”, and the guidance includes lessons they’ve learned from strapping all this together. The documentation is currently being reviewed so if you fancy having a read of the drafts that have been published head over to codeplex.

Keep that in mind and we’ll look at each in turn…

Script-on-top

What I’ve dubbed “script-on-top” is what I believe most developers do right now. That is, they look to sit JavaScript on top of the HTML and CSS; the script uses the HTML and CSS and manipulates them as though they are components just waiting to be orchestrated. You’ll often see code that looks a bit like this (I’m using jQuery);

   1:  $(document).ready(function () {

   2:      $('#combo').change(function () {

   3:          var value = $(this).val();

   4:          var result = myframework.getDisplayMessageFromServer(value);

   5:          $('#messagediv').html(result);

   6:      });

   7:  });

* Note that none of the script in this post is real. I just hacked it into notepad – but it demonstrates the point sufficiently.

There are some good practices there – not least the fact that the call back to the server is encapsulated within a reusable framework. This is layering, effectively creating a data access layer in JavaScript, and hence is following patterns that have been established for a long time for server-side code. The configuration for how to communicate with the server and the location of the server endpoint is all encapsulated within this framework.

However, I have a few problems with this approach.

1. I don’t like specifying element identifiers in JavaScript. Why? Because it feels wrong. It just does. Stick with me and you might start to agree. Fundamentally this comes down to the separation of concerns between CSS, HTML, and JavaScript.

2. If I have lots of drop-down lists that have very similar behaviour, I still have to wire up every single one. A lot of developers really do wire up every single one manually in code like that above. There are ways to apply behaviour in a blanket manner but none quite so good as my preferred approach… so hold that thought.

3. I don’t like the idea of having to write an entirely new User Interface “manager” component of some description. What often happens with the above approach is that when a page gets more complex developers create a central class that wires up all these events, maybe caches some data, and more. Why? Surely we’re done all that server-side, must I really Repeat myself (R capitalised in homage to DRY) on the client?

4. The URLs to each endpoint are embedded in the framework. But my URLs are “designed” on the server (especially if you’re using Routing, perhaps with ASP.NET MVC)… surely I don’t want to hard-code them in the script too?

Script-as-a-platform

So what is the alternative? I believe we need to turn our way of thinking about JavaScript on it’s head. Instead, think of CSS and JavaScript as defining a platform that our HTML mark-up simply refers to in order to build up a user interface. Rather than our JavaScript taking ownership of HTML elements, our HTML makes use of predefined JavaScript “behaviours” (yes, I know that is an emotive term for JavaScript so forgive me!) and CSS styles.

Such a mind-set leads to HTML that looks like this (I’m using ASP.NET MVC 3 with a Razor view);

   1:  <select 

   2:      data-getmessage-output="#messagediv" 

   3:      data-getmessage-source="@Url.Action("Message", "Ajax", new { item = "{placeholder}" })">

   4:  </select>

   5:   

   6:  <div id="messagediv"></div>

… and matching JavaScript a bit like this;

   1:  $(document).ready(function () {

   2:      $('*[data-getmessage-source]').change(function () {

   3:          var value = $(this).val();

   4:          var url = $(this)

   5:              .data('getmessage-source')

   6:              .replace('{placeholder}', value); ;

   7:          var output = $(this).data('getmessage-output');

   8:          var result = myframework.getDataFromServer(url);

   9:          $(output).html(result);

  10:      });

  11:  });

So what is the difference? The difference is that my JavaScript is a reusable component, and my HTML has output instructions to the client to make use of that component through the use of an HTML 5 Custom Data Attribute. It could easily have used a CSS class instead if the parameters to my component were simpler. The script is slightly longer, but it isn’t complex – and none of it will be repeated in individual pages.

As a result, the URL to the endpoint is no longer hard-coded in a JavaScript library. And all SELECTs that should have this behaviour get it automatically just by referencing this script. The pairing of output DIV and drop-down list is clearly defined in HTML, not tucked away in JavaScript somewhere. There are, in fact, no IDs in my JavaScript, which means that my HTML is completely owning the document structure while JavaScript provides behaviour for that structure... without detailed knowledge of it.

I can still create reusable JavaScript – in fact, my sample code could be hugely refactored into something much more reusable.

But most of all, there is no longer a need or temptation for a central orchestrating JavaScript component – our orchestrating is done by the HTML, which is generated server-side, so our server code is really pulling the strings. We’ve moved our mind-set from writing JavaScript to “make the UI work” into writing HTML that composes reusable JavaScript components and behaviours. The highlight is because I believe that’s a good summary description of what I’d encourage you to do.

Does It Matter?

Yes, I believe it does. Follow this composition approach and your JavaScript code will be easier to thoroughly test (because you won’t have lots of separate wiring up code for each page), and the act of composing will often feel simpler to the developer than writing imperative code to “pull strings” for any particular page.

So, what do you think?

On a related note, if you’re curious about my role in particular then check out my team’s blog series of “Meet an ADC”; mine is here. Our job title changed from Application Development Consultant (ADC) to Application Development Manager (ADM) so the acronym may be slightly different but the facts are still the same.

Step 1: Inside your form, add two Submit buttons. Add a name attribute to both (note it isn’t added by MVC by default);

   1:  <p>

   2:      <input type="submit" name="Command" value="Save" />

   3:      <input type="submit" name="Command" value="Delete" />

   4:  </p>

Note both have the same name.

Step 2: Inside your action, add a parameter that matches the name of the buttons;

   1:  [HttpPost]

   2:  public ActionResult Index(

   3:      Person person, 

   4:      string command)

   5:  {

   6:      bool saved = (command == "Save");

   7:   

   8:      if (saved)

   9:          // code removed

  10:      else

  11:          // code removed

  12:  }

Simple huh? You could write some clever extension method to inspect the posted HTTP values, but I find this approach far more elegant. It is really clear that I’m expecting the “command” to be posted to my action.

A part of me wonders if naming all your buttons the same contravenes the HTML specification, but I can find no evidence of this – it is an accepted practice for checkboxes and radio buttons of course, and I’ve found this to work well. If you know otherwise do shout up. Like it? Hate it?

Step 3: Well… let’s take it one step further and create an enum of commands;

   1:  public enum Command

   2:  {

   3:      Save,

   4:      Delete

   5:  }

Step 4: … and update our action method parameter’s type to be our new enum, and of course our logic to use it;

   1:  [HttpPost]

   2:  public ActionResult Index(

   3:      Person person, 

   4:      Command command)

   5:  {

   6:      if (command == Command.Save)

   7:          // code removed

   8:      else

   9:          // code removed

  10:  }

Hey presto! Strongly typed clear code that reacts to which button was clicked.

Some time ago I blogged on Conditional Validation in MVC, and Adding Client-Side Script to an MVC Conditional Validator. A number of people have asked me to update the sample to MVC 3, so guess what – it’s your birthday! The main differences are summarised below… and check out the code download to see it working. I’d recommend reading my previous two posts if you want the background on how it all works.

Important: Note that this is by no means a complete solution, and neither were my previous ones. They’re POCs intended to get you started! For example, you may need to handle different data types (Int32, perhaps) or control types (radio buttons, perhaps) yourself. I’d also recommend thoroughly testing the code. Enjoy…

The Attribute is the Adapter!

Hooray! There’s no need for an adapter class anymore. The Attribute instead can implement an interface;

 1: public class RequiredIfAttribute : ValidationAttribute, IClientValidatable

 2: {

 3: }

IClientValidatable demands that we implement GetClientValidationRules on our Attribute, in a very similar way to the example in my previous posts. That’s much neater.

Our Context is Different

I’m not particularly happy with this workaround right now, so if you’ve a better solution let me know. The issue is that when we are emitting the Client Validation Rules described above, we must calculate the Identifier that the control we depend upon will have when it is written out into the HTML. To do this, we call;

 1: string depProp = viewContext.ViewData.TemplateInfo.GetFullHtmlFieldId(this.DependentProperty);

However… now that this method is being called from within the Attribute itself, rather than within an Adapter, that means it is executed while the field the Attribute applies to is being rendered. That means the context is one level lower than it was for my original solution. MVC tracks a “stack” of field prefixes in this context whilst rendering fields, and each time it ducks into a new template it adds a prefix. So when rendering our Person entity (which is a variable called model for example) the prefix would be “model_”. When rendering Person’s Name, it would be “model_Name”. And if we had an address field on Person, that in turn had a City field, it could become “model_Address_City”. Note the “model_” bit often isn’t there – it depends, and I’m simplifying

What this means is that when calculating the dependent property ID with the code above, this context is “City” or “Country” (as the attribute is used on two fields it is called twice) rather than String.Empty. Which means it calculates the HTML ID of the “IsUKResident” field to be “City_IsUKResident”, instead of “IsUKResident”, and of course “City_IsUKResident” doesn’t exist. Therefore I have to post-process it to strip off “City_”.

Yuck. Anyone know how to navigate the prefix hierarchy to stop this happening? It does seem to work though.

jQuery Validation

Next up, we use the jQuery.validate library to write our validation functions. This is now the only option, instead of one of two options as it was before. My validator looks like this;

 1: $.validator.addMethod('requiredif',

 2:     function (value, element, parameters) {

 3:         var id = '#' + parameters['dependentproperty'];

 4:  

 5:         // get the target value (as a string, 

 6:         // as that's what actual value will be)

 7:         var targetvalue = parameters['targetvalue'];

 8:         targetvalue = 

 9:           (targetvalue == null ? '' : targetvalue).toString();

 10:  

 11:         // get the actual value of the target control

 12:         // note - this probably needs to cater for more 

 13:         // control types, e.g. radios

 14:         var control = $(id);

 15:         var controltype = control.attr('type');

 16:         var actualvalue =

 17:             controltype === 'checkbox' ?

 18:             control.attr('checked').toString() :

 19:             control.val();

 20:  

 21:         // if the condition is true, reuse the existing 

 22:         // required field validator functionality

 23:         if (targetvalue === actualvalue)

 24:             return $.validator.methods.required.call(

 25:               this, value, element, parameters);

 26:  

 27:         return true;

 28:     }

 29: );

You can see I’m just reusing the built in “required” validation if I determine it needs to be run.

However, we do also need to add an adapter that extracts the HTML 5 Custom Data Attributes that MVC adds to my input controls (use View Source and look for “data-XXX” on the <input> elements if you don’t know what these are – or read my article here) and passes them to my validation method. Mine looks like this;

 1: $.validator.unobtrusive.adapters.add(

 2:     'requiredif', 

 3:     ['dependentproperty', 'targetvalue'], 

 4:     function (options) {

 5:         options.rules['requiredif'] = {

 6:             dependentproperty: options.params['dependentproperty'],

 7:             targetvalue: options.params['targetvalue']

 8:         };

 9:         options.messages['requiredif'] = options.message;

 10:     });

This states that I require two parameters – dependentproperty and targetvalue. These are therefore passed in the options object for me. I must then do any processing on them that is required (none, in this case) and create an entry in options.rules with their processed values. I also need to ensure I put the error message into a dictionary indexed by the name of my validation rule. Phew! I’m sure that could be easier, couldn’t it? Perhaps I’ll write a little helper… there are helper functions for rules that only have a single parameter or need a boolean, but mine didn’t fit that pattern.

Enabling Validation

… is no longer required in the View, because it is enabled in Web.config instead, and is set to “true” by default! Excellent news!

Conclusion

Well, I hope that has been pleasantly brief. Download the code and have a play if you’re interested, and let me know how you get on. I think MVC 3 is a giant leap towards far better validation… and to celebrate that the sample uses Razor, of course!