In this blog post I’ll show you how to install and use my end-result of this proof of concept. In a follow-up, I’ll create a sample application with it. This first version is really just that: a proof of concept, just showing that it works. For example, this version includes a simple valueprovider for binding sitecore items to a model, but this is far from optimal. When creating a sample application, I’ll also be digging into modelbinding and other issues that’ll show up when creating an application. Perhaps I’ll conclude that its better to use something like CustomItem generator or the glass project and wrap one of those in a modelbinder, we’ll see (shoot your opinion about that in the comments!). I also only tested this on Sitecore 6.4, so it’ll probably only work on that version and up.

Now, let’s go to the code! To get started, open an existing Sitecore project (or create a new one) in Visual Studio. Now add the NuGet package BoC.Sitecore.MvcApp either through the package manager console or through tools->library package manager->Manage NuGet Packages for Solution…

The Sitecore Mvc starter app is the version I’ll use for this blog-post: it will add a basic mvc project to your solution to get started with. The other one (BoC.Sitecore.Mvc) will just add the dll + a config file to your current project, use this one if you want to set up your own Mvc project without any starting point.

Once you’ve installed the package, a new project named ‘yourproject’.mvcapp is added to your solution:

This is an empty ASP.NET MVC3 Razor project, with some stuff removed. The default web.config is removed, since we’ll have to use a modified version of Sitecore’s web.config and the account-stuff has been removed. As you can see, a default HomeController has been added, a default view and a default model (ItemView). Now, to see if BoC.Sitecore.Mvc works, let’s build the solution and open up the sitecore shell. Once logged in to your Sitecore shell, expand the tree items /sitecore/Layout and /sitecore/Layout/Layouts. You’ll see that underneath both, a new folder is added named ‘MVC Actions’. It’s in two places since you can use your MVC Actions both as Layout or as a rendering, more on that later.

Let’s see what the action and view for Home/Index looks like, so we can now what to expect to see when we try to load them in sitecore. The action itself looks very simple:

It expects an item of type ItemView and just passes that on to the view. As mentioned earlier, I added a simple valueprovider that will try to resolve any parameter named “item” with field-values from the current sitecore item (the current sitecore item by default is the context.item, unless you provided a datasource for the rendering). The model by default only includes the property DisplayName of the type RenderingString:

RenderingString is a special type added by BoC.Sitecore.Mvc : it will call RenderField when outputted in html so you can use the page editor. You could also change this to ‘public string DisplayName {get; set; }’ to have it filled with the normal string value. Since DisplayName is not editable in the page editor, and thus we cannot see the difference between RenderingString and normal String, let’s change this property to Title like so:

In our case we’ll use the ‘Sample Item’ template from the default setup, which has a Title field. If your item does not have a Title field, you’ll have to pick some other field name of course.

Now, open up the view in Views/Home/Index.cshtml:

The view still uses DisplayName, so we have to change that as well:

When the view will be fully rendered (thus not through a RenderChildAction), the view uses the ‘masterpage’ Views/Shared/_Layout.cshtml:

As you can see there is a special HtmlHelper extension used here: @Html.RenderPlaceholder(“main”) which is the equivalent of <sc:placeholder Key=”main” runat=”server” /> for the aspx version.

Now, compile your changes, and go back to the sitecore shell. Underneath the Homepage, add a new Sample Item template called ‘My new sample item’ and click the ‘Layout Details’ button in the ‘Presentation’ Ribbon.  In the dialog that opens, click on ‘edit’.

In the next dialog, click on the layout to pick the MVC Actions / Home / Index layout

Now, save all modifications by click ‘OK’ twice.

Now in the ribbon presentation, click on the ‘preview’ button to see our new page.

And there it is! Our MVC rendered sitecore item. The page still holds all the other renderings from the original Sample Item template including the nested Sample Sublayout.ascx the Sample Inner Sublayout.ascx and the sample rendering.xslt. So now we have an MVC rendered razor layout, holding asp.net usercontrols with an xslt rendering! You can mix-and-match those all together, how cool is that!

The item’s title is displayed twice, since our ‘Layout’ renders the title also, remember (the Home/Index.cshtml ouputs the title, and we’ve picked that as our Layout for the sitecore item). To see that the page editor also still works (even for the razor code), click on the ‘page editor’ button in the ‘Publish’ ribbon.

