Actya is a simple open source ASP.NET MVC Content Management System (CMS).

Why on earth would we need another CMS?

Quite often, a CMS is chosen as application framework for custom application development because you’ll get a lot for free: navigation, security and content management (obviously). Custom applications are then developed as modules that run within the context of the CMS. Cuyahoga, the CMS I’ve started  8 years ago works exactly like this.

Rob Conery describes an issue with this solution:

I’ve deployed Big CMS’s before as a solution for clients and every single time we decided to move away. They’re great for getting off the ground – but after a while there’s jus too much friction.

And that’s probably what many of us experience: a CMS gets in the way when your main focus is the custom application. This is the single main reason to create Actya: a CMS that doesn’t get in your way when doing custom development.

CMS as add-on

Actya can act as an add-on library for your application. While developing your custom application in Visual Studio, you can add it with NuGet just like any other library. The first time you run your application after adding Actya, an installer kicks in to ask you where you want to have your CMS data stored, what theme you want to use and which account is the CMS administrator. No further configuration required and nothing has to change in your custom application.

The video below shows this scenario with NuGetGallery as the ‘custom’ application:

Even though Actya is mainly designed to act as an add-on CMS, you can also use it as a simple regular CMS. Download it at from CodePlex downloads page, point an IIS 7+ web site or application to the extracted files, open de site in your browser and the installation starts automatically.

After installation, you can access Actya’s admin pages at http://my-host-or-application/cmsadmin.

RavenDB document database

Here’s the other reason for creating Actya: schema-less NoSQL databases are considered to be ideal for CMS applications because you can put any type of content in it without having to alter a database schema or have some kind of monstrous Entity-Attribute-Value model. I wanted to experience if that claim is true.

Actya uses the .NET NoSQL database RavenDB and it really makes development easier. Not only due to the flexibility of the schema-less design but also to the absence of a mapping layer. Wonderful! A cool feature of RavenDB is the embedded mode where you don’t need a database server at all. Actya uses this mode by default (the data goes in App_Data), but can also connect to an existing RavenDB server.

Requirements

• ASP.NET 4.0
• Full-Trust environment

Wanted: Feedback

I’ve released the first alpha version to see if anybody finds this CMS useful. Your feedback will have a have a lot of weight in determining future development. If you have any, please go to http://actya.codeplex.com/discussions and open a discussion with ‘User Feedback’ as topic.

A new version of the MvcPaging component is available via NuGet with the following changes:

• Added ItemStart and ItemEnd properties to IPagedList (Displaying items {ItemStart} – {ItemEnd}).
• Non-canonical url’s for page 1 (https://github.com/martijnboland/MvcPaging/issues/2).

So the core library hasn’t changed much, and in all honesty, I think it’s pretty much done. Please leave a reply if you think otherwise.

What did change substantially is the sample application. It was still very much ASP.NET 1.0 with WebForms views. This is now a proper ASP.NET MVC 3 application with Razor views and the default ASP.NET MVC 4.0 template for look & feel.

The sample application can be found at GitHub.

In ASP.NET MVC you can create your own model binders to control the way that models are constructed from an HTTP request. For example, if you don’t want any whitespace characters in your model, you can create a custom model binder that trims all whitespace characters when constructing  a model object. You only have to implement the IModelBinder interface and its BindModel method in a class and register it during application startup.

Getting the value from the HTTP request

There are many examples online of how to build a custom model binder. In all these examples you can find a common way of getting a value from the HTTP request:

public class MyModelBinder: IModelBinder
{
    public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        var valueProviderResult = bindingContext.ValueProvider.GetValue(bindingContext.ModelName);
        if (valueProviderResult != null)
        {
            var theValue = valueProviderResult.AttemptedValue;

            // etc...
        }
    }
}

The code above works nicely and you get protection for potential dangerous request values out of the box. Now let’s assume that we want some potential dangerous values like HTML or XML tags in our model. The recommended way is to add an [AllowHtml] attribute to the model property that may contain HTML and no validation happens for that property. Alternatively, it’s possible to add an [ValidateInput(false)] attribute to the controller action that accepts the model with HTML content, but this turns off validation for all model properties.

A potentially dangerous Request.Form value was detected from the client

Wait a minute! Didn’t we just explicitly say to allow those dangerous values? What’s happening?

It appears that a call to bindingContext.ValueProvider.GetValue() in the code above always validates the data, regardless any attributes. Digging into the ASP.NET MVC sources revealed that the DefaultModelBinder first checks  if request validation is required and then calls the bindingContext.UnvalidatedValueProvider.GetValue() method with a parameter that indicates if validation is required or not.

