Steve Michelotti: Studio for Wijmo MVC Review

I was recently asked to review Studio for Wijmo MVC by Component One and, overall, I am impressed. There are 2 major components of this. The first is Wijmo Complete which is a collection of over 30 UI widgets (very similar to jQuery UI). The second is Wijmo Scaffolding for MVC which builds upon the scaffolding that was released as part of the MVC 3 Tools Update (note: is does not build on top of powershell-based MVC Scaffolding which Microsoft released earlier this year).

Some of the Wijmo widgets have corresponding widgets in jQuery UI – the idea is for them to extend jQuery UI. For example:

In addition to these widgets, Wijmo contains several pretty cool widgets that have some functionality that you don't get out of the box with jQuery UI. For example, the Wijmo Charts are stunning and really enable a rich experience with minimal implementation required.

wijmochart

Also, the Menu widget is very rich and highly customizable.

wijmomenu

The Wijmo Grid is another widget that is extremely impressive and is on par with jqGrid. These rich widgets like the Chart, Menu, Grid, etc. are where Wijmo really shines. Although Wijmo does offer some widgets that are similar to what you can find in other libraries like jQuery UI, the fact that they bundle all of them together and add several widgets that you cannot find in jQuery UI make it quite compelling. Additionally, the Wijmo Documentation is comprehensive as well.

When MVC first came out, many Microsoft control vendors went down the path of trying to create MVC Helpers for complex controls that were for C# centric. This often led to an awkward API that didn't feel right in web development. Fortunately, Component One did not take this path with Wijmo MVC – instead the widgets follow the typical jQuery API so could be used outside the context of MVC. However, they do add some niceties that integrate nicely with some MVC concepts (e.g., Data Annotation metadata on view models) so that if you are using MVC, you get some nice value adds.

Wijmo Scaffolding for MVC

The Wijmo Scaffolding is a nice feature for quickly getting up and running with Wijmo controls but there were a couple of aspects that fell a little short of my expectations overall. When I first heard about Wijmo Scaffolding I was initially very excited because I thought it was integrated with PowelShell-based MVC Scaffolding. However, that is not the case. Specifically, Wijmo Scaffolding comes with some replacement T4 templates for the templates that work with the MVC 3 Tools Update scaffolding dialog (i.e., the new "Add Controller" dialog). The differences between the Wijmo templates and the default templates are not earth shattering. The primary differences are:

Wijmo adds additional CSS styles to support the Wijmo styles
Wijmo templates work with the 3 Editor Templates that ship with Wijmo Scaffolding
Wijmo templates do not take into account one-to-many relationships

Let's take an example walkthrough for building something with Wijmo Scaffolding. Consider view models that look like this:

public class Task
{
    public int Id { get; set; }
 
    [Required]
    public string Name { get; set; }
 
    [DisplayName("Due Date")]
    [DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = "{0:d}")]
    public DateTime? DueDate { get; set; }
 
    public int StatusId { get; set; }
    public virtual Status Status { get; set; }
 
    [StringLength(100)]
    public string Notes { get; set; }
}
 
public class Status
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Notice there is a typical one-to-many relationship between Status and Task. After going through the standard "Add Controller" dialog box with Wijmo scaffolding, the resulting "Create" screen looks like this:

wijmoCreate

I've got nice looking styles and the date field conveniently gets the Wijmo Input Date widget. However, the foreign key to StatusId is not taken into account automatically as it would be with traditional MVC Scaffolding. This would be a great enhancement for Component One to make.

After adding a few items, the List view, which gets scaffolded using the Wijmo grid widget, looks like this:

wijmoGrid

There's automatic sorting/paging and the styles look nice as well (though we have the same pesky problem with the foreign key on StatusId). However, when I sorted by the "Name" column, although the alphabetical sort worked great, the visual styles were lost:

wijmoGrid

This may be just a minor bug but I did not dig into trying to debug it.

Wijmo MVC comes with 3 Editor templates:

DateTime – which uses the Wijmo Input Date widget
Decimal – which uses the Wijmo Input Number widget based on Data Annotations [Range] attribute
IntSlider – which uses the Wijmo Int Slider widget also taking into account the Data Annotations [Range] attributes. Note: since this editor is not named for the Integer data type, it is meant to be used by invoking a [UIHint].

These editor templates all do the intended job nicely. However, as a small nitpick, I'd probably choose to change the implementation slightly. The DateTime editor looks like this:

@inherits System.Web.Mvc.WebViewPage<System.DateTime?>
@if (Model.HasValue)
{
    @Html.TextBox("", (Model.Value), new { @class = "datePicker" })
}
else {
    @Html.TextBox("", "", new { @class = "datePicker" })

}
<script type='text/javascript'>
    $(document).ready(function () {
        $("#@ViewData.TemplateInfo.GetFullHtmlFieldId("")").wijinputdate({ showTrigger: true});
    });
</script>

Since the wijinputdate() widget is applied directly the the element itself (as seen on line #12), it means that you'll have a snippet of jQuery like this interspersed throughout your markup for every DateTime on your page:

<script type='text/javascript'>
    $(document).ready(function () {
        $("#DueDate").wijinputdate({ showTrigger: true});
    });
</script>

My preference is that they take a more "unobtrusive" approach. For example, since they are already adding a class="datePicker" to the text box, all we'd need to do is to add 1 line of jQuery to the page that would take care of all of these like this:

<script type="text/javascript">
    $(function () {
        $(".datePicker").wijinputdate({ showTrigger: true });
    });
</script>

So rather than having multiple jQuery calls through the page for this – it's just one (i.e., any element with a class of "datePicker"). This would also make the payload sent to the browser smaller as well. But again, this is a small nitpick.

Conclusion

Overall, I was very impressed with Wijmo MVC and I think it is a compelling option for any developer building rich MVC applications. Although the widgets can be used for any jQuery solution, the integration with MVC is a nicety that makes things more seamless. In my opinion, the sweet spot for Wijmo are the incredibly rich widgets such as the charts, graphs, menus, and grids. My constructive suggestions are that I'd like to see Component One extend the scaffolding support by supporting the integration with the Powershell-based MVC Scaffolding. At the same time, it would not be difficult to add support for foreign keys of one-to-many relationships – this would also enable Repository support that MVC Scaffolding provides as well. Overall, if you're looking for a cohesive suite of UI widgets for your MVC application, I'd definitely recommend checking out Studio for Wijmo MVC.