Modify the fields, add some extra renderings, it all still works. To show off an extra mix-and-match, now let’s also add our action as rendering to the existing asp.net based homepage.

Click on the homepage-treeitem and click on the ‘Layout details’ button on the ‘Presentation’ ribbon. In the popup dialog, click on ‘edit’ and then, in the next popup dialog, click on controls.

Now, click the add button. In the next popup dialog, select MVCActions/Home/Index and add it to placeholder ‘/main/centercolumn/content’

Click on select, and then twice on OK to save this new addition. Now, on our preview pane, we see an extra Title appear!

This is our Views/Home/Index.cshtml ! Since the action is now added to the page as a rendering instead of being used as a layout, the /Views/Shared/_Layout.cshtml is not used. This is because this action is now being rendered by calling MVC’s RenderChildAction. Child actions never have a layout.

Now just go ahead and do some mixing of different options for yourself, you could try a different viewengine (aspx, spark viewengine) for example, works just fine. A little extra nice-to-know is that you can add a DescriptionAttribute to your controllers and/or actions to have them show up differently in sitecore. ({0} is thereby replaced with the original name).

I hope you’ll all enjoy playing with MVC within Sitecore and get some great ideas about it while you’re at it. Please leave all your great ideas and suggestions in the comments.

If you want to checkout the source, you can find that at github: http://github.com/csteeg/BoC.Sitecore.MVC

To generate the c# code for the views, I just started out with David Ebbo’s single file generator and modified it to generate views instead of helpers only. To do this, there had to be a WebRazorHostFactory that knew about all the mvc stuff (what dll’s to reference, what namespaces to use, etc) .I could either choose to include all that information statically in the code, or I could look for a web.config in the same project and let the WebRazorHostFactory use that config. I chose the latter option, so that everyone can easily change the WebRazorHostFactory behavior  by adding a web.config file to their project.

Next, I started figuring out how the PageVirtualPathAttribute inside System.Web.Webpages.dll is used by Microsoft. I found out that it is used when you call ApplicationPart.Register and after that call, there’s not much you can use of this functionality without some heavy reflection. I know it’s the wrong path to choose, but did it anyway. I ended up creating a ViewEngine calling into ApplicationPart’s internal methods to output compiled views. It worked, but I didn’t like it much: there had to be a better way.

I then tried if I could hook into the BuildManager stuff that asp.net mvc uses to generate the views. It was actually much easier then expected, now why didn’t I go on that path the first time!

I ended up creating

• a CompiledRazorBuildProvider, which inherits from the default RazorBuildProvider,
• a CompiledVirtualPathProvider which returns a CompiledVirtualFile if it decides that a compiled view should be used
• and a ApplicationPartRegistry, which registers which compiled views are available.

To view the source, head over to

• https://github.com/csteeg/BoC/tree/master/Src/Commons.Web.PrecompiledViews/ – for the classes mentioned
• https://github.com/csteeg/BoC/tree/master/Src/RazorSingleFileGenerator/ – for David Ebbo’s modfied file generator

To just get started without viewing the source, read on, I will explain step by step how to use this library with some screenshots.

If you have improvements, fork the project on GitHub and let me know! If you have suggestions for improvement, just drop it in the comments.

Step 1: Install the FileGenerator

Download and install the Visual Studio extension: http://visualstudiogallery.msdn.microsoft.com/en-us/f28290ce-d987-4f91-b034-707031e10ce6/file/39295/0/RazorSingleFileGenerator.vsix

Step 2: Create new mvc project

Step 3: Add a class library to hold the views

Step 4: Cut your Models & Views folders

Step 5: Paste them into the just created Class Library

Step 6: Copy the website’s web.config file

Step 7: Paste that web.config file into the class library

Step 8: Select all your .cshtml files in the class library and set the Custom Tool to ‘MvcRazorClassGenerator’

Does anyone have a suggestion on improving this step??

Step 9: Build your class library

Step 10: Add your class library to the references of the web application

Step 11: Add ‘Commons.web.mvc.precompiledviews.dll’ as a reference to your website

this dll is copied to the class library’s output folder (in this case ../EmbeddedViews/bin/debug’)

Step 12: Register your views by adding a line to the application_start in global.asax.cs

