Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?
Experience Sitecore! | All posts tagged 'MVC'

Experience Sitecore!

Martin Miles on Sitecore

Helix project, MVC routing and the form posting back to controller. Part 3 - Adding validation

In previous post we have created an MVC form, that submits to a feature controller and set up the routing to make it all work. In this part we'll add validation to that form. This part does not differ from traditional MVC approach, however let's make our form smooth and complete.

1. Add validation controls into a page for each of inputs:

@using (Html.BeginRouteForm(MvcSettings.SitecoreRouteName, FormMethod.Post))
{
    @Html.LabelFor(x => x.FirstName)
    @Html.TextBoxFor(x => x.FirstName)
    @Html.ValidationMessageFor(x => x.FirstName)

    @Html.LabelFor(x => x.LastName)
    @Html.TextBoxFor(x => x.LastName)
    @Html.ValidationMessageFor(x => x.LastName)

    @Html.LabelFor(x => x.Email)
    @Html.TextBoxFor(x => x.Email)
    @Html.ValidationMessageFor(x => x.Email)









}
2. Model needs to be updated with validation action filter attributes, provided by DataAnnotations:
using System.ComponentModel.DataAnnotations;

namespace YourSolution.Feature.Test.Models
{
    public class TestModel
    {
        [Display(Name = nameof(FirstNameLabel), ResourceType = typeof(TestModel))]
        [Required(ErrorMessageResourceName = nameof(Required), ErrorMessageResourceType = typeof(TestModel))]
        [MinLength(3, ErrorMessageResourceName = nameof(MinimumLength), ErrorMessageResourceType = typeof(TestModel))]
        public string FirstName { get; set; }

        [Display(Name = nameof(LastNameLabel), ResourceType = typeof(TestModel))]
        [Required(ErrorMessageResourceName = nameof(Required), ErrorMessageResourceType = typeof(TestModel))]
        [MinLength(3, ErrorMessageResourceName = nameof(MinimumLength), ErrorMessageResourceType = typeof(TestModel))]
        public string LastName { get; set; }

        [Display(Name = nameof(EmailLabel), ResourceType = typeof(TestModel))]
        [EmailAddress(ErrorMessageResourceName = nameof(InvalidEmailAddress), ErrorMessageResourceType = typeof(TestModel))]
        [Required(ErrorMessageResourceName = nameof(Required), ErrorMessageResourceType = typeof(TestModel))]
        public string Email { get; set; }

        // Labels and validation messages: instead of hardcoded you may take it from Dictionary
        public static string FirstNameLabel => "First name";
        public static string LastNameLabel => "Last name";
        public static string EmailLabel => "E-mail";
        public static string Required => "Please enter a value";
        public static string MinimumLength => "Should be at east 3 characters";
        public static string InvalidEmailAddress => "please enter valid email address";
    }
}
3. Last but not the least, need to decorate POST action with validation action filter attribute, that runs validation prior to executing controller and returns validated view model on failure or runs into controller action if there no errors. So, updated controller action:
        [HttpPost]
        [ValidateModel]
        public ActionResult Test(TestModel loginInfo)
        {
            // do something on successful form submission
            return new RedirectResult("/SuccessfulResultPage");
        }
4. And of course, the ValidateModelAttribute class itself:
using System.Web.Mvc;

namespace YourSolution.Feature.Test.Attributes
{
    public class ValidateModelAttribute : ActionFilterAttribute
    {
        public override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            var viewData = filterContext.Controller.ViewData;

            if (!viewData.ModelState.IsValid)
            {
                filterContext.Result = new ViewResult
                {
                    ViewData = viewData,
                    TempData = filterContext.Controller.TempData
                };
            }
        }
    }
}

5. After running gulp commands for updating views and DLL libraries, an updated page would do validation similar to:


That's it! Finally, our feature project named Test would have the following structure in Solution Explorer:



Thanks for reading!

Helix project, MVC routing and the form posting back to controller. Part 2 - Creating a form