Unfortunately we can’t use any of the framework code because it’s sealed, private or whatever to protect ignorant devs from doing dangerous stuff, but  it’s not too difficult to create a working custom model binder that respects the AllowHtml and ValidateInput attributes:

public class MyModelBinder: IModelBinder
{
    public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        // First check if request validation is required
        var shouldPerformRequestValidation = controllerContext.Controller.ValidateRequest && bindingContext.ModelMetadata.RequestValidationEnabled;

        // Get value
        var valueProviderResult = bindingContext.GetValueFromValueProvider(shouldPerformRequestValidation);
        if (valueProviderResult != null)
        {
            var theValue = valueProviderResult.AttemptedValue;

            // etc...
        }
    }
}

The other required piece is a way to retrieve an unvalidated value. In this example we use an extension method for the ModelBindingContext class:

public static ValueProviderResult GetValueFromValueProvider(this ModelBindingContext bindingContext, bool performRequestValidation)
{
    var unvalidatedValueProvider = bindingContext.ValueProvider as IUnvalidatedValueProvider;
    return (unvalidatedValueProvider != null)
               ? unvalidatedValueProvider.GetValue(bindingContext.ModelName, !performRequestValidation)
               : bindingContext.ValueProvider.GetValue(bindingContext.ModelName);
}

It’s now possible to add the MVC pager to your own project with NuGet.

Or from Visual Studio with ‘Manage NuGet Packages…’ and then search for ‘MvcPaging’.

After installing, you can immediately use the Pager HtmlHelper in your views:

et voilà!

We also have include the IPagedList for your convenience:

For more info, check out the original blogpost that started it or the github project page.

Enjoy!

In almost every application, feedback from the application to the user via notification messages is required.

For some strange reason, we don’t have a standard way in .NET web applications for dealing with this kind of messages and I find myself hacking some half-baked solutions over and over again. Starting from today, this must end! In this post we’re going to find a solution for ASP.NET MVC 3.

One single way to display messages

This is the one and only requirement:

In every scenario I want to be able to call ShowMessage() from my controller action and the message appears on the screen.

ShowMessage extension method

To have a ShowMessage method in every controller action, we could implement it in a base controller class or create an extension method. Let’s try an extension method:

public static void ShowMessage(this Controller controller, MessageType messageType, string message, bool showAfterRedirect = false)
{
    var messageTypeKey = messageType.ToString();
    if (showAfterRedirect)
    {
        controller.TempData[messageTypeKey] = message;
    }
    else
    {
        controller.ViewData[messageTypeKey] = message;
    }
}

All this method does is take a message type enum (Success, Warning or Error) and a message and store it in either ViewData or TempData, depending on the flag ‘showAfterRedirect’. TempData is for Post-Redirect-Get situations.

We can now call ShowMessage(). With this solution it’s only possible to store one type of message per request, but that should be enough (even more than one message is already troublesome).

RenderMessages HTML Helper

Creating messages is one thing, but what about displaying them? It’s also easy. Enter the RenderMessages() HTML helper:

/// <summary>
/// Render all messages that have been set during execution of the controller action.
/// </summary>
/// <param name="htmlHelper"></param>
/// <returns></returns>
public static HtmlString RenderMessages(this HtmlHelper htmlHelper)
{
    var messages = String.Empty;
    foreach (var messageType in Enum.GetNames(typeof(MessageType)))
    {
        var message = htmlHelper.ViewContext.ViewData.ContainsKey(messageType)
                        ? htmlHelper.ViewContext.ViewData[messageType]
                        : htmlHelper.ViewContext.TempData.ContainsKey(messageType)
                            ? htmlHelper.ViewContext.TempData[messageType]
                            : null;
        if (message != null)
        {
            var messageBoxBuilder = new TagBuilder("div");
            messageBoxBuilder.AddCssClass(String.Format("messagebox {0}", messageType.ToLowerInvariant()));
            messageBoxBuilder.SetInnerText(message.ToString());
            messages += messageBoxBuilder.ToString();
        }
    }
    return MvcHtmlString.Create(messages);
}

It iterates through all possible message types, tries to find a message in either ViewData or TempData and creates a div with the message in it.

Put the helper in the Layout page, add some css classes (.messagebox, .succes, .warning and .error) and we’re all set.

What about AJAX?

Now this is getting tricky. In our AJAX actions, we can still call ShowMessage(), but how should the message be displayed if we only return some JSON data or a partial view? One solution would be to wrap all AJAX results in a special JSON view result with the notification messages and the original result embedded. Drawback is that we have quite some work to do on the client-side to handle all this.