Step 13: Run your website!

Now, you will see the normal default website, even though there aren’t any views in your website path!

If you wish to override some views, just create the normal folders (eg /Views/Home) and add your views there, but don’t forget to copy back the deleted /Views/web.config back into your project then!

HappyBirthday is an app for the Vodafone 360 platform and helps you to never forget a birthday again.
You can read more about the app at the details page of HappyBirthday!

The Vodafone 360 platform is a new internet service for your mobile, PC and Mac. It brings your phone, email, chat and social network contacts together in one placeand runs on many many phones. You don’t need to have a vodafone account to join 360, anyone can join at http://360.com.

For this project the following (extensive) list of libraries is used (all these libraries are included in the download):

• MS ASP.NET Mvc 1.0
• Microsoft .NET RIA Services July 2009 Preview
• NHibernate 2.1.0CR1
• NHibernate Linq (latest trunk version)
• FluentNhibernate (latest trunk version, patched to work with NHibernate 2.1.0CR1)
• MS Unity 1.2
• ASP.NET Dynamic Data MVC Preview (since this project is pretty old, I had to modify it quite a bit, the source is included in the download)
• I used Rob Conery’s t4 templates as the base to generate entities from the database.

Besides using these libraries, I copied some code snippits from the Kigg project, which has quite a nice codebase!

In the first part of this serie, I’ll show you how you can use these libraries along with my own code to scaffold the entire Northwind database in an mvc project. It’ll be totally hassle-free, I promise! It will generate classes from the database-schema and I will also show you how to override the default generated domainservices and repositories (yes, those are generated at runtime if you don’t specify your own!).

In the upcoming parts, I will add client-side validation and some ajax-love to the scaffold pages. In one of those parts I’ll also explain how my code works, and what it does. I’m also thinking about showing how to replace some parts of the library, since it’s very pluggable. I could for example replace the persistencelayer with Linq-to-Sql or replace the Depency part with StructureMap.

Although this sample shows you how to use an existing database, it would ofcourse be best if you could use the Model-first approach! Luckely nHibernate makes this very simple as well. If you create the entity files in your project and have them inherited from BaseEntity, all you have to do is add this line to your Application_Start:

new SchemaUpdate(IoC.Resolve<Configuration>).Execute(true, true);

Your database schema will be automatically updated if you change anything to your Model.

You can watch the screencast here and download the sample + dll’s here

For the next screencast, I’ll by a mic so I don’t have to subtitle it

The first thing that bothered me was the fact that Unity throws an exception when Resolve<T> is not able to resolve the given type: I’d prefer it to return null instead, hence most containers do that. The second, even more irritating point, was that ResolveAll<T> only returned the named instances/types instead of all registered types. In fact, Unity overwrites the default registration if your register a type multiple times. Eg:

Container.Register<IMyInterFace, MyClass1>();
Container.Register<IMyInterFace, MyClass2>();

would cause the MyClass1 registration to be removed. I’d like the MyClass1 to remain the default registration, and have ResolveAll<IMyInterface>() return both. I’m happy to tell you that it can be done!

When using an IoC container, it’s good practice to access it’s features through a generic wrapper class. For my projects, I use the wrapper from the Kigg source code. If you access the container through a wrapper after you configured your container, it’ll be easy to replace it with a different container in the future.

My wrapper class looks like this:

public class UnityDependencyResolver : IDependencyResolver
{
    private readonly IUnityContainer container;

    public UnityDependencyResolver() : this(new UnityContainer())
    {
        var configuration = (UnityConfigurationSection) ConfigurationManager.GetSection("unity");
        if (configuration != null)
            configuration.Containers.Default.Configure(container);
    }

    public UnityDependencyResolver(IUnityContainer container)
    {
        Check.Argument.IsNotNull(container, "container");

        this.container = container;
        this.container.AddExtension(new TypeTrackingExtension());
        this.container.RegisterInstance<IUnityContainer>(container);
        this.container.RegisterInstance<IDependencyResolver>(this);
    }

    public IUnityContainer Container { get { return container; } }

    public void RegisterInstance<T>(T instance)
    {
        Check.Argument.IsNotNull(instance, "instance");

        container.RegisterInstance(instance);
    }