In previous part, we created a test feature, as a part of a Helix-based solution. We also created a page and rendering and wired it together. So, now it's time to create a form.

As a start, let's create a controller, as it is referenced from rendering definition item:

namespace YourSolution.Feature.Test.Controllers
{
    public class TestController : Controller
    {
        public ActionResult Test()
        {
            return View();
        }
    }
}

Then create corresponding Razor view..

@using Sitecore.Mvc.Configuration
@model YourSolution.Feature.Test.Models.TestModel

@using (Html.BeginRouteForm(MvcSettings.SitecoreRouteName, FormMethod.Post))
{
    @Html.LabelFor(x => x.FirstName)
    @Html.TextBoxFor(x => x.FirstName)
    
    @Html.LabelFor(x => x.LastName)
    @Html.TextBoxFor(x => x.LastName)

    @Html.LabelFor(x => x.Email)
    @Html.TextBoxFor(x => x.Email)
}



.. and model that represents our form, to be passed between controller and view:

namespace YourSolution.Feature.Test.Models
{
    public class TestModel
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Email { get; set; }
    }
}

As we are working with a project outside of webroot, we need to use gulp in order to copy this view into corresponding folder on the website (or you may copy that manually), same for the feature DLL.

After refreshing browser you will see the view. Obviously, when trying to hit "Submit" button - nothing happens as there's no POST controller action method. So let's add the one:

namespace YourSolution.Feature.Test.Controllers
{
    public class TestController : Controller
    {
        public ActionResult Test()
        {
            return View();
        }

        [HttpPost]
        public ActionResult Test(TestModel loginInfo)
        {
            // do something
        }
    }
}

Still not there... why? Let's troubleshoot that. First thing to do is to find out where form does POST to. In webinspector, it shows:

  <form action="/test" method="post"> ... </form>

So far so good - that looks correct (form POSTs to itself). But how /test URL corresponds to YourSolution.Feature.Test.Controllers.Test() method of YourSolution.Feature.Test feature project?

That's where routing comes into a play. As you know, feature is just a single project that is built into individual DLL and is deployed into /bin folder of project webroot along with other libraries. So how do we wire up /test with that particular method?

We apply config patch Feature.Test.config in order to add a pipeline processor right before the one that initializes MVC routes.






      
    
  

After running gulp configuration task this patch will be put into YourSolution/Website/App_Config/Include/Features folder along with custom configuration include file patches for other feature modules. Corresponding processor will be the following:

using System.Web.Mvc;
using System.Web.Routing;
using Sitecore.Pipelines;

namespace YourSolution.Feature.Test.Pipelines
{
    public class RegisterWebApiRoutes
    {
        public void Process(PipelineArgs args)
        {
            RouteTable.Routes.MapRoute("Feature.Test.Api", "api/test/{action}", new { controller = "Test" });
        }
    }
}

Finally the last bit to make routing work - modify _ViewStart.schtml view file on the project level. Here is it:

@{
    Layout = (this.ViewContext.IsChildAction) || (this.ViewContext.RouteData.Values.ContainsKey("scIsFallThrough") && 
        Convert.ToBoolean(this.ViewContext.RouteData.Values["scIsFallThrough"])) ? null : "~/Views/Shared/_Layout.cshtml";
}

If you have done everything correctly, after gulp'ing your assets into web folder and refreshing the page in browser, you'll see a form similar to the one below:


That's it! Now the form is fully functional and POSTs to a controller, however in order to make things even better - let's apply form validation.

References:

Sitecore Helix Documentation


Helix project, MVC routing and the form posting back to controller. Part 1 - Prerequisites

At the moment I am working on challenging project that is powered by Sitecore 8.2and follows Helix principles.

Last week I implemented a Feature, that has an MVC form posting back to its controller (here I mean native MVC, not Web Forms for Marketers) module. "Not a big deal" - I thought initially... and spent more time that positively expected until finally got it implemented.