HTTP headers to the rescue

I discovered a very nice solution on StackOverflow: use custom HTTP headers to store a message. With the help of a global action filter we can check if there are messages in the ViewData dictionary and when the request was an AJAX request, copy the messages to a custom HTTP header.

/// <summary>
/// If we're dealing with ajax requests, any message that is in the view data goes to
/// the http header.
/// </summary>
public class AjaxMessagesFilter : ActionFilterAttribute
{
    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        if (filterContext.HttpContext.Request.IsAjaxRequest())
        {
            var viewData = filterContext.Controller.ViewData;
            var response = filterContext.HttpContext.Response;

            foreach (var messageType in Enum.GetNames(typeof(MessageType)))
            {
                var message = viewData.ContainsKey(messageType)
                                ? viewData[messageType]
                                : null;
                if (message != null) // We store only one message in the http header. First message that comes wins.
                {
                    response.AddHeader("X-Message-Type", messageType);
                    response.AddHeader("X-Message", message.ToString());
                    return;
                }
            }
        }
    }
}

Finally the message in the HTTP headers are displayed with a little bit of jQuery:

$(document).ready(function () {
    handleAjaxMessages();
});

function handleAjaxMessages() {
    $(document).ajaxSuccess(function (event, request) {
        checkAndHandleMessageFromHeader(request);
    }).ajaxError(function (event, request) {
        displayMessage(request.responseText, "error");
    });
}

function checkAndHandleMessageFromHeader(request) {
    var msg = request.getResponseHeader('X-Message');
    if (msg) {
        displayMessage(msg, request.getResponseHeader('X-Message-Type'));
    }
}

function displayMessage(message, messageType) {
    $("#messagewrapper").html('<div class="messagebox ' + messageType.toLowerCase() + '"></div>');
    $("#messagewrapper .messagebox").text(message);
}

Demo

For a closer look check out the live demo or download the VS2010 solution from GitHub.

The MVC pager now has support for AJAX scenario’s, thanks to Bart Lenaerts. This was my first GitHub pull request and everything went pretty smoothly.

Check out the demo application for an example. Visit the GitHub project page to download the solution.

Just a short message to let you know that the MVC Pager demo is upgraded to ASP.NET MVC3 and VS 2010. Get it at https://github.com/martijnboland/MvcPaging.

During the last year I’ve been looking at various NoSQL databases. I’m particularly interested in the flexibility (no fixed schema) and I don’t care that much for scalability that some of these databases provide, therefore I focused on document databases like CouchDB, MongoDB and Raven DB.

After some reading, I decided it was time for an experiment and took Raven DB to create an ASP.NET membership provider. The main reason I chose Raven DB is that you can run it embedded in your .NET application (for example in ~/App_Data) without a separate server and it’s even possible to run the entire database in-memory, which is ideal for tests.

The result of the experiment can be found at https://github.com/martijnboland/RavenDBMembership. It’s a VS 2010 solution with the membership provider, some integration tests and an ASP.NET MVC 3 sample app. You can also directly download it from here.

Disclaimer:

I’m not sure that creating a Membership provider was the right thing to do to experience NoSQL. Sure, the provider works, but the Membership API forces you into a direction that isn’t necessarily suitable for document databases and there might be some NoSQL anti-patterns here and there in the code

Oh, and the ASP.NET MVC sample app extends the Membership mess that comes with the default MVC project template. Don’t take this as some best practices example.

The EF 4 code-first demo has been updated to reference the EF4 Feature CTP3 dll at its default location. To run the demo, you have to make sure that the you have it installed. Download the EF 4 Feature CTP3 at http://www.microsoft.com/downloads/details.aspx?FamilyID=af18e652-9ea7-478b-8b41-8424b94e3f58&displayLang=en.

Although the demo was originally developed with VS 2010 Beta 2 everything works perfectly fine on VS 2010 RTM.

You can find the demo sources at github: http://github.com/martijnboland/EF4-codeonly-demo where it’s also possible to download the sources all at once.

During work, I discovered that the pager that I created a while ago didn’t work properly when using ASP.NET MVC2 area’s. The links that were generated didn’t count for the current area that the controller and views were in, resulting in wrong urls. Luckily the ASP.NET MVC team also ran into this issue and created an GetVirtualPathForArea() extension method on RouteCollection. Calling this one, instead of GetVirtualPath() made things work properly in area’s.

You can get the code for ASP.NET MVC 2 at http://github.com/martijnboland/MvcPaging/tree/mvc2 (mvc2 branch of the MvcPaging repository).