    public void RegisterType<TFrom, TTo>() where TTo : TFrom
    {
        container.RegisterType<TFrom, TTo>();
    }

    public void RegisterType(Type from, Type to)
    {
        Check.Argument.IsNotNull(from, "from");
        Check.Argument.IsNotNull(to, "to");

        container.RegisterType(from, to);
    }

    public void Inject<T>(T existing)
    {
        Check.Argument.IsNotNull(existing, "existing");

        container.BuildUp(existing);
    }

    public object Resolve(Type type)
    {
        Check.Argument.IsNotNull(type, "type");
        if (container.Configure<TypeTrackingExtension>().CanResolve(type))
        {
            return container.Resolve(type);
        }
        else
        {
            return null;
        }
    }

    public object Resolve(Type type, string name)
    {
        Check.Argument.IsNotNull(type, "type");
        if (Container.Configure<TypeTrackingExtension>().CanResolve(type, name))
        {
            return container.Resolve(type, name);
        }
        else
        {
            return null;
        }
    }

    public T Resolve<T>()
    {
        return (T) Resolve(typeof(T));
    }

    public T Resolve<T>(string name)
    {
        Check.Argument.IsNotEmpty(name, "name");
        return (T) Resolve(typeof(T), name);
    }

    public IEnumerable<T> ResolveAll<T>()
    {
        var namedInstances = container.ResolveAll<T>();
        var unnamedInstance = default(T);

        try
        {
            unnamedInstance = container.Resolve<T>();
        }
        catch (ResolutionFailedException)
        {
            //When default instance is missing
        }

        if (Equals(unnamedInstance, default(T)))
        {
            return namedInstances;
        }

        return new ReadOnlyCollection<T>(new List<T>(namedInstances) { unnamedInstance });
    }

    ~UnityDependencyResolver()
    {
        Dispose(false);
    }
    public void Dispose()
    {
        Dispose(true);
    }
    protected void Dispose(bool disposing)
    {
        if (disposing)
        {
            container.Dispose();
        }
    }
}

Though most methods are just direct wrappers for accessing the container itself, there are a few extra’s. For one, there’s the ResolveAll<T> method that returns both named and unnamed instances instead of only the named instances, that’s one problem fixed.

Secondly, you can see the Resolve methods use

if (Container.Configure<TypeTrackingExtension>().CanResolve(type, name))

It uses an UnityExtension to see if the Type can be resolved and it returns null if it can’t. This solution was provided by David Buksbaum in his blog post Type Tracking Extension for Unity. This extension is added to the container in this wrapper’s constructor.

I did modify David’s extension a little, to have it not overwrite the first registered type and to have CanResolve return true for types that can be initiated also (the original only returns true for types that have been registered). My version looks like this:

public class TypeTrackingExtension : UnityContainerExtension
{
    private readonly Dictionary<Type, HashSet<string>> registeredTypes = new Dictionary<Type, HashSet<string>>();

    protected override void Initialize()
    {
        Context.Container.Configure<UnityDefaultBehaviorExtension>().Remove();
        Context.Container.Configure<InjectedMembers>().Remove();
        //we have to be the first in the chain
        Context.RegisteringInstance += OnNewInstance;
        Context.Registering += OnNewType;

        Context.Container.Configure<UnityDefaultBehaviorExtension>().InitializeExtension(Context);
        Context.Container.Configure<InjectedMembers>().InitializeExtension(Context);
    }

    public override void Remove()
    {
        base.Remove();
        Context.RegisteringInstance -= OnNewInstance;
        Context.Registering -= OnNewType;
    }
    private void OnNewInstance(object sender, RegisterInstanceEventArgs e)
    {
        HashSet<string> names;
        string name = string.IsNullOrEmpty(e.Name) ? string.Empty : e.Name;

        if (!registeredTypes.TryGetValue(e.RegisteredType, out names))
        { //  not found, so add it
            registeredTypes.Add(e.RegisteredType, new HashSet<string> { name });
        }
        else
        { //  already added type, so add name
            if (name == String.Empty && names.Contains(name))
            {
                //default instance is already registered, let's give it a name so we can use ResolveAll() like it works in all other ioc containers
                name = e.Name = Guid.NewGuid().ToString();
            }
            names.Add(name);
        }
    }
    private void OnNewType(object sender, RegisterEventArgs e)
    {
        HashSet<string> names;
        string name = string.IsNullOrEmpty(e.Name) ? string.Empty : e.Name;
        if (!registeredTypes.TryGetValue(e.TypeFrom, out names))
        { //  not found, so add it
            registeredTypes.Add(e.TypeFrom, new HashSet<string> { name });
        }
        else
        { //  already added type, so add name
            if (name == String.Empty && names.Contains(name))
            {
                //default instance is already registered, let's give it a name so we can use ResolveAll() like it works in all other ioc containers
                name = e.Name = Guid.NewGuid().ToString();
            }
            names.Add(name);
        }
    }