The difference between Helix project and more traditional Sitecore MVC application is that in Helix your assets - controllers, views, statics etc. are kept within an individual project for a particular Feature (or Foundation, or Project - depending on what functionality you're implementing).

Prerequisites.

I assume you already have your Helix solution ready (you may use Habitat, as an "instance" of Helix). So let's start with Sitecore.

I create a page called Test under website root using one of page templates. Next, a rendering is required to be assigned into a placeholder on a page. I create a controller rendering named Test and put it under this feature folder (also called Test). Please notice, that I have to specify controller with fully qualified name with a name of assembly where this controller resides.


Tip: do not forget to publish your items, unless you're working in a live mode from Master DB directly.


Next, let's create a project structure in Solution Explorer. As we're building a Feature, create a solution folder under Feature folder in Visual Studio and name it Test (as a feature name). Create a class library project within that folder following Helix naming conventions YourSolution.Feature.Test with the same namespace and assembly name. The easiest probably would be simply to copy project folder from an existing feature and change namespace / types there.


You need to have Web config to the project root. Please ensure you are referencing the same .NET version as set in Target Framework of the project, in my example it is 4.5.2:






  





      



      



      



      



      
    
  




    
  






    
  


Also you need to have web.config within the /Views folder to make IntelliSense work properly





Below is the minimum references you'll need to have. DataAnnotations library is not essential, for sure, but is included because it'll be needed at step 3):



At this stage we're set. Let's mote to the next step - creating and wiring up a MVC form on a rendering.

References:

Sitecore Helix Documentation

StackOverflow 2 questions on Multi-Site configuration: Multisite Best Practice for setting up Visual Studio Project and Manage web.config in multisite solution

Got to answer two question about multi-site configuration working with Sitecore:

1. Sitecore Multisite Best Practice for setting up Visual Studio Project (link to original question)

I'm seeking an advise on best practice that has worked for creating a asp.net MVC visual studio solution that supports multisite (multi tenant). One thing we would like to do is minimize the regression defects so that developer don't modify the wrong website code base etc.
That the solution needs to support more than 8 web sites.

2. Manage web.config in sitecore multisite solution (link to original question)

We have a multisite solution with individual visual studio solutions for each websites. Then we have master solution to build/deploy all websites.
Firstly, not sure whether it's a best practice to include web.config in Visual Studio solution. But I think all the nuget packages needs web.config to add their settings.
As a result, we have web.config for each solution. However when we deploy from master web.config gets overwritten by each sites. Could someone please suggest how this issue can be fixed?

Answers:

I have got one more alternative to address that. Currently working on a huge project, with dozens of developers and quite bureaucratic process of deployments, we have introduced the following approach:

  1. Project consists of multiple logical subparts, which in fact are individual websites.
  2. Each of those websites we set up as an MVC Area with own controllers, views etc
  3. Most important - we set up MVC Areas as individually pluggable DLLs. So each of that websites is a separate project under solution, with its own resources and statics; on build everything is copied under their required paths and DLL goes to the \bin folder.
  4. One more class library for shared (by all websites) resources, it is being referenced only by those sites, that need that functionality
  5. In Sitecore, we have the same strict principles - the content, layouts, renderings are isolated as higher as possible, no individual content may be re-used (unless from shared resources folder).

This approach serves us almost a year already and has proven for its agility, much easier deployment and fairly less code merge conflicts. If you are working under just one site - you don't need to re-compile and re-deploy everything - just replace one dll at bin folder.

Thus, combining that with your question, Approach 1 would be an answer.

References (more to read):

Regarding managing configuration, I would advise for each website (under its individual project) to create it's own App_Config/Include folder and create _project_name_.config within that folder in order to keep all site-specific settings there (for further merge into resulting config).

On build you set up (for each individual project) that file to be copied into main SITECORE_INSTANCE_WEB_ROOT\App_config\Include folder along with the rest of include patch config files.

Hope someone finds that helpful!

StackOverflow: Including MVC in existing Sitecore Project

