>HTML 5

>So I started looking at some of the new things available with HTML 5 by going through the slideshow found at Html5Rocks.  There’s some pretty cool stuff coming.  I don’t think it is that far away.  But it is definitely not immediate.  To prove that, just go to the site with IE.  The main HTML5Rocks site works in IE but the slideshow doesn’t.

The slideshow should work fine in IE once IE9 comes out.  But why do we have to wait?  Mozilla and Google managed to update their browsers to start supporting HTML 5.  Why can’t Microsoft do the same?  Why must we wait for IE9 (and then for adoption of IE9) before we can start taking advantage of many of the features of HTML5?  Seems to me that a position like that just slows down adoption of these great capabilities which will make development easier.  Making it even more ironic is that word is already starting to get out about how to add support for HTML5 to ASP.NET MVC (http://www.deanhume.com/Home/BlogPost/asp-net-mvc-html5-toolkit/29).

But I digress; I meant for this post to be about the new capabilities coming, not about Microsoft taking so long to support them 🙂

So, here are my favorite features coming with HTML5:

• The new input types for date, time, email, color, number.  Yes, many of these aren’t yet supported.  And the richest support is only in Chrome.  But when these come, it will be nice.  It will make validation easier and it will make things more consistent across web sites.  At least, once everybody starts accommodating the new types.
• Easy, easy ways to add audio and video to your site with the new audio and video tags.  
• The new CSS selectors will make lot’s of things easier.  And no more jQuery to get different backgrounds on alternate table rows!
• The TextStroke, Opacity, Rounded Corners, shadows and Gradient support is fantastic. Especially the gradient support.  I always hated the “hack” of using a 1px wide image to get a gradient color in a background.
• I can see the local storage changing the game a lot.  Today, if I have a multi-page “wizard”, I have to send and save the data on the server between pages.  With this capability, I could store the data locally and send it once when the user has hit a Save button making my process use less bandwidth and be a bit more crash proof.

I see no reason not to start using these features today.  Modernizr is a javaScript library that lets you know what features are and aren’t available in the current browser.  It extends that knowledge into CSS as well.  For example, if you want to have one background style if gradients are supported and a different one if they are not, you can code:

.cssgradients { /* Gradients supported by browser */

}

.no-cssgradients { /* gradients not supported by browser*/

}

This does mean some extra work when creating your scripts and your styles.  But it also means that you can take advantage of these new features and gracefully degrade them as necessary.  So the question becomes is the extra effort worth it?

I think it is.  

>ASP.NET MVC Validations

>I was excited to see the announcement on Scott Gu’s blog about ASP.NET MVC v3.  And I was even more excited to see that they are greatly enhancing the validation processing.  Specifically, they’ve added a way to perform model level validations.  And with the way it looks like it wraps the validations so that you don’t have to create Controller methods specific for you validations, this could be a huge improvement over what was introduced in v2.

>ASP.NET MVC v2 Validations

>I’m working on a new (and simple) site in ASP.NET MVC v2 in v4 of the framework.  And I’ve been trying to figure out the best way to do validations using the new capabilities.  But after looking at everything, I’m thinking my old way is better.

In my previous MVC sites, I’ve put the validation logic in a service layer.  For client-side validation, I used the JQuery Validation Library.  This did require me to write the validation logic twice but, for the complex validations, I was able to reuse my service layer code because of the capabilities of the validation library.

I use view models in my UI.  Using the definitions from Simon Ince’s Blog, I use a combination of variant 2 (Container View Model) and variant 3 (View Model and Mappers).

To get the validation messages from the service layer to the UI layer, I used the IValidationDictionary and ModelStateWrapper approach talked about in the this ASP.NET MVC tutorial.

And this approach worked well for me.

Now I’m moving into MVC v2 and am looking at the new validation capabilities with the data annotations library.  I liked what I saw.  Not having to duplicate the validation code in both the client and server was going to save lot’s of time.

As I started looking at implementing it, I got my first concern.  All of the validations were being placed in the View Models, not on the domain models.  When I found samples with the validations placed on the domain models, the domain models were being used as the view models.  Sigh…

When I did some research, I discovered that the data annotation validations have MVC dependencies.  So using them in a service layer seems like a bad idea.  Another sigh…

But if I move away from the new validations framework and from using View Models with Mappers, that also makes it more difficult to use the templates because I’d lose the DisplayName attribute.  And I find that attribute and the templates incredibly handy, helpful and time saving.

So, for now I’m thinking I will be coding validations twice and they will execute three times; once on the client, once on the server in my UI and once on the server in my service layer.  Seems like a waste but I don’t see any other approach right now.

>ASP.NET MVC

>I’ve started creating my first ASP.NET MVC project and I have to say, I’m enjoying it quite a bit.  The ease with which you can work in testing and the power built in are pretty cool features.  And, having the jquery “built-in” is nice. 

I’d say my favorite features are:

1. Not having the page bloat you get with web forms and view state.
2. Not having the complications of adding fancy “ajaxy” features if you don’t want to use the overhead of update panels.
3. Not having to deal with the headaches of View State and Ajax is really nice.

I’m impressed how easy it was to pick up and how some of the features were implemented.  I really like the way that did the data binding to the models.  It’s easily customized but works well right-out of the box.  And, adding things like the MS AntiXSS library to help prevent cross site scripting attacks is sweet.  And since I’ve been doing a lot of CSS based design previously, formatting the pages is not any more of a challenge than it was with web forms.