    /// <summary>
    /// Determines whether this type can be resolved as the default.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <returns>
    /// 	<c>true</c> if this instance can resolve; otherwise, <c>false</c>.
    /// </returns>
    public bool CanResolve<T>()
    {
        return CanResolve(typeof(T), null);
    }
    /// <summary>
    /// Determines whether this type can be resolved as the default.
    /// </summary>
    /// <param name="type">The type.</param>
    /// <returns>
    /// 	<c>true</c> if this instance can resolve; otherwise, <c>false</c>.
    /// </returns>
    public bool CanResolve(Type type)
    {
        return CanResolve(type, null);
    }
    /// <summary>
    /// Determines whether this type can be resolved with the specified name.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="name">The name.</param>
    /// <returns>
    /// 	<c>true</c> if this instance can be resolved with the specified name; otherwise, <c>false</c>.
    /// </returns>
    public bool CanResolve<T>(string name)
    {
        return CanResolve(typeof (T), name);
    }

    /// <summary>
    /// Determines whether this type can be resolved with the specified name.
    /// </summary>
    /// <param name="type">The type.</param>
    /// <param name="name">The name.</param>
    /// <returns>
    /// 	<c>true</c> if this instance can be resolved with the specified name; otherwise, <c>false</c>.
    /// </returns>
    public bool CanResolve(Type type, string name)
    {
        if (isResolvableClass(type))
            return true;

        HashSet<string> names;
        if (registeredTypes.TryGetValue(type, out names))
        {
            return names.Contains(name ?? string.Empty);
        }
        return false;
    }

    private bool isResolvableClass(Type type)
    {
        return type.IsClass && !type.IsAbstract;
    }
    /// <summary>
    /// Determines whether this instance can be resolved at all.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <returns>
    /// 	<c>true</c> if this instance can be resolved at all; otherwise, <c>false</c>.
    /// </returns>
    public bool CanResolveAny<T>()
    {
        return CanResolveAny(typeof(T));
    }

    /// <summary>
    /// Determines whether this instance can be resolved at all.
    /// </summary>
    /// <param name="type">The type.</param>
    /// <returns>
    /// 	<c>true</c> if this instance can be resolved at all; otherwise, <c>false</c>.
    /// </returns>
    public bool CanResolveAny(Type type)
    {
        return isResolvableClass(type) || registeredTypes.ContainsKey(type);
    }

    /// <summary>
    /// Tries to resolve the type, returning null if not found.
    /// </summary>
    /// <typeparam name="T">The type to try and resolve.</typeparam>
    /// <returns>An object of type <see cref="T"/> if found, or <c>null</c> if not.</returns>
    public T TryResolve<T>()
    {
        return TryResolve<T>(default(T));
    }
    /// <summary>
    /// Tries to resolve the type with the specified of name, returning null if not found.
    /// </summary>
    /// <typeparam name="T">The type to try and resolve.</typeparam>
    /// <param name="name">The name associated with the type.</param>
    /// <returns>An object of type <see cref="T"/> if found, or <c>null</c> if not.</returns>
    public T TryResolve<T>(string name)
    {
        return TryResolve<T>(name, default(T));
    }
    /// <summary>
    /// Tries to resolve the type, returning null if not found.
    /// </summary>
    /// <typeparam name="T">The type to try and resolve.</typeparam>
    /// <param name="defaultValue">The default value to return if type not found.</param>
    /// <returns>An object of type <see cref="T"/> if found, or the <see cref="defaultValue"/> if not.</returns>
    public T TryResolve<T>(T defaultValue)
    {
        if (!CanResolve<T>())
            return defaultValue;
        return Container.Resolve<T>();
    }
    /// <summary>
    /// Tries to resolve the type with the specified of name, returning null if not found.
    /// </summary>
    /// <typeparam name="T">The type to try and resolve.</typeparam>
    /// <param name="name">The name associated with the type.</param>
    /// <param name="defaultValue">The default value to return if type not found.</param>
    /// <returns>An object of type <see cref="T"/> if found, or the <see cref="defaultValue"/> if not.</returns>
    public T TryResolve<T>(string name, T defaultValue)
    {
        if (!CanResolve<T>(name))
            return defaultValue;
        return Container.Resolve<T>(name);
    }
}