Recently one chap has asked a question oh how to include MVC into existing Sitecore project. A guy coming from classical ASP.NET MVC background experienced confusion with MVC implemented in Sitecore (here's an original link on StackOverflow). I decided to give a comprehensive answer on how MVC work with Sitecore:


Answer: In the very simplest way, you need to have the following:

  1. Item for your page, the one that has URL; that is as normal in Sitecore
  2. That page Item should have Layout assigned. From Presentation --> Details menu select at least a layout on that stage. If you do not have layout yet, you need to create a layout definition item under /Layout/Layouts folder and associate it with certain *.cshml file. Also mention that layout should have a placeholder where you will "inject"your rendering.

    @Html.Sitecore().Placeholder("Main")
    
  3. You need to create a Controller Rendering under /Layout/Renderings folder in Sitecore. Make sure you set Controller and Controller Action fields to your controller name and action method name. enter image description here

  4. Finally, go again to Presentation --> Details --> Edit --> Controls and add your newly created rendering into a placeholder that you have on your layout *.cshtml file. enter image description here

That's all done.


StackOverflow: Adding route in Application_Start

One more question I could not pass by on StackOverflow (link to original question):

I am using sitecore 7.5 and I need to add new route in application_start in order to use it in ajax call but when I run the application it seems that sitecore deals with the route as content item any help please.

Below in my answer:

Here is the code that creates a route for you. In global.asax.cs you will call RegisterRoutes from App_Start event handler:

    protected void Application_Start()
    {
        RouteConfig.RegisterRoutes(RouteTable.Routes);
    }

And there you specify your route as:

    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.MapRoute(
             name: "test",
             url: "mvc/Forms/{action}/{id}",
             defaults: new { controller = "Forms", action = "Test", id = UrlParameter.Optional }
           );
    }

You will have /mvc/ prefix in this case that will handle your route to specifies controller, so you will call it as:

/mvc/Forms/Test/{you_may_pass_some_optional_GUID_here}

This will route to FormsController class action method Test(string id) but you may omit id parameter

A bit of attention: Please note that setting route in Application_Start is not the best way of doing that; much better is to implement mapping routes at Initialize pipeline, as it fits Sitecore architecture:

public class Initialize
{
    public void Process(PipelineArgs args)
    {
        MapRoutes();
    }

    private void MapRoutes()
    {
        RouteTable.Routes.MapRoute(
                "Forms.Test", 
                "forms/test", 
                new
                {
                    controller = "FormsController",
                    action = "Test"
                },
                new[] { "Forms.Controller.Namespace" });
     }
}

The rest of implementation: Also I have previously wrote an article in my blog about how to implement ajax call to a route, that will guide you through the rest of the implementation process:

http://blog.martinmiles.net/post/editing-content-on-a-cd-server

Update: Please also make sure your config has a handler to handle your prefix, see below:

<customHandlers>
    <handler trigger="~/mvc/" handler="sitecore_mvc.ashx" />
Hope someone finds this helpful!


Sitecore MVC areas as pluggable separate DLL - making areas further more independent!

I want to share my experience of implementing MVC Areas as an individually pluggable (into the host website) DLL, that contains the code of specific area: controllers, models / view models, some area-specific DLL. The proof of concept was created by my great colleague Chandra Prakash, I decided to pick it after him and implemented in our product, so now it is 8 month as it works in production without any issues at all.


We are working in a big enterprise Sitecore-hosted project with more than hundred of developers, so each deployment process may bring a pain. Pluggable areas implementation has proven its concept and helped us to keep updating only those parts of entire multisite Sitecore solution that have been updated, without any risk of affecting the rest!


Features:

  • no need to code anything in a host website, thus:
  • no need to rebuild whole big outer solution - just rebuild (and replace) DLL
  • no more need to struggle with complex dependencies
  • simplified update: drop DLL into host website bin folder, and copy some static files referenced by this DLL - js, css, cshtml, img.

