Last week, a new version of the MvcPaging library has been released. This time there are some breaking changes and that’s why the major version number is increased.

What’s new:

• Simplified API with reduced number of Html.Pager overloads;
• DisplayTemplate option and PaginationModel;
• Configurable number of pages.

Simplified API

There have been some requests for extra configuration options, but I didn’t want to add more overloads to the Html.Pager helper. Instead, the number of overloads is reduced drastically:

Html.Pager(int pageSize, int currentPage, int totalItemCount)

and

Html.Pager(int pageSize, int currentPage, int totalItemCount, AjaxOptions ajaxOptions)

We now only have a method with the required parameters and one overload for Ajax scenarios. Also, the Ajax.Pager helper is removed. Note that this is a breaking change, so if you were using the Ajax.Pager helper, you now have to use the Html.Pager with the AjaxOptions overload.

Non-required configuration options are added via the Options() method. This interface also replaces the overloads in the previous version where you could set route values or controller actions. This is the second breaking change. You can now only set these values via the Options method.

Html.Pager(pageSize, pageNumber, totalItemCount).Options(o => o
    .Action("action")
    .AddRouteValue("q", mySearchQuery)
)

Below are all options:

• Action(string action)

  Sets an alternative action for the pager that is different from the current action.

• AddRouteValue(string name, object value)

  Adds a single route value parameter that is added to page url’s.

• RouteValues(object routeValues)

  Adds route value parameters that are added to the page url’s.

• RouteValues(RouteValueDictionary routeValues)

  Adds route value parameters that are added to the page url’s.

• DisplayTemplate(string displayTemplate)

  When set, the internal HTML rendering is bypassed and a DisplayTemplate view with the given name is rendered instead. Note that the DisplayTemplate must have a model of type PaginationModel.

• MaxNrOfPages(int maxNrOfPages)

  Sets the maximum number of pages to show.

DisplayTemplate option

A few people have been asking for configurable rendering, especially since Twitter Bootstrap has become popular. Rajeesh CV submitted a pull request that introduced a view model for the Pager, the PaginationModel. This view model made it very easy to create an option where you can specify a DisplayTemplate that is used for the actual rendering. It works like any other ASP.NET MVC DisplayTemplate and requires a model of PaginationModel. As a bonus, the PaginationModel makes unit testing a lot easier.

The MvcPaging.Demo project has an example DisplayTemplate that renders Html that is compatible with Twitter Bootstrap:

Html.Pager(pageSize, pageNumber, totalItemCount).Options(o => o
    .DisplayTemplate("BootstrapPagination")
    .MaxNrOfPages(14))

Configurable number of pages

As you can see in  the screenshot above, the pager can now be configured to show more or less than 10 pages via the MaxNrOfPages() option.

I’d like to thank Rajeesh CV, jbucht01 for the contributions and ideas. For more information, visit the GitHub project page, or install the Pager in your own projects with NuGet.

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.

Many to one associations and introduce a foreign key property

Let’s say it bluntly: EF supports Foreign Key associations  (foreign key id’s in your entities, besides many to one associations)  and you better use them, or you’ll experience a lot of pain. I started to model my entities with ‘proper’ object references but ran into 2 problems:

• Filtering in collection properties causes select n+1 issues. So forget:
  

  Order.OrderLines.Where(ol => ol.Product.Id == productId)

  but do:

  Order.OrderLines.Where(ol => ol.ProductId == productId)

  to filter a collection property because the first will load all product instances;

• When you override Equals() and GetHashCode()in your entities to use only the ID for object equality, you can assign an empty object with only the ID set as reference property in NHibernate but EF doesn’t fall for this trick. This is can be very useful, for example when setting references from a dropdownlist where you only have an ID of the referenced object.

It seems that EF just doesn’t leverage proxies like NHibernate does so it needs to have the actual object instance to do things instead of just the proxy.

The good thing however is that when you’re having both a foreign key ID property and an object reference in EF, these are synced automatically and only one column will be generated in the database and the only real issue is a little pollution of your entity.

Object reference not set to an instance of an object

So you’ve created a nice object graph and saved it in the database. Then after fetching the object graph back, some of the referenced objects are null even when the ID’s of the references are nicely sitting there in the database. WTF???

Well, EF doesn’t automatically load a referenced object unless it’s marked as virtual (lazy) or loaded explicitly via Include(). If you forget both, you’ll end up with the NullReferenceExceptions.

No Dictionary collection mapping

This is something not many people complain about, but I really miss the option to map dictionaries like Map in NHibernate. Also, NHibernate’s List mappings are not supported.