As you can see, I change the order of the event chain, by removing UnityDefaultBehaviorExtension from the Container, and then add it again later. This allows us to add a name to the type being registered. If a type is registered multiple times without a name given, a name is given in the form of a unique Guid

So now, if you do

Container.Register<IMyInterFace, MyClass1>();
Container.Register<IMyInterFace, MyClass2>();

var wrapper = new UnityDependencyResolver(Container);
var classes = wrapper.ResolveAll<IMyInterFace>()

classes will contain both MyClass1 and MyClass2!

Let’s say you have a 2 simple classes like this:

Now, in the global.asax’s init (assuming a web application), we can configure NHibernate using Fluent NHibernate like this:

It uses convention over configuration in lots of places, eg the Id property is always used as identity-column if a property with that name exists.
But you could also easily add your own conventions. If you want to have the Id colums to be ArtistId and AlbumId (and any other className + Id), you’d do:

Want to restrict the namespace as well? No problem!

Fantastic! Now, to see what mapping file this code automagically creates for our Artist class, we can run the following code:

which returns an XmlDocument. In this case, the InnerXml of that document looks like this:

Again: fantastic! See how it even generates the one-to-many relation with the correct end-class, because we defined a property IList<Album>!

Running the same code for the Album class gives:

If you want to use Fluent NHibernate the ‘old’ way, you can still add ClassMap<Artist> to your assembly. Hence, you can even mix it with the AutoPersistenceModel! If you have a classmap file, it’ll use that for your class, if it isn’t there it’ll automatically create a mapping for you!

I’m sold! This makes using NHibernate a breeze. You can get up and running with your NHibernate project so much faster now.

The javascript-only package includes 3 javascript files that allow you to use the default Microsoft AjaxHelper. You can just copy those files to your Content folder and include them in your head section, instead of the MicrosoftAjax.js and MicrosoftMvcAjax.js. All ajax extensions work the same as their Microsoft equivalence,  using jQuery instead of MicrosoftAjax. As a little bonus, you’ll get back and forward button support for your ajax-links.

That’s it, go ahead and use the AjaxHelper functions like you’re used to. Though a few things have changed for the AjaxHelpers in preview 5, you could still use the introduction ASP.NET MVC Preview 4 – Using Ajax and Ajax.Form by Scott Hanselman if you haven’t already checked out the AjaxHelper. Main thing that has changed is that you cannot use inline javascript in the AjaxOptions in preview 5, you should now specify a method name. You could also download the entire jQueryMvc project, it holds a sample website showing some of the ajax magic.

Talking about the entire project, it’s more than just the .js files! The intention of the project is to get you up and running very quickly when you want to create an mvc based ajax application. We use Unity as our default IoC container.

I think it’s quite hard to explain exactly what the project does for you, it’s best really to just look at the sample website, but I will give a brief overview. First, we have a DefaultViewViewEngine. If you mark your controller with a [DefaultView] attribute like so:

If you call in example /Home/Index, by default the Index view will be searched for. If it isn’t found, the DefaultViewViewEngine will look for a template with the name specified ("default" in the above example). It doesn’t matter what viewengine you use for your views, it will work for all of them. So what can this do? Look at the structure of the views in the sample site:

As you can see, most of the the views only have an ascx file prefixed with an underscore. Since the views are not found when the actions Home/About, Home/SayHello, Home/Index are called upon, the DefaultViewViewEngine will open Shared/Default.aspx.
This default page does not do much

As you can see, it just uses the masterpage. But with only little imagination, you can see that you can easily create different default-pages for each controller. The masterpage however, does hold some extra magic:

This special contentplaceholder, by default works like a normal placeholder. But, if it doesn’t get new content from it’s page, it will ask the ViewEngine(s) to open the view of the current action prefixed with an underscore. So, if you call Home/About, this will ask for Home/_About. 
Can you see the magic? For all similar pages, you just have to create the ascx files (or other partials if you use a different viewengine). Those partial views will be pushed into the main page.

But wait, there’s more! If you make an ajax-request to a controller that has the [AjaxController] attribute, it will return only the partial view! Now, isn’t that great ? That looks a lot like the updatepanel to me

Go to codeplex and download the project to see the ajax-magic I’m so excited about!
Source can be downloaded at Google code: http://code.google.com/p/jquerymvc/source/checkout
The sample website can be seen in action at: http://www.chrisvandesteeg.nl/demo/jquerymvc5/

Unfortunately the AjaxHelper itself is sealed, so atm we can’t (easily) change how the AjaxHelper generates its links. So, as an alternative, I created a javascript library that uses the same methodnames as the MicrosoftMvcAjax version.

Though at first I was upset that AjaxHelper wasn’t opened up, this javascript-only solution makes it very easy to use. All you have to do is

• place the latest jQuery version in your Content folder;
• place my javascript file in your Content folder;
• add references in your views (or masterpage ofcourse) to these 2 files instead of referencing the MicrosoftMvcAjax.js and MicrosoftAjax.js file.

If you haven’t played with the AjaxHelper yet, take a look at Scott Hanselman’s post on Using Ajax and Ajax.Form

This jQuery version also has a little extra: browser-history support for your ajax requests

Now, go download the js file and play!

So, quite some things have changed in preview 3, which made me decide to change a lot in the jQuery for Asp.net mvc (jqmvc) too. To start with most radical one: I ditched the ajax.master. This little ‘framework’ does not rely on a special masterpage in your website from now on. Since things have radically changed, I’ll start all over again on how to use this project.

In this post, I’ll explain how the project works globally. I won’t go into too much details about everything, but I will just explain the things you’ll directly touch in your application. In the next post, I’ll explain how to use the project in your website (until that time you could take a look at the included sample website). That post will explain the Ajax- and HtmlHelpers in this project and it will explain how to do an ajax request using jQuery.

Before my story starts, let’s start with the links and downloads for all those who want to read code rather than stories :

• Downloads 
• SVN source Repository
• The online demo
• Codeplex homepage

Application and routes

To have a quick go for your application, it’s recommended that you inherit your application from JqueryMvc.JqueryMvcApplication. You can ofcourse easily do this in your global.asax like so:

This application sets up the Unity dependency container and will set up the default routes. If you wish to setup a different (or no) dependency container, you should override InitializeContainer() and ConfigureContainer(). JQueryMvc itself is no longer dependent on a dependency container.

I found it hard to set up the default routes in preview 3 if your server does not support wildcard redirects (like visual studio’s webdevserver doesn’t). In that case you need to catch existing files (default.aspx needs to exist, but shouldn’t do anything), but you need to skip the Content folder. I came up with the following solution:

So if there’s a default.aspx in the root of your application, it set’s routeExistingFiles to true. If the url matches the RegEx ^Content\/.* the routing will be stopped using the new IgnoreRoute method. Also, your controllers will then be extended with .aspx to be sure the requests passes the asp.net cycle. If you have the option to catch all incoming requests, all you have to do is remove the default.aspx from the root of your website.

Controllers

As you’ve seen in Scott’s post, controllers should now return an ActionResult. The normal way would be to have your controller action return the result of the View() method. With jqmvc you should not call the View() method at the end of your action. Ofcourse, if you’re sure you want to return the normal view, you could still do so. In jqmvc there is a ExtController which you should inherit your controllers from. This baseclass contains a method called Action() which accepts the same attributes as View() but does some magic to decide what type of request the current request is, and will try to return the correct ActionResult for that type of request. This could be either an Ajax-request, a Json request or a normal page-request. Your typical controller with some actions would look like this:

Views

If jqmvc encountered the current request as a normal page request, it will create the default ViewResult, nothing special there.

If jqmvc decided Json should be returned, a JsonResult is created and no further actions will be taken. The rendered view will be the ViewData serialized to Json. The ViewEngine of the controller is also changed to a JsonViewEngine but this is only called upon in case of an Exception.