In day-to-day usage you will have the only one minor overhead of that implementation: 2 extra fields in controller rendering. In fact, instead of standard Controller Rendering we are using Area Controller Rendering that is derived from Controller Rendering just with addition of 2 extra fields required to resolve the area on a fly:



Sound attractive, isn't it? Then look how it is implemented - I address to the original article with more detailed explanations.




Editing content on a CD server. Part 1. MVC ajax request to controller

Imagine the situation, when you need to have a page with an updatable text, for instance:

This div becomes editable as you click it

Now the next logical step would be to fire on blur client event (it happens when out focus out of div, ending the editing mode) and send changed content somewhere to the back end. Something simple like jQuery snippet below can handle that:


$('#editField').blur(function () {
        
    $.ajax({
        url: 'some/backend/url/to/post',
        data: { name: value },
        type: 'post',
        success: function () {
            // handle success 
        },
        error: function () {
            // handle error
        }
    });
});

So far, so good. The very next question would be - how do I create an endpoint in Sitecore to support that ajax post request and how do I pass the data and handle positive and negative outcomes? I assume, the back end should have some MVC controller action, that does some back end job of storing my data and returning JSON object back to client script.

So in order to make this work we register MVC routes, this is referenced from Application_Start event handler and is usually implemented in App_Start folder.
    public class Application : Sitecore.Web.Application
    {
        protected void Application_Start()
        {
            RouteConfig.RegisterRoutes(RouteTable.Routes);
        }
    }
    public class RouteConfig
    {
        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.MapRoute(
                 name: "ajax",
                 url: "api/Ajax/{action}/{id}",
                 defaults: new { controller = "Ajax", 
                                 action = "DefaultActionMethodName", id = UrlParameter.Optional }
               );
        }
    }

This route binds all the /api/Ajax requests to be served by AjaxController class. But there is one more setting you require to do in order for your request to go the right direction - in config file set up a custom handler that will intercept that types of requests:

  
    ...
    
    ...

Controller action method being called is specified by caller, and will call DefaultActionMethodName as a default fallback if missing, passing id is optional. Here is the controller:

    public class AjaxController : Controller
    {
        [HttpPost]
        public ActionResult PostComment(string id, PostCommentViewModel model)
        {
            // implement backend logic here

            return Json();
        }
    }

 Controller accepts id as a parameter automatically resolved from URL, as specified in route we configured earlier. It also accepts and binds JSON object that we send as data into PostCommentViewModel object that automatically comes into controller as second parameter. Here is its implementation:

    public class PostCommentViewModel
    {
        [AllowHtml]
        public string Comment { get; set; }
    }
So, we can now finalize jQuery snippet that handles blur effect and sends data to controller. I have intentionally simplified it using external JavaScript objects, for clarity of understanding, you would normally avoid using global JavaScript variables in production code. These objects are used to keep state between ajax calls and to call server only when content is modified indeed. 
If there was an error on server, script retains previous value. If request worked out successfully with a status code 200 (OK) the we store updated value into <div> tag.  
var contents = $('#editField').html();
var id = '@Html.Sitecore().CurrentItem.ID';

var data = {};

$('#editField').blur(function () {
    if (contents != $(this).html()) {

        $.ajax({
            url: '/api/Ajax/PostComment/' + id,
            data: { Comment: $('#editField').html().trim() },
            type: 'post',
            success: function () {
                contents = $('#editField').html();
                var k = 0;
            },
            error: function () {
                $(this).html(contents);
            }
        });

        contents = $(this).html();
    }
});

On the server side there is not much to do with it - just save to database and return the result. Here is the final code of PostComment action of AjaxController:

 public class AjaxController : BaseController
    {
        [HttpPost]
        public ActionResult PostComment(string id, PostCommentViewModel model) // change to HtmlString
        {
            //Response.StatusCode = 500; 

            Database database = Sitecore.Context.Database;
            var item = database.GetItem(id);

            using (new Sitecore.SecurityModel.SecurityDisabler())
            {
                item.Editing.BeginEdit();
                try
                {
                    item.Fields["Comment"].Value = model.Comment;
                }
                finally
                {
                    item.Editing.EndEdit();
                }
            }

            item = database.GetItem(id);
            var val = item.Fields["Comment"].Value;

            return Json(id + " |" + model.Comment);
        }
    }

