Last week, I had the pleasure of presenting at DevConnections at the Mandalay Bay in Las Vegas, NV. I had a total blast interacting with attendees, fellow speakers and checking out the vendor hall. The logistics for the conference were remarkable given…
One of the new features of the Dependency Inject (DI) components from MVC3 is something called a IFilterProvider. The purpose of this component is to provide a simpler way for MVC applications to interact with filters (action, exception, result, etc….
I’ve been getting different questions via emails, DMs, IMs, etc. that can be summed up by this question:
Once MVC3 comes out, will I need MVC Turbine anymore to provide Dependency Injection (DI) support to ASP.NET MVC?
There is really no clear answer for this, so all I can say is, it depends 
For those of you that are not aware, MVC3 has added better support for using Dependency Injection (DI) within different parts of your application. This newly added support applies to:
These are the same features that MVC Turbine (Turbine) has offered since we first released V1 almost a year ago. However, in order to provide these and other features, the Turbine codebase has had to handle the plumbing necessary to wire up components in a way to provide first-class DI support. This means that a good chunk of the codebase is just there to ‘hook things up’ within the framework pipeline. After all, we can’t change the underlying framework so we have to make due with what’s available through the public API.
Since the new extension points that MVC3 exposes provide deeper integration to the framework (pipeline), we can now safely delete all the code that we’ve previously had to write; this is a very good thing. As the old saying goes, we can now stand on the shoulder of giants and focus on providing additional support for MVC applications.
The biggest value of add that Turbine gives applications is the “Blade” concept, which is essentially a way to provide an extensibility story to MVC applications. In essence you can build Blades that house cross-cutting support to your applications (i.e. Logging, Persistence Management, ESB Support, etc.) without re-inventing the wheel every time. You write once and use everywhere.
Now that the codebase has shrunk, the team can now focus on providing additional features around Blades as well as (to name a few):
Also, with the release of MVC3 it is only natural to increase the version number of Turbine to v3; after all Turbine could not exist without ASP.NET MVC.
I am very excited about the new features and opportunities that MVC3 will bring to ASP.NET stack. To me these features are beyond additions to the framework pipeline but more of an on ramp for creating applications quicker and better on top a great web stack.
Happy Coding!
Recently MVC Turbine has had a lot attention, so I wanted to take the time to say “Thank You!” to those of you that have help promote it, use it, provided feed or giving it a look.
In particular I wanted to say a HUGE THANKS to Hugo Bonacci (@hugoware) for donating his artistic talent and creating these awesome logos for the project. Thanks for putting up with my many draft changes and requests. The logos are awesome and I thank you for providing such a great asset to the project!
(horizontal banner)
(avatar/icon)
Also, I wanted to list out a set of links to blog posts by my self and fellow MVC Turbine member, Darren Cauthon. Darren has provided a lot of great feedback, code and samples which makes the project a lot better. Thank you Darren for your efforts!
Here are the links from Darren that showcase the extensibility that MVC Turbine provides to applications:
Also, here’s a list of some of the other extension projects that Darren is currently working on:
If you’re an audio learner instead of a visual one, then check out these podcasts in which, yours truly, talks about both ASP.NET MVC and MVC Turbine:
The plan of attack by the dev team is to provide better documentation as well as blog more about examples on ways to use Turbine to extend and power your applications (similar to what Darren is already doing). We want to make the portal site, http://turbineproject.com more than just a redirection to the CodePlex site. At the same time, we want to roll in bug fixes, fluent registration features and MEF support into v2.2, so check out the GitHub repository for these changes. Lastly, you can also download the MVC Turbine Project Templates for Visual Studio 2010 from the Visual Studio Gallery.
Again, I want to say thank you for taking the time to check out the project and for all the help all you have provided. If you’re interested in helping out, reach out to me either via this blog or start a comment thread out in the Google Group.
Happy Coding!
Last week, it was tweeted that MVC Turbine v2.1 had reached RTM.
The released bits can be downloaded from the main project site; the features it provides are (same as v2.0 RTM plus these):
The Visual Studio Templates have been upgraded for VS 2010 and MVC2 and released to the Visual Studio Gallery
After some user feedback, these changes have been made to the code within the template:
All the source is available out on Github for you to check out or fork! Also, if you have any questions or would like to contribute feedback to the project, check out the MVC Turbine Google Group.
If you have any questions, please leave a comment out on the Google Group!
Happy Coding!
First of, I would like to give a huge thanks to Phil Haack for his awesome blog post, Sending JSON to an ASP.NET MVC Action Method Argument, which shows how really flexible the ASP.NET MVC can be. Also, I owe him a beer next time I see him for saving my behind and providing an actual solution to my original POSTing JSON Data to MVC Controllers post.
Namaste, Phil!
In Phil’s post, he mentions that using a model binder falls short because of the lack of validation support:
There’s one key problem with using a model binder to accept JSON. By writing a custom model binder, you miss out on validation. Using his example, if you type “abc” for the
Agefield, you will get a serialization failure when attempting to serialize the JSON into thePersonInputModelobject because Age is anInt32and the serialization will fail.
He’s absolutely right and, as he mentions, you should use the JsonValueProviderFactory from the ASP.NET MVC 2 Futures library. Funny enough, as he was finishing up his blog post, I was working a simple JSON model binder to show how this is possible with what comes out of the box with MVC2. The source code for this sample is located here, http://github.com/jglozano/samples/tree/master/JSONModelBinder.
The interesting thing in both solutions, is that you do have to some work on the client side to take your javascript structures and convert them into JSON. Phil shows on his post how you can use a JSON plug-in for jQuery to accomplish this. If you read down in the comments, Dave Ward points out that we should be using Crockford’s json2.js to serialize (or stringify) your structure into valid JSON. Funny enough, while working on my sample I had bumped into this StackOverflow post that explains the reason to use Crockford’s script and quotes John Resig’s recommendation (add here for ease of read):
The second major feature of the language is the addition of native JSON support to the language.
I’ve been championing this move for a long time and I’m glad to see it finally arrive in a specification.
In the meantime PLEASE start migrating your JSON-using applications over to Crockford’s json2.js. It is fully compatible with the ECMAScript 5 specification and gracefully degrades if a native (faster!) implementation exists.
In fact, I just landed a change in jQuery yesterday that utilizes the
JSON.parsemethod if it exists, now that it has been completely specified.There are two primary methods for handling JSON:
JSON.parse(which converts a JSON string into a JavaScript object) andJSON.stringify(which convert a JavaScript object into a serialized string).
Once this piece is applied on the client side, there is still some work to be done server side. For this piece, let’s assume we do not know about IValueProvider and the JsonValueProviderFactory and let’s explore the creation of a model binder (since I already have the code 
) and some of the issues of taking this approach instead of using the ‘baked-in’ pieces that Phil described.
I took a short look at implementing a JSONModelBinder and this is what I came up with:
The code is pretty simple and to the point, except for the interaction with the JavaScriptSerializer piece, which unfortunately does all the heavy lifting for the system. If you’re using .NET 4, the JavaScriptSerializer class has a Deserialize(String, Type) that returns an object of the specified type. However, in .NET 3.5, this method is not available since it’s marked as internal and the only option you have for deserialization is the DeserializeObject(String) method.
If you were to use this method for the example JSON data (in our case, {“Name”:”John User”, “Age”:”29”}) you will get an object of type IDictionary<string,object> as a result. If you look at Jonathan Carter’s implementation, he leverages the DictionaryValueProvider within the JsonValueProviderFactory, which works great with the new model binding pieces since this type implements IValueProvider.
So, in order to get this piece to work with the type that’s specified via the ModelMetadata, I had to do some work with reflection and extension methods to expose the correct Deserialize method:
Unfortunately, not straight forward but it at the end accomplishes the sending of JSON data to a controller action:
Where do we go from here?Again, although this is functional, you will not get the desired results or leverage the full power of MVC2 new validation components. If you need to support this scenario, PLEASE USE the approach that Phil’s post outlines, it will save you headaches.
If you’re interested in looking at my code, it can be found here: http://github.com/jglozano/samples/tree/master/JSONModelBinder – also, you want to use this with .NET4, there are instructions within the model binder that tell you what to change in order to get things working correctly.
Happy Coding!
I’m sure that some (if not many) of you know this little approach for posting data from a JSON POST action (through jQuery) to an MSMVC Controller. If you don’t, keep reading otherwise go read something more important
While working on MSMVC sites, I (like many of you) find myself doing a lot of user interaction with AJAX (via jQuery) on the client. At times, I will need to post several pieces of related data to an action and then get a response back from the server. If you’re doing some clever routing to create a more RESTful resource, then this will not work for you since you’ll need to pass the information as dictated by your route. But if you have a controller action that takes a chunk of data, then this will work perfectly for you.
Again, the goal here is to keep things pretty simple and leverage as much as the runtime’s out of box wiring as possible.
Take the following form (design and html):
The whole purpose of this form is to take the data, do some simple data validation and then POST the data to the server for processing. This can be done in several ways, since we’re doing a POST action, we opt to use the jQuery.post() method. As the documentation states, this is nothing more than an explicit setting of the jQuery.ajax() API function which specifies POST as the action method.
One of the parameters that can be passed to the post API call is the actual data for the call. The type of this data parameter can be either a map (structure) or string since this will be passed as part of the request body. To get the most “bang for your buck” with this API, you’ll want to have the data parameter be a map (structure) and let the jQuery and MSMVC runtime do the heavy lifting for you. Let’s examine the data that’s request by our controller for the above form.
All we need for this request to be valid is a nothing more than a simple input model to hold the “person” information as well as an action to receive it:
As you can see, there’s nothing complicated about these pieces. Just a simple controller action that takes in an Input (View) Model and returns a JSON data structure back to the caller. The only thing that can be consider complicated about this action is the [HttpPost] restriction, since as we stated earlier, we’re doing a jQuery post API call.
One of the nicest features of MSMVC is the concept of a IModelBinder, which performs a lot of heavy lifting for you when you transfer complex objects via a request. Out of the box, the DefaultModelBinder will wire up primitive, (light) complex types and collections for you by pulling information from the request (request body, query string, form data, etc.) In other words, if you provide the right information for a request, the DefaultModelBinder will do the rest for you. Let’s go back and examine our jQuery POST code.
What we need to do here is simple,
The previous list can be accomplished by the following:
In the above sample, all the magic takes place with the aide of the “Person” structure that’s passed as a parameter to the POST call. If we examine the request body (with the aide of Firebug) we can see how the request is actually structured:
The outlined area show that the data within the request is passed as key-value pairs (application/x-www-form-urlencoded) to the server processing. Again, since MSMVC comes with the DefaultModelBinder, we get the mapping of the request data into our input (view) model for free:
From here, we can easily return JSON back to the client and allow it to do processing as it sees fit. In our case, we’ll just display the data to the user as a simple message:
Pretty straight forward and simple, huh? If you’re interested on the code, go here: http://github.com/jglozano/samples
Happy Coding!
Great minds think alike … or is it that fools seldom differ? I forget… In any note, all I can say that in this case it took three people’s work to make this possible in order to bring simplicity to the masses. Please note that this piece is a work in progress and we’re still trying to figure out how things will be at the end for these two frameworks to interact. Also, if you want more code, I suggest you check out the Fubu sample for MVC Turbine.
I’m not going to go over the details about FubuMVC, since people smarter than me have already have. All I can say is that if you’re doing MVC (the presentation pattern) style development in the .NET platform, you should definitely check out FubuMVC as well as OpenRasta and MonoRail and of course, MSMVC. These frameworks make your life easier as a web developer within the MS platform and it’s your right to explore them all to know what works for you. Ok, now to get off my soap box.
FubuMVC has tons of great features for developers to take full advantage of their web application and do a lot with very little effort. One of these features is called Html Conventions, as Jeremy describes them:
If your familiar with MvcContrib’s Opinionated Input Builders or MVC2’s Templates feature (very well described by Brad Wilson here), we’re doing the same thing conceptually but with much different mechanics. Right now, I’m focused on the very basic building block methods that appear on FubuMVC view’s (remember that we basically force all views in FubuMVC to be strongly typed with a single ViewModel):
- InputFor( expression ) – write an Html element to edit a single property on the ViewModel. Instead of calling TextboxFor(x => x.Something) or DropdownListFor(x => x.Other) we can just say InputFor(x => x.Some.Property.On.The.ViewModel) and let the conventions figure out what to do from there. If we need to change the model property to something else, or change our conventions about how elements should be constructed, no big deal.
- DisplayFor( expression ) – write an Html element to display the value of a single property value on the ViewModel. String fields are just displayed. Entity fields may be displayed as a link to more information on that link. Date fields are shown in short date format, etc.
- LabelFor( expression ) – write an Html “label” element for the field. Out of the box, FubuMVC will just put in the field name, but that’s not all that useful. In our Dovetail project we have this tied into our localization subsystem to pluck out a localized header text for the desired property.
Fubu (as well as MVC Contrib and MVC2) establishes a convention (or standard) for allowing the ViewModel to drive the intent of your application. One way they enforce this convention, is by having their own ViewPage (since they use the WebForm ViewEngine out of the box) to do some of the wiring and provide the underlying framework to make it all *just* work. The question here is, how do we get this to work on the MSMVC side? I mean, it’s just a ViewPage right??
For a while I’ve been thinking of these pieces could be leveraged within the MSMVC world in order to provide another option for developers (and perhaps intermix solutions). While talking with Wes McClure, he mentioned some of the work that he and Ryan Ohs have done around using FubuMVC’s Html Conventions within MS MVC. The clever approach to their solution is to leverage Html helpers to bind the worlds together. This yield the following markup within your views:
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server"> <h2>Product Details</h2> <p><%= Html.LabelFor(x => x.Id) %>: <%= Html.InputFor(x => x.Id) %> <%= Html.DisplayFor(x => x.Id) %></p> <p><%= Html.LabelFor(x => x.Name) %>: <%= Html.InputFor(x => x.Name) %> <%= Html.DisplayFor(x => x.Name) %></p> <p><%= Html.LabelFor(x => x.Created) %>: <%= Html.InputFor(x => x.Created)%> <%= Html.DisplayFor(x => x.Created)%></p> <p><%= Html.LabelFor(x => x.InStock) %>: <%= Html.InputFor(x => x.InStock)%> <%= Html.DisplayFor(x => x.InStock)%></p> </asp:Content>
Pretty cool, huh? Unfortunately, the following dark magic needs be housed within your web application in order to wire up all the pieces:
public class MvcApplication : HttpApplication { protected void Application_Start() { var container = new WindsorContainer(); LocalHtmlConventionRegistry.AddRegistrationsToContainer(container); // must be before HtmlTagsRegistry. HtmlTagsRegistry.AddRegistrationsToContainer(container); ServiceLocator.SetLocatorProvider(() => new WindsorServiceLocator(container)); container.Register(Component.For<IServiceLocator>().Instance(ServiceLocator.Current).LifeStyle.Singleton); } } public static class HtmlTagsRegistry { public static void AddRegistrationsToContainer(IWindsorContainer container) { container.Register(Component.For<IElementNamingConvention>().ImplementedBy<DefaultElementNamingConvention>()); container.Register(Component.For<Stringifier>().ImplementedBy<Stringifier>()); container.Register(Component.For(typeof(ITagGenerator<>)).ImplementedBy(typeof(TagGenerator<>))); container.Register(Component.For<TagProfileLibrary>().LifeStyle.Singleton); var library = container.Resolve<TagProfileLibrary>(); var conventions = container.Resolve<HtmlConventionRegistry>(); library.ImportRegistry(conventions); } }
By looking at the code, and the commitment a developer had to do in order to make sure everything wired up correctly, I knew there was a better way. A way to get things done without leaking all that plumbing into an application. This cried out for application composition, so I used MVC Turbine to do the dirty work for me.
One of the main aspects of MVC Turbine is the Blade concept which is powered by the underlying IoC container. With all the extra wiring that needs to take place for the FubuMVC and MSMVC worlds to interact, it made complete sense for this churn to find a home within a Blade, in particular an HtmlConventionBlade:
namespace FubuMvc.Blades.UI { using FubuMVC.UI; using FubuMVC.UI.Tags; using MvcTurbine; using MvcTurbine.Blades; using MvcTurbine.ComponentModel; public class HtmlConventionBlade : Blade, ISupportAutoRegistration { public void AddRegistrations(AutoRegistrationList registrationList) { // Tell the system to scan and auto-register all the HtmlConventionRegistry types registrationList.Add(Registration.Simple<HtmlConventionRegistry>()); } public override void Spin(IRotorContext context) { IServiceLocator locator = context.ServiceLocator; // Hydrate the library from the system. var library = locator.Resolve<TagProfileLibrary>(); // Get all the registered HTML conventions var conventions = locator.ResolveServices<HtmlConventionRegistry>(); // Register each convention foreach (HtmlConventionRegistry convention in conventions) { library.ImportRegistry(convention); } } } }
We still need to provide the underlying plumbing for Fubu to wire up. This can be done via a supporting IServiceRegistration implementation to handle all these pieces:
namespace FubuMvc.Blades.UI { using FubuMVC.UI; using FubuMVC.UI.Configuration; using FubuMVC.UI.Tags; using MvcTurbine.ComponentModel; public class SupportingServiceRegistration : IServiceRegistration { public void Register(IServiceLocator locator) { // Register the common Fubu UI pieces locator.Register<IElementNamingConvention, DefaultElementNamingConvention>(); locator.Register<Stringifier, Stringifier>(); locator.Register(typeof (ITagGenerator<>), typeof (TagGenerator<>)); // Wire up the proxy for MS CSL -> MVC Turbine CSL locator.Register<Microsoft.Practices.ServiceLocation.IServiceLocator, ServiceLocatorProxy>(); // Wire up an instance of the TagProfileLibrary for the system to use locator.Register(new TagProfileLibrary()); } } }
From here, you’re pretty much all set. All you need is to add an assembly reference to the FubuMvc.Blade and let the runtime do the rest for you. Once you have the assembly reference, you’re free to create your own HtmlConventionRegistry classes and get rolling quickly with other pieces of your application.
If you have the time, check out the source for the FubuMVC integration. If you view the solution, you’ll see the basic CommonConventions class:
namespace HtmlConventions { using System; using FubuMVC.UI; using FubuMVC.UI.Configuration; using FubuMVC.UI.Tags; using HtmlTags; public class CommonConventions : HtmlConventionRegistry { public CommonConventions() { Editors.Always.Attr("class", "test"); Editors.IfPropertyIs<DateTime>().Modify(tag => tag.AddClass("picker")); Editors.IfPropertyIs<bool>().BuildBy(req => new CheckboxTag(req.Value<bool>())); // Relax, this is just the default fall through action Editors.Always.BuildBy(TagActionExpression.BuildTextbox); Editors.Always.Modify(AddElementName); Displays.Always.BuildBy(req => new HtmlTag("span").Text(req.StringValue())); Labels.Always.BuildBy(req => new HtmlTag("span").Text(req.Accessor.Name)); } public static void AddElementName(ElementRequest request, HtmlTag tag) { if (tag.IsInputElement()) { tag.Attr("name", request.ElementId); } } } }
Which once it’s run, yields the following output:
Feel free to play with these bits and let me know what you think. For now,
Happy Coding!
Great minds think alike … or is it that fools seldom differ? I forget… In any note, all I can say that in this case it took three people’s work to make this possible in order to bring simplicity to the masses. Please note that this piece is a work in progress and we’re still trying to figure out how things will be at the end for these two frameworks to interact. Also, if you want more code, I suggest you check out the Fubu sample for MVC Turbine.
I’m not going to go over the details about FubuMVC, since people smarter than me have already have. All I can say is that if you’re doing MVC (the presentation pattern) style development in the .NET platform, you should definitely check out FubuMVC as well as OpenRasta and MonoRail and of course, MSMVC. These frameworks make your life easier as a web developer within the MS platform and it’s your right to explore them all to know what works for you. Ok, now to get off my soap box.
FubuMVC has tons of great features for developers to take full advantage of their web application and do a lot with very little effort. One of these features is called Html Conventions, as Jeremy describes them:
If your familiar with MvcContrib’s Opinionated Input Builders or MVC2’s Templates feature (very well described by Brad Wilson here), we’re doing the same thing conceptually but with much different mechanics. Right now, I’m focused on the very basic building block methods that appear on FubuMVC view’s (remember that we basically force all views in FubuMVC to be strongly typed with a single ViewModel):
- InputFor( expression ) – write an Html element to edit a single property on the ViewModel. Instead of calling TextboxFor(x => x.Something) or DropdownListFor(x => x.Other) we can just say InputFor(x => x.Some.Property.On.The.ViewModel) and let the conventions figure out what to do from there. If we need to change the model property to something else, or change our conventions about how elements should be constructed, no big deal.
- DisplayFor( expression ) – write an Html element to display the value of a single property value on the ViewModel. String fields are just displayed. Entity fields may be displayed as a link to more information on that link. Date fields are shown in short date format, etc.
- LabelFor( expression ) – write an Html “label” element for the field. Out of the box, FubuMVC will just put in the field name, but that’s not all that useful. In our Dovetail project we have this tied into our localization subsystem to pluck out a localized header text for the desired property.
Fubu (as well as MVC Contrib and MVC2) establishes a convention (or standard) for allowing the ViewModel to drive the intent of your application. One way they enforce this convention, is by having their own ViewPage (since they use the WebForm ViewEngine out of the box) to do some of the wiring and provide the underlying framework to make it all *just* work. The question here is, how do we get this to work on the MSMVC side? I mean, it’s just a ViewPage right??
For a while I’ve been thinking of these pieces could be leveraged within the MSMVC world in order to provide another option for developers (and perhaps intermix solutions). While talking with Wes McClure, he mentioned some of the work that he and Ryan Ohs have done around using FubuMVC’s Html Conventions within MS MVC. The clever approach to their solution is to leverage Html helpers to bind the worlds together. This yield the following markup within your views:
Pretty cool, huh? Unfortunately, the following dark magic needs be housed within your web application in order to wire up all the pieces:
By looking at the code, and the commitment a developer had to do in order to make sure everything wired up correctly, I knew there was a better way. A way to get things done without leaking all that plumbing into an application. This cried out for application composition, so I used MVC Turbine to do the dirty work for me.
One of the main aspects of MVC Turbine is the Blade concept which is powered by the underlying IoC container. With all the extra wiring that needs to take place for the FubuMVC and MSMVC worlds to interact, it made complete sense for this churn to find a home within a Blade, in particular an HtmlConventionBlade:
We still need to provide the underlying plumbing for Fubu to wire up. This can be done via a supporting IServiceRegistration implementation to handle all these pieces:
From here, you’re pretty much all set. All you need is to add an assembly reference to the FubuMvc.Blade and let the runtime do the rest for you. Once you have the assembly reference, you’re free to create your own HtmlConventionRegistry classes and get rolling quickly with other pieces of your application.
If you have the time, check out the source for the FubuMVC integration. If you view the solution, you’ll see the basic CommonConventions class:
Which once it’s run, yields the following output:
Feel free to play with these bits and let me know what you think. For now,
Happy Coding!
The MVC Turbine bits are now compiled against ASP.NET MVC 2 RC2 which runs on .NET 3.5 SP1 and Visual Studio 2008. You can get the bits by going to the CodePlex site.
Please note that this the same feature release as MVC Turbine v2.0 RTM. The following is compiled and upgraded to work with .NET3.5 in VS2008:
Again, as I mentioned before, the main development will take place onVS2010 and MVC2 as I get things setup for v3 sometime first quarter of 2010.
Happy Coding!