In my last blog post about using the MVC Framework inside Sitecore, I announced that I’d write another blog post on how to actually create a real world application with MVC inside Sitecore. The first blog post was just a proof of concept, creating a real world application with it, helps completing the code.

Sitecore has announced that it will support MVC in Sitecore version 6.6. Great news! This tutorial will use the technical preview of Sitecore 6.6 to rebuild the mvc musicstore inside a Sitecore environment.

Since Microsoft has already created a nice tutorial for getting started with ASP.NET MVC : MVC Music Store tutorial. I figured it’d also be a nice tutorial to get started with MVC inside Sitecore. It’s an easy to follow, small tutorial, which makes it easy to go through for both experts and beginners in the world of MVC. Experts can just skip the parts explaining how MVC itself works and go straight to the action. For beginners, the entire tutorial takes less then 2 hours. It will be the best invested 2 hours of your programmer’s life so far !

Once you have completed the Microsoft tutorial, the steps in this blog-post will help you transform it to a Sitecore project.

Step 1 – complete the tutorial

First, follow the entire tutorial (or if you’re an expert on MVC already, just download the package:http://mvcmusicstore.codeplex.com/)

Step 2 – Get Sitecore running with MVC support

Follow the instructions given by John West to get Sitecore 6.6 with MVC support up and running.

Step 3 – copy contents

Copy the wwwroot contents of the mvcmusicstore project into the wwwroot of an existing Sitecore project (or create a new one first), but SKIP the web.config files! Note that you should copy the web-files to the web folder of your sitecore project! (if you downloaded the package, the web-content is inside the ‘MvcMusicStore’ folder inside the zip file)

Now open the Sitecore project in visual studio, and add the project you just copied to your solution (File –> Add –> Existing project).

Step 4 – connectionstrings

Copy the connectionstring in the web.config of the original created MVCMusicStore project, to the App_Config\Connectionstrings.config inside your sitecore solution.

Step 5 – Global.asax

Modify the default route in global.asax.cs. You can do that by adding any static string value in front of the default route. I chose ‘musicstore_api’. Doing this will make all your controller actions accessible through /musicstore_api/home/index, this could come in handy for stuff you need to access without going through sitecore (eg. ajax calls, delete actions, etc)

If you now run your application, and everything went fine, your application should show the default sample Sitecore homepage. If you now go to /musicstore_api/ , the musicstore should work exactly the same as when you finished the original tutorial. (Note: if you downloaded the sample code instead of making your own, and you run in to the error code “Unable to find the requested .Net Framework Data Provider. It may not be installed.”, you need to install MS Sql Compact CE 4.0)

These first 5 steps were the steps required to get an existing MVC application working inside the sitecore wwwroot. Now we’ll start modifying the existing app to become an application fully powered by sitecore!

Step 6 – Create layout

In Visual Studio, copy /Views/Shared/_Layout.cshtml to /Views/Shared/_SitecoreLayout.cshtml

Open _SitecoreLayout.cshtml and replace

with

In the Sitecore Content Editor user interface, navigate to the /sitecore/layout/Layouts/ folder that contains the default layouts. Underneath, create a new ‘Layout folder’ named ‘MVC MusicStore’. Now copy the ‘Sample layout’ item and paste it inside your newly created folder (using your right mouse button), name it ‘Shared layout’

Having your newly pasted layout selected, go to the ‘content’ tab, and change the Path field to /views/shared/_SitecoreLayout.cshtml

Step 7 – Create Sitecore templates

Run your application, and go the the Sitecore desktop (/sitecore/shell/default.aspx) and open the template manager.

Add a new template folder underneath ‘Templates\User defined’ called ‘MVC MusicStore. Underneath that new folder, add a new template.

Call the new template ‘Default page’ and just let the base template field as it is. Click next, next, finish.

Select your new ‘Default page’ item in the tree, and on the ribbon ‘Builder options’ click the ‘Standard values’ button in the template section.

And next on the ‘Presentation’ ribbon, click the ‘Details’ button in the layout section

This will open the layout details wizard:

Here, click the Edit-button under the ‘Default’ section (marked with a red border in the screenshot above), which will open the “Device Editor” popup:

In the dropdown, choose the ‘Shared Layout’ the MVC MusicStore folder and click OK twice

Step 9 – Register controller actions

Unfortunately, Sitecore does not automatically detect all controller actions and registers them as a rendering, like BoC.Sitecore.Mvc does. I will update BoC.Sitecore.Mvc ofcourse, to auto register all your controller actions, but for now, you will have to add them by hand.

In the Sitecore contenteditor, navigate to /sitecore/Layout/Renderings. Click the item with your right mouse button and choose Insert->Rendering Folder, name it ‘MVC MusicStore’. Inside that folder, add another folder ‘Home’. Click with the right mouse button on that Home item, and choose Insert->Controller rendering. Name it ‘Index’

Select your new rendering, and in the content tab, enter ‘Home’ as the controller, and ‘Index’ as the action.

Now you’ll have to do this for all actions wer’re going to use in this tutorial, your tree should end up like this:

Step 9 – Create sitecore items

Based on our previously created ‘Default page’ template, we’re now going to add the Sitecore items based on this template.

Open up the content editor in sitecore, and delete the exiting homepage item (/sitecore/content/home). Add a new Home item by click the ‘Content’ item with the right mouse button and choosing ‘Insert –> Insert from Template’.

Call the item Home and pick our just created ‘Default page’ template as it’s template

Using this same template, create the following tree inside Sitecore:

IMPORTANT Notice the * in front of Genre and Id…. these are wildcard mappings! The nameof the items should be * and the displayname *Genre and *Id.

Step 10 – Attach controller actions

On these pages, we’ll attach the appropiate MVC Action. Start with the Home item. Click on it in the tree, and open the ‘Presentation’ ribbon. Now click on the details button:

This will open the layout popup

Now click the Edit-button under the ‘Default’ section (marked with a red border in the screenshot above), which will open the “Device Editor” popup

Click the controls tab, and choose ‘Add’. That will bring up the ‘Select a rendering’ window.

Choose Renderings/MVC MusicStore/Home/Index and enter ‘main’ as the placeholder name (remember we added that $Html.SitecorePlaceholder(“main”) to _SitecoreLayout.cshtml?). Click on Select, and then on OK twice to save all your changes.

Now do the same for all other pages you’ve created except the ‘checkout’ page (that is just a placeholder). The other pages should get the following controls:

• Checkout –> Renderings/MVC MusicStore/Checkout/Complete
• Checkout/AddressAndPayment –> Renderings/MVC MusicStore/Checkout/AddressAndPayment
• ShoppingCart –> Renderings/MVC MusicStore/ShoppingCart/Index
• Store –> Renderings/MVC MusicStore/Store/Index
• Store/Browse –> Renderings/MVC MusicStore/Store/Browse
• Store/Browse/*Genre –> Renderings/MVC MusicStore/Store/Browse
• Store/Details –> Renderings/MVC MusicStore/Store/Details
• Store/Details/*Id –> Renderings/MVC MusicStore/Store/Details

Step 11 – Publish & test

Now, publish your entire site (! beware that if you’re using the sample database with the sample item template, that there is a worfklow attached to the new items by default… you need to approve them before publishing). After publishing, you can go checkout the homepage of your website. HEY! It’s just showing ‘default page’ ??

This is because by default, Sitecore holds a default.aspx in the root, and MVC by default does not trigger any route if the file exists on disk. You can enable routing for existing files by adding ‘routes.RouteExistingFiles = true;’ to the RegisterRoutes method in global.asax.cs, or you can just delete the default.aspx. I chose the latter one: just rename your default.aspx page in the root of your website’s folder to default.aspx.bak. Refresh your homepage.

Much better, but now what! the navigation menu and logo are shown twice!

Step 12 – Modify viewstart

The reason for the page being displayed twice, is because the default MVC Musicstore project does not take into account that the views can be accessed as a child-action. Adding the actions as a sublayout inside our sitecore pages, makes the actions being rendered as childactions. To skip the layout being rendered in child mode, open Views/_ViewStart.cshtml and modify the one line that’s in there to:

(I do hope Sitecore will support ViewContext.IsChildAction, as that is the official way to check if your view should be partially rendered)

Save the file, and check the homepage again: Looking just fine now!

Step 13 – Modify Links

Though the website looks good now, all links are pointing to the /musicstore_api folder. Even though that will work just fine, that’s the native MVC you’re calling then. To point all links to the sitecore versions, we’ll have to change all link renderings. This is the most dramatic change in an existing MVC application. In fact, we’ll break compatibility here, since the links will become Sitecore specific. I haven’t figured out a way to keep this compatible. Then again, I don’t think you’d ever even want that. Thing is, with a standard MVC application, a controller action always has it’s own url. With SitecoreMvc any page in Sitecore can use the same MVC Action over and over again, on different url’s. This is so different, it’ll be impossible to keep things cross-compatible.

First, we need to add 2 files to our MVC solution. One of the files will extend the default HtmlHelper with some extra methods to easily create links to Sitecore items. The other file will add support for wildcard items (remember that *Id and *Genre items you’ve created?). Download Extensions.cs and WildcardValueProvider.cs and add them to your solution (eg. in a Helpers folder) (these files will ofcourse also be part of the next BoC.Sitecore.MVC release, but we’re still working without external libs in this tutorial)

In your global.asax, register the wildcardvalueprovider in the application_start:

Now, go change all the links in the project….

Open Views/Store/GenreMenu.cshtml. Modify the @Html.ActionLink in there, to the following:

See how we’ve mapped Genre as a parameter? The wildcard resolver will pick that up.

In Views/Home/Index.cshtml and Views/Store/Browse.cshtml change the action Url.Action to

This is the alternate method to set the wildcard item (*Id): by providing an anonymous object with the correct values

The Html.ActionLink in Views/Store/Index.cshtml to

The Html.ActionLink in Views/ShoppingCart/CartSummary.cshtml to

In Views/ShoppingCart/Index.cshtml, change the $.post(“/ShoppingCart/RemoveFromCart” to

(See how this will go directly to MVC! This won’t hit any Sitecore item, hence the url would become /musicstore_api/shoppingcart/removefromcart).

In the same file, replace the checkout Html.ActionLink with

and the details Html.ActionLink to

In Views/ShoppingCart/Complete.cshtml change the Html.ActionLink to

In Controllers/ShoppingCartController.cs, in the AddToCart method, change the RedirectToAction to

and, the last one, in Controllers/CheckoutController.cs, in the AddressAndPayment method, change the RedirectToAction to

Step 13 – Remove authorization

As a last step remove the Authorize attribute on the CheckoutController. In this tutorial, we’ll not be setting up Account related stuff, it’ll be taken care with in the follow-up of this post.

Step 14 – Run

Now run your project again! Everything but Account-related stuff should work fine now! Add albums to your cart, check out, etc.

Conclusion

That concludes this tutorial for now. It should give you a good idea on how to get MVC up and running for your Sitecore projects.In the next blog post about Sitecore & MVC, I will explain how to use the Sitecore security in this MVC Musicstore and we’ll get rid of the external database by creating Sitecore items for the albums. I will try to add the new Model’s feature in Sitecore 6.6 for that. The albums will the be editable using both the Sitecore content-editor AND page-editor.

In the meantime, Sitecore has announced that it will support MVC in Sitecore version 6.5.1. Great news! I got a sneak preview of what they’ve made, looks great. From what I’ve seen, this tutorial won’t have to change much when they’ve released the official version. I’ll update the tutorial as soon as 6.5.1 will be released.

Since Microsoft has already created a nice tutorial for getting started with ASP.NET MVC : MVC Music Store tutorial. I figured it’d also be a nice tutorial to get started with MVC inside Sitecore. It’s an easy to follow, small tutorial, which makes it easy to go through for both experts and beginners in the world of MVC. Experts can just skip the parts explaining how MVC itself works and go straight to the action. For beginners, the entire tutorial takes less then 2 hours. It’ll be the best invested 2 hours of your programmer’s life so far !

Once you have completed the Microsoft tutorial, the steps in this blog-post will help you transform it to a Sitecore project.

Step 1 – complete the tutorial

First, follow the entire tutorial (or if you’re an expert on MVC already, just download the package:http://mvcmusicstore.codeplex.com/)

Step 2 – copy contents

Copy the wwwroot contents of the mvcmusicstore project into the wwwroot of an existing Sitecore project (or create a new one first), but SKIP the web.config files! Note that you should copy the web-files to the web folder of your sitecore project! (if you downloaded the package, the web-content is inside the ‘MvcMusicStore’ folder inside the zip file)

Now open the Sitecore project in visual studio, and add the project you just copied to your solution (File –> Add –> Existing project).

Step 3 – nuget package

Install the NuGet package BoC.Sitecore.Mvc (not the starter app) to your just added project. You can do that either through the package manager console or through tools->library package manager->Manage NuGet Packages for Solution…

This will modify your web.config to allow MVC applications inside your sitecore website, and will add the BoC.Sitecore.MVC reference which holds all the MVC magic.

Step 4 – connectionstrings

Now, copy the connectionstring in the web.config of the original created MVCMusicStore project, to the App_Config\Connectionstrings.config inside your sitecore solution.

If you now run your application, and everything went fine, your application should work exactly the same as when you finished the tutorial. (Note: if you downloaded the sample code instead of making your own, and you run in to the error code  “Unable to find the requested .Net Framework Data Provider.  It may not be installed.”, you need to install MS Sql Compact CE 4.0)

These first 4 steps were the steps required to get an existing MVC application working inside the sitecore wwwroot. Now we’ll start modifying the existing app to become an application fully powered by sitecore!

Step 5 – Global.asax

Running the application worked just fine, but there’s no sitecore magic somewhere in the pipeline, so let’s add that. First, we’ll modify the default route in global.asax.cs. You can do that by adding any static string value in front of the default route. I chose ‘musicstore_api’. Doing this will make all your controller actions accessible through /musicstore_api/home/index, this could come in handy for stuff you need to access without going through sitecore (eg. ajax calls, delete actions, etc)

Step 6 – Create ‘GetLayout’ controller action and view

Using BoC.Sitecore.Mvc, if you want a Razor view as your layout, you’ll have to load it through a controller action. If you don’t like creating a controller action for just loading the base layout, you could use Robert Jongkind’s RazorForSitecore module, it will all mix and match just fine. Sitecore 6.5.1’s version of MVC will also support picking a Razor view without a controller as your layout..

For now however, we’ll stick to using just the SitecoreMVC way. Open your HomeController.cs file and add new action called ‘DefaultLayout’. The only thing that action should do, is return View():

Also create the accompanying view, with just 1 line telling Sitecore it can render a placeholder with key “main” in this view. (Html.SitecorePlaceholder is an extension method inside BoC.Sitecore.MVC)

Step 7 – Create Sitecore templates

Run your application, and go the the Sitecore desktop (/sitecore/shell/default.aspx) and open the template manager.

Add a new template folder underneath ‘Templates\User defined’ called ‘MVC MusicStore. Underneath that new folder, add a new template.

Call the new template ‘Default page’ and just let the base template field as it is. Click next, next, finish.

Select your new ‘Default page’ item in the tree, and on the ribbon ‘Builder options’ click the ‘Standard values’ button in the template section.

And next on the ‘Presentation’ ribbon, click the ‘Details’ button in the layout section

This will open the layout details wizard:

Here, click the Edit-button under the ‘Default’ section (marked with a red border in the screenshot above), which will open the “Device Editor” popup:

In the dropdown, choose the ‘DefaultLayout’ MVC action underneath the Home controller and click OK twice

Step 8 – Create sitecore items

Based on our just created ‘Default page’ template, we’re now going to add the Sitecore items based on this template.

Open up the content editor in sitecore, and delete the exiting homepage item (/sitecore/content/home). Add a new Home item by click the ‘Content’ item with the right mouse button and choosing ‘Insert –> Insert from Template’.

Call the item Home and pick our just created ‘Default page’ template as it’s template

Using this same template, create the following tree inside Sitecore:

Notice the * in front of Genre and Id…. these are wildcard mappings! The name of the items should be * and the displayname *Genre and *Id.

Step 9 – Attach controller actions

On these pages, we’ll attach the appropiate MVC Action. Start with the Home item. Click on it in the tree, and open the ‘Presentation’ ribbon. Now click on the details button:

 
This will open the layout popup

Now click the Edit-button under the ‘Default’ section (marked with a red border in the screenshot above), which will open the “Device Editor” popup

Click the controls tab, and choose ‘Add’. That will bring up the ‘Select a rendering’ window.

Choose MVC Actions/Home/Index and enter ‘main’ as the placeholder name (remember we added that $Html.SitecorePlaceholder(“main”) to DefaultLayout.cshtml?). Click on Select, and then on OK twice to save all your changes.

Now do the same for all other pages you’ve created except the ‘checkout’ page (that is just a placeholder). The other pages should get the following controls:

• Checkout –> MVC Actions/Checkout/Complete
• Checkout/AddressAndPayment –> MVC Actions/Checkout/AddressAndPayment
• ShoppingCart –> MVC Actions/ShoppingCart/Index
• Store –> MVC Actions/Store/Index
• Store/Browse –> MVC Actions/Store/Browse
• Store/Browse/*Genre –> MVC Actions/Store/Browse
• Store/Details –> MVC Actions/Store/Details
• Store/Details/*Id –> MVC Actions/Store/Details

Step 10 – Publish & test

Now, publish your entire site (! beware that if you’re using the sample database with the sample item template, that there is a worfklow attached to the new items by default… you need to approve them before publishing). After publishing, you can go checkout the homepage of your website.

Hey! the navigation menu and logo are shown twice!

Step 11 – Modify viewstart

The reason for the page being displayed twice, is because the default MVC Musicstore project does not take into account that the views can be accessed as a child-action. Adding the actions as a sublayout inside our sitecore pages, makes the actions being rendered as childactions. To skip the layout being rendered in child mode, open Views/_ViewStart.cshtml and modify the one line that’s in there to:

Save the file, and check the homepage again: Looking much better!

Step 12 – Modify Links

Though the app looks good now, all links are pointing to the /musicstore_api folder. Even though that will work just fine, that’s the native MVC you’re calling then. To point all links to the sitecore versions, we’ll have to change all link renderings. This is the most dramatic change in an existing MVC app. In fact, we’ll break compatibility here, since the links will become Sitecore specific. I haven’t figured out a way to keep this compatible. Then again, I don’t think you’d ever even want that. Thing is, with a standard MVC application, a controller action always has it’s own url. With SitecoreMvc any page in Sitecore can use the same MVC Action over and over again, on different url’s. This is so different, it’ll be impossible to keep things cross-compatible.

Open Views/Store/GenreMenu.cshtml. Modify the @Html.ActionLink in there, to the following:

See how we’ve mapped Genre as a parameter? The wildcard resolver will pick that up. We could have also placed the name in the path attribute, that would resolve just the same:

Now do the same for all other links in the project. In Views/Home/Index.cshtml and Views/Store/Browse.cshtml change the action Url.Action to

The Html.ActionLink in Views/Store/Index.cshtml to

The Html.ActionLink in Views/ShoppingCart/CartSummary.cshtml to

In Views/ShoppingCart/Index.cshtml, change the $.post(“/ShoppingCart/RemoveFromCart” to

(See how this will go directly to MVC! This won’t hit any Sitecore item, hence the url would become /musicstore_api/shoppingcart/removefromcart).

In the same file, replace the checkout Html.ActionLink with

and the details Html.ActionLink to

In Views/ShoppingCart/Complete.cshtml change the Html.ActionLink to

In Controllers/ShoppingCartController.cs, in the AddToCart method, change the RedirectToAction to

and, the last one, in Controllers/CheckoutController.cs, in the AddressAndPayment method, change the RedirectToAction to

Step 13 – Remove authorization

As a last step remove the Authorize attribute on the CheckoutController. In this tutorial, we’ll not be setting up Account related stuff, it’ll be taken care with in the follow-up of this post.

Step 14 – Run

Now run your project again! Everything but Account-related stuff should work fine now! Add albums to your cart, check out, etc.

Conclusion

That concludes this tutorial for now. It should give you a good idea on how to get MVC up and running for your Sitecore projects.In the next blog post about Sitecore & MVC, I will explain how to use the Sitecore security in this MVC Musicstore and we’ll get rid of the external database by creating Sitecore items for the albums. The albums will the be editable using both the Sitecore content-editor AND page-editor. So watch this blog for the follow-up, though I’ll first write a post on an other topic.

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

Inspired by David Ebbo’s blog post ‘Turn your Razor helpers into reusable libraries’ I wanted to be able to embed compiled Razor views in a dll. This would allow for easy distribution of asp.net mvc ‘modules’ that have their default views embedded, but allowing you to place files in your ‘views’ folder to override those default views.

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!