Wildcard items ("*"-pages) with MVC, passing the correct datasources based on requested item URL

As you probably know, there is a feature in Sitecore, called "wildcard items". Let's say you have a folder where multiple subitems suppose to be and should be presented by similar pages. Sitecore allows you create a wildcard item named "*" (asterisk) so that it will serve any request to this folder. Let's take a look on example below:


Here we see clear separation of pages and data. Airports page has the only child - wildcard page item that is highlighted (and you see its details). Below, in /Data folder, there is a corresponding data sources for each of the airport.

In usual scenario, there should be a page item created for each of airports from /data folder, and page's presentation details screen should have that data items set as the datasource for corresponding rendering (yes, we are on MVC here). But how to have this working, if we have only one universal page item? We have a rendering called Airport to display airport info, but how should we specify the datasource to it?


The rendering relies on RenderingContext.Current.Rendering.DataSource as usual. And instead of datasource of specific airport, we get "*" item as the datasource in all cases, regardless of what airport's page we're loading.

I wanted to leave page's datasource and rendering untouched, as normal implementation. Instead, I decided to incline into mvc.getRenderer pipeline and resolve datasources for "*"-wildcard-items dynamically, based on the URL requested, so that rendering get corresponding data item from RenderingContext.Current.Rendering.DataSource. And of course, as "*"-items serves all possible requests to its folder, I must provide datasources only for matching data items, redirecting all the rest to 404 error page (since there's no data for the page - there's no sense in such a page).

So here's my implementation of wildcard datasource resolver:







Airport
        
      
    
  

Code referenced from configuration patch file:

    public class WildcardDatasource : GetRendererProcessor
    {
        public string RenderingName { get; set; }

        public override void Process(GetRendererArgs args)
        {
            if (args.PageContext.Item.Name == "*" && args.Rendering.RenderingItem.Name.IsSameAs(RenderingName))
            {
                string datasourceFolder = args.Rendering.DataSource.IsOK()
                    ? args.Rendering.DataSource
                    : string.Format("{0}/{1}", Paths.DataFolder.TrimEnd('/'), args.PageContext.Item.Parent.Name);

                string dataSourcePath = string.Format("{0}/{1}", datasourceFolder, 
                    args.PageContext.RequestContext.HttpContext.Request.Url.Segments.Last());

                var dataSourceItem = Sitecore.Context.Database.GetItem(dataSourcePath);
                if (dataSourceItem != null)
                {
                    args.Rendering.DataSource = dataSourcePath;
                }
                else
                {
                    // process 404 page not found
                }
            }
        }
    }


Things to improve in future:

  1. Add support for nested wildcards
  2. Find the way wildcard items work with Page Editor

Sitecore.Kernel and Sitecore.MVC delivered via a NuGet library

Update (01 Aug 2015):  Here is the alternative approach answer and the solution for blog post:


I was always wondering, why Sitecore yet hasn't hosted Sitecore.Kernel and Sitecore.MVC on the NuGet?

This would have simplified our (developers') life in some way, as for today, we have to keep an additional /Libs folder and reference those 2 DLLs out of it (but couple others will serve good as well, for instance Lucene DLLs etc.). That could also simplify versioning and dependencies issues for us as soon as we still are using NuGet package management, so we now have 2 folders for references, highlighted below:


If they avoid doing that for licensing purposes - that seems quite strange as mentioned libraries are very little part of what Sitecore is, plus they may just supply obfuscated DLLs via NuGet and normal reflection-friendly via standard platform installation.

Here is what I have in my Libs folder and that I use and reference in small proof-of-concept project:


Dear Sitecore, if you read me, please consider using NuGET - today's industry standard for packaging and resolving dependencies .