Cascade is a big black box

EF doesn’t have a way to specify how changes in your entity are cascaded into related entities. I’m not sure if this is a good or a bad thing. On one hand I miss having control over this, but on the other hand EF seemed to do well without setting anything.

Out of the box, EF code first generates CASCADE  DELETE database constraints on required associations but when your model gets only a little bit complex, you’ll get errors like “Introducing FOREIGN KEY constraint on table may cause cycles or multiple cascade paths”. Fortunately, you can turn this off in your DbContext:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    // Remove cascade delete convention because it causes trouble when generating the DB.
    modelBuilder.Conventions.Remove<OneToManyCascadeDeleteConvention>();

    base.OnModelCreating(modelBuilder);
}

Explicitly set state when attaching objects to the DbContext

In NHibernate you can simply update an object that isn’t associated with a Session via Session.Update(). EF can do the same via Attach() but you must not forget to explicitly set the object state to modified, otherwise no updates occur:

dbContext.Customers.Attach(customer);
dbContext.Entry(customer).State = EntityState.Modified;
dbContext.SaveChanges();

More?

Please leave a comment if you want to share your own experiences.

• 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.

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);
}

A little while ago, I needed something to handle events in a loosely coupled manner due to a plugin-like architecture. Since I’m not the first person on earth who needs this, I went out looking for what’s available in .NET land and ended up with the EventAggregator from Caliburn Micro:

1. Caliburn Micro (EventAggregator)

The nicest thing is that it allows subscribers to handle multiple events by just implementing an interface:

public interface IHandle<TMessage> : IHandle
{
    void Handle(TMessage message);
}  

public class MySubscriber : IHandle<SomeMessage>, IHandle<OtherMessage>
{
    public void Handle(SomeMessage message){
        // do something with the message
    }

    public void Handle(OtherMessage message){
        // do something with the other message
    }
}

Note that you can use ANY object as message. I like that!

Unfortunately, the application I’m working on is an ASP.NET MVC web application where the EventAggregator is more suitable for stateful environments like Silverlight or WPF. For example, I had to make the EventAggregator a Singleton to make sure that subscribers with different lifestyles (per web request, singleton, ASP.NET provider) could be called properly. Another issue was that I couldn’t find a nice way to instantiate all subscribers in the application.

2. FunnelWeb (EventPublisher)

While browsing the Funnelweb source code, I stumbled upon an interesting EventPublisher class, the EventAggregator of Funnelweb. This class takes a constructor dependency on a list of objects that implement IEventListener. So no subscribing here. The advantage of this is that an IoC container can take care of all subscriber creation and you don’t have to worry anymore if all subscribers are instantiated and are subscribed. When an event is published, the EventPublisher just goes through the list of IEventListener subscribers and calls their Handle() method. A small drawback is that the subscribers have to find out if they can handle the published event themselves. All events are published to all subscribers whatever type of event.

3. Mix and Match and add a little sauce

I really like the approach that is  taken in Funnelweb so I’ve taken that as the base for my solution and added the parameterized event listeners of Caliburn Micro.

The event listener interface:

/// <summary>
/// Event listener marker interface (for IoC convenience).
/// </summary>
public interface IEventListener
{}

/// <summary>
/// Event listener interface that is parameterized with the type of the payload (event data)
/// </summary>
/// <typeparam name="TPayload">The type of the event data</typeparam>
public interface IEventListener<in TPayload> : IEventListener where TPayload: class
{
    /// <summary>
    /// Handle the published event with the given payload as event data.
    /// </summary>
    /// <param name="payload">The event data</param>
    void Handle(TPayload payload);
}

An event listener implementation:

public class MyEventListenerClass: IEventListener<Foo>, IEventListener<Bar>
{
    // Snip initialization and other code.

    public void Handle(FooEvent payload)
    {
        // Do things with Foo event data
    }

    public void Handle(BarEvent payload)
    {
        // Do things with Bar event data
    }
}

The event publisher interface:

/// <summary>
/// Publishes events to listeners.
/// </summary>
public interface IEventPublisher
{
    /// <summary>
    /// Publish an event with the given payload. This can be a specifically designed
    /// event class, but this is not required. We just don't allow primitives.
    /// </summary>
    /// <typeparam name="TPayload">The type of the event data</typeparam>
    /// <param name="payload">The event data</param>
    void Publish<TPayload>(TPayload payload) where TPayload : class;
}

The event publisher implementation:

public class EventPublisher : IEventPublisher
{
    private readonly IEnumerable<EventListener> _listeners;