If jqmvc decided that the request is an Ajax request, it will create a normal ViewResult, but it will change the ViewLocator of the controller.
(Offtopic: I think it’s a design-error to have the viewlocator on the controller. It should be on the ViewResult object, that’s the only object that uses it. Perhaps this will be changed in the next preview…)
This AjaxViewLocator will first look for .ascx files instead of .aspx files. If it can’t find the .ascx it will load .aspx afterall.  You can also create a target-specific .ascx file: if you do an ajax-request through our javascript function jQuery.mvc.request() (or one of the htmlhelper functions), you have to specify a target for the loaded content. Let’s say we want to load /Home/Index into a <div id="dynamiccontent"></div>
The AjaxViewLocator will then look for :

1. /Views/Home/Index.dynamiccontent.ascx
2. /Views/Home/Index.acx
3. /Views/Home/dynamiccontent.ascx
4. /Views/Home/Index.aspx
5. /Views/Shared/Index.dynamiccontent.ascx
6. /Views/Shared/Index.ascx
7. /Views/Shared/dynamiccontent.ascx
8. /Views/Shared/Index.aspx

To have the page /Home/index available both as an ajax request as well as normal request, you could create an /Views/Home/Index.aspx which loads the index.ascx like so:

Things to know

• We have some HelperClasses to simplify the use of jqmvc

• The ViewData keys "Messages" and "Errors" are treated specially by jqmvc.

• Your page should always contain:

  • <%= Html.RegisterJqueryMvc(Page.ClientScript) %> To register the required javascript files

  • <div id="loading"></div>; or something else with id="loading". This will be made visible during ajax-requests

  • <div id="errors"></div> to display errors

  • <div id="messages"></div> to display messages (informational)

• We have a special contentplaceholder in JqueryMvc.UI.WebControls.ContentPlaceHolder. This will use the AjaxViewLocator to load some default content. Eg, if used like this in your masterpage, and the current request is /Home/Index:
  <jq:ContentPlaceHolder ID="maincontent" runat="server" />
  It will look for for content in:

  1. /Views/Home/Index.maincontent.ascx
  2. /Views/Home/Index.acx
  3. /Views/Home/maincontent.ascx
  4. /Views/Home/Index.aspx
  5. /Views/Shared/Index.maincontent.ascx
  6. /Views/Shared/Index.ascx
  7. /Views/Shared/maincontent.ascx
  8. /Views/Shared/Index.aspx

     This way, your index.aspx could just be an empty page that points to MasterPage with this default-content-loading contentplaceholer.

• Your ascx files should inherit from JqueryMvc.Mvc.ExtViewUserControl to have access to the AjaxHelper (bug in asp.net mvc!) and to have the messages & errors parsed by jqmvc.
• In case of an error the default controller will look for a rescue page in /Views/[ControllerName]/Rescues/error.aspx or /Views/Shared/Rescues/error.aspx (or .ascx in case of an ajax request). You can specify your own rescues for different types of errors by using the RescueAttribute of
• You should remove default.aspx if your application-server supports wildcard mappings.

I also made up a nice(r) way to inject the ViewEngine into the BaseController. It’s now injected through a public method using a MethodInjection attribute:

Thanks to this method, we no longer have pre-register all the Controllers with our container (in the previous version of jQueryMvc I scanned all dll’s on ApplicationStart to register the Controller and assign the ServiceViewFactory as the default ViewFactory)

Furthermore, since the ASP.NET MVC team decided to change the way the Views are rendered (now through a ViewEngine, which is nice I think), it was no longer needed to use the code from Aaron Lerch. Though still inspired by his code ofcourse, I removed almost all of his code now. We now have a single ‘ServiceViewEngine‘ inheriting from the ASP.NET MVC’s default WebFormViewEngine. All code deciding what view to render, is now located in this class.

What I did not like about preview 2, is that the name of the master-template cannot be set from within the ViewEngine. It’s now stored into the ViewContext, and the setter is private . So now the mastertemplate is set in the BaseController, causing the BaseController to have to know what type of request the current one is (which is bad):

As usual, you can download the hottest source from the Subversion repository at http://code.google.com/p/jquerymvc/source/checkout or you can download a zipped package of the source code.