    public EventPublisher(IEnumerable<IEventListener> listeners)
    {
        _listeners = listeners;
    }

    public void Publish<TPayload>(TPayload payload) where TPayload : class
    {
        var handlersForPayload = _listeners.OfType<IEventListener<TPayload>>();
        foreach (var handler in handlersForPayload)
        {
            handler.Handle(payload);
        }
    }
}

By creating a generic Publish<TPayload> method we are able to publish the event only to listeners that implement IEventListener<TPayload> .

4. Use it!

To be honest, you pretty much need an IoC container to use the full power of this EventPublisher, and to be more specific: an IoC container that can inject the IEnumerable<EventListener> parameter in the constructor of the EventPublisher, but I think most modern IoC containers can do that (Castle Windsor, Autofac, StructureMap). In the example below, we’re using Autofac.

Let’s say we have an application service IMyService and a plugin IPlugin, implemented by MyService and MyPlugin. MyService publishes an event with the type of MyEvent and MyPlugin handles that event. IMyService is being used in an ASP.NET MVC controller.

Event, Service and Plugin:

public class MyEvent
{
    public string Message { get; set; }
}

public interface IMyService
{
    void DoSomething();
}

pubic class MyService : IMyService
{
    private IEventPublisher _eventPublisher;

    public MyService(IEventPublisher eventPublisher)
    {
        _eventPublisher = eventPublisher;
    }

    public void DoSomething()
    {
        // Do things
        ...

        // Notify with MyEvent as event data
        _eventPublisher.Publish(new MyEvent { Message = "Something is done" });
    }
}

public interface IPlugin
{
    ...
}

public class MyPlugin : IPlugin, IEventListener<MyEvent>
{
    public void Handle(MyEvent myEvent)
    {
        var publisherMessage = myEvent.Message;
        // Do things with the event data.
        ...
    }
}

Wire things together in the IoC container (Autofac):

var builder = new ContainerBuilder();

// IEventPublisher
builder.RegisterType<EventPublisher>().As<IEventPublisher>().InstancePerLifetimeScope();

// Services. Name has to end with "Service" by convention.
builder.RegisterAssemblyTypes(Assembly.GetExecutingAssembly())
    .Where(t => t.Name.EndsWith("Service"))
    .AsImplementedInterfaces()
    .InstancePerLifetimeScope();

// Plugins. Name has to end with "Plugin" by convention.
foreach (var assembly in pluginAssemblies)
{
    builder.RegisterAssemblyTypes(pluginAssemblies)
        .Where(t => t.Name.EndsWith("Plugin"))
        .AsImplementedInterfaces()
        .SingleInstance();
}

var container = builder.Build();DependencyResolver.SetResolver(new AutofacDependencyResolver(container));

Note that the plugins (our IEventListener) can have a different lifestyle (Singleton) than the IEventPublisher (Instance per HTTP request). This should be fine as long as the IEventListeners live longer or have the same lifestyle  as the IEventPublisher.

Finally the ASP.NET MVC controller:

public class MyController : Controller
{
    private IMyService _myService;

    public MyController(IMyService myService)
    {
        _myService = myService;
    }

    public ActionResult DoSomething()
    {
        // This call will automagically call MyPlugin.Handle
        _myService.DoSomething();
        return View();
    }
}

That’s it! Thank you both Caliburn Micro and Funnelweb! I’m pretty happy with this solution and use it for multiple scenario’s:

• Plugins that need to respond on events of the core system;
• Separation of concerns in Application Services: I often have an Application Service that needs to do a little more than it was originally designed for, for example post-processing of an order. Now I only need to publish an event with the order as data and the appropriate application services pick it up and perform the post-processing;
• Dirty things with custom ASP.NET providers. Just implement one or more IEventListener<T> interfaces and register the provider instance in the IoC container with the interfaces it implements.

Just one thing that worries me a little is the dependency of the EventPublisher to all classes that implement IEventListener<T> . These can potentially grow into a huge list and I don’t know what overhead that creates. I already experimented with a IEnumerable<Lazy<IEventListener>> parameter in the constructor of the EventPublisher so object creation is delayed until the moment we actually publish something and that seems to work fine with Autofac.

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!

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.

I’ve heard these discussions a lot and in most cases, people’s preferences are based on the technology that they are most proficient in and not based on facts. The only fact here is that it’s awkward to leave your comfort zone and learn something that is totally different conceptually (stateful vs. stateless).

So when you ask a developer which presentation technology to choose, you should also weigh his background.

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