Nuri Halperin

Between - Extension method to shorten notation

Nuri Halperin — Sat, 17 Oct 2009 05:49:00 GMT

Sometimes I just write code. And sometimes I clean up my code. Most of the times, I focus on the meat of the methods, hacking away at verbose or lengthy flows, re-factoring out common code, trying to untangle overly complex logic etc.

Recently, I noticed that many of the conditional terms I write span very long lines and are a bit cumbersome to read. The reason for that is that many of the variable names are long, or the properties or both and that often the comparison is on a property of an object or member of a collection etc.

So for instance:

if (summerCatalog.Products[0].ProductCategories[0].ParentCategoryID >= 1 && summerCatalog.Products[0].ProductCategories[0].ParentCategoryID <= 4)
{ 
//...
}

Can become quite long.
Long is not easy to read.
Long is not easy to maintain.
Long is not easy to think through.

What I really wanted to say is if [value] is between [a] and [b].

Of course, one could say "lets just make the variable names shorter". But that flies in the face of self explanatory plain naming. So abbreviating for the sake of short-lineliness (New word! You heard it her first!) is out.

Well, this is just screaming "EXTENSION METHODS" doesn't it?

Here we go then:

/// <summary>
/// Returns whether the value is between the 2 specified boundaries.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="value">The value to compare</param>
/// <param name="minValueInclusive">The min value (inclusive).</param>
/// <param name="maxValueInclusive">The max value (inclusive).</param>
/// <returns>True if the value is equal to or between the boundaries; False otherwise.</returns>
public static bool Between<T>(this T value, T minValueInclusive, T maxValueInclusive) where T : IComparable<T>
{
    if (minValueInclusive.CompareTo(maxValueInclusive) > 0)
    {
        throw new ArgumentException("minimum value must not be greater than maximum value");
    }
    return (value.CompareTo(minValueInclusive) >= 0 && value.CompareTo(maxValueInclusive) <= 0);
}

The Between function takes any object which supports IComparable<T> and performs syntactic sugar comparison with the inclusive min and max values.
What's more, it adds a basic sanity check for the comparison. How many times do I do that sanity check in my normal code (!)?

Now the conditional is

if (summerCatalog.Products[0].ProductCategories[0].ParentCategoryID.Between(1, 4)) 
{
///...
}

At least I don't have to refactor this in my brain while reading.

Sure, you might say, but you could have just de-referenced the deep value and then have a shorter conditional, like so:

Category category = summerCatalog.Products[0].ProductCategories[0];
if (category.ParentCategoryID >= 1 && category.ParentCategoryID <= 4)
{
    //...
}

Yes - of course - but it adds a line of code, places the burden of reading the very common idiom ( x >= a && x <= b) on me, and I constantly stumble on the lest-than-or-equal vs. less-than and it doesn't check for my boundaries being inadvertently swapped.

So there you have it. A simple extension cuts down your lines of code, makes long text shorter and saves lives. Which begs the question: is this already part of the language - and should it be?

Unit Testing and approval tests

Nuri Halperin — Sat, 08 Aug 2009 06:13:19 GMT

It's been years now that unit testing frameworks and tools have grabbed our attention, made their way into our favorite IDE and sparked yet another wave of seemingly endless "my framework is better than yours" wars. And then there are the principal wars of whether TDD is better than Test After Development. And most excitingly the automated testing tools etc. Oh, and let's not forget mocks! So we have all the tools we need – right? Well, kind of, no.

I recently attended a talk by Llewellyn Falco and Woody Zuill the other day, and they used a little library called Approval Tests (http://approvaltests.com/). I immediately fell in love with the concept and the price ($0). Llewellyn is one of the two developers of the product, hosted on http://sourceforge.net/projects/approvaltests/.

What does it do that years of frameworks don't?

For me, a major nuisance is that you have a piece of code, and that piece of code produces a result (object, state – call it what you will). That result is commonly named "actual" in Visual Studio unit tests. The developer must then assert against that result to ensure that the code ran properly. In theory, unit tests are supposed to be small and only test one thing. In reality, functions which return complex objects rarely can be asserted with one assert. You'd typically find yourself asserting several properties or testing some behavior of the actual value. In corporate scenario, the unit tests might morph into some degree of integration tests and objects become more complex, requiring a slew of assert.this and assert.that().

What if you could just run the code, inspect the value returned, and – if it satisfies the requirements – set "that value" to be the comparison for all future runs? Wouldn't that be nice? Good news: Approval Tests does just that. So now, instead of writing so many asserts against your returned value, you just call ApprovalTests.Approve() and the captured state is compared against your current runtime. Neat huh?

But wait, there's more! What if your requirements are regarding a windows form, or a control? how do you write a unit test that asserts against a form? The answer is simple and genius: Capture the form as an image, and compare the image produced by your approved form (after you have carefully compared it to the form given to you by marketing – right?) and compare it to each subsequent run. ApprovalTests simply does a byte by byte comparison of the resultant picture of the form and tells you if it matches what you approved.

Let's break down the steps for installation:

Add a reference to the ApprovalTests.dll assembly.

Yeah,it's that simple.

Ok. Let's break down the steps for adding an approval to your unit test

Write your unit test (arrange, act – no asserts) as usual.
Add a call to Approve()

Yeah, it's that simple.

How do you tell it that the value received is "the right one"? Upon first run, the Approve() call will always fail. Why? Because it has no stored approved value to compare the actual it received against. When it fails, it will print out a message (console or test report – depends on your unit test runner). That message will contain a path for the file that it received, complaining about a lack of approved file. The value captured from that run (and any subsequent run) is stored in a file named something like "{your unit test file path}\{your method}.received.xyz". If you like the result of the run -the image matches what the form should look like, or the text value is what your object should contain etc – then you can rename it to "{your unit test file path}\{your method}.approved.xyz". You should check the approved file into your source control. After all, it's content constitutes the basis of the assertion in your unit test!

Consider the very simple unit test code:

        1: [Test]

       2:         public void DateTime_Constructor_YMDSetDate()

       3:         {

       4:             DateTime actual;

       5:             actual = new DateTime(2038, 4, 1);

       6:             Approvals.Approve(actual.ToString());

       7:         }

The function under test here is the constructor for System.DateTime which takes 3 parameters – month day and year. Upon first run, the test will fail with a message resembling

"TestCase 'MyProject.Tests.DateTimeTest.DateTime_Constructor_YMDSetDate'
failed: ApprovalTests.Core.Exceptions.ApprovalMissingException : Failed Approval: Approval File "C:\….\MyProject\DateTimeTest.DateTime_Constructor_YMDSetDate.approved.txt" Not Found."

That's because this file was never created – it's your first run. Using the standard approver, this file will actually now be created but will be empty. In that same directory you will find a file named {…}.received.txt. This is the capture from this run. You can open the received value file, and inspect the text to ensure that the value returned matches your expected value. If it does, simply rename that file to .approved.text or copy it's content over and run the test again. This time, the Approve() method should succeed. If at any point in the future the method under test returns a different value, the approval will fail. If at any point in the future the specs change, you will need to re-capture a correct behavior and save it.

How do you easily compare the values from the last run and the saved approved value? The approved file is going to be a text file for string approvals, and an image file for WinForm approvals. As it turns out, you can instruct Approval Tests to launch a diff program with the 2 files (received, approved) automatically upon failure, or just open the received file upon failure or silently just fail the unit test. To control that behavior, you use a special attribute

       1: [TestFixture]

       2: [UseReporter(typeof(DiffReporter))]

       3: public class ObjectWriterTest

       4: {

The UserReporterAttribute allows you to specify one of 3 included reporters

DiffReporter – which opens tortoisediff for diffing the received and approved files if the comparison fails.
OpenReceivedFileReporter – which launches the received file using the application registered to it's extension on your system if the comparison fails.
QuietReporter – which does not launch any program but only fails the unit test if the comparison fails.

When your have a CI server and run unit tests as part of your builds, you probably want to use the quiet reporter. For interactive sessions, one of the first 2 will probably be more suitable.

How are value comparisons performed? Under the standard built in methods, a file is written out and compared to byte by byte. If you wish to modify this or any behavior, you can implement your own approver or file writer or reporter by implementing simple interfaces. I ended up adding a general use object writer so that I can approve arbitrary objects. The effort was fairly painless and straightforward.

I did have to read the code to get the concept. If only my time machine worked: I could have read my own blog and saved myself 20 minutes. Yeah, right.

The project has some bells and whistles – plug ins for a few IDE's and there's a version for Java and Ruby. I have not reviewed these versions.

There you have it folks- a shiny new tool under your belt. I can see this saving my hours of mindless typing of Assert.* calls and I can go home early. Yeah, right.

MVC Radio Button List

Nuri Halperin — Thu, 06 Aug 2009 00:29:29 GMT

As predicted, I came around to using some radio buttons. As you might guess by now, I didn't like the HTML or the implementation in the current MVC release. As you may expect, I wrote my own :-)

The implementation is fairly simple and straightforward. It extends System.Web.MVC.ViewPage, takes a list of objects, allows for selection of one of the radio buttons, supports orientation and supports selection of both the value the radio button submits and the display string for that item independently.

        1: using System;

       2: using System.Collections.Generic;

       3: using System.Linq.Expressions;

       4: using System.Web.Mvc;

       5: using System.Web.UI;

       6:  

       7: public static partial class HtmlHelpers

       8: {

       9:     public static void ShowRadioButtonList<T>(this ViewPage page, IList<T> list, string name, Expression<Func<T, object>> valueProperty, Expression<Func<T, object>> displayProperty, System.Web.UI.WebControls.Orientation orientation)

    {

        page.ShowRadioButtonList(list, name, valueProperty, displayProperty, "3", orientation);

    }

  

  

    public static void ShowRadioButtonList<T>(this ViewPage page, IList<T> list, string name, Expression<Func<T, object>> valueProperty, Expression<Func<T, object>> displayProperty, string selectedValue, System.Web.UI.WebControls.Orientation orientation)

    {

        HtmlTextWriter writer = new HtmlTextWriter(page.Response.Output);

        if (writer != null)

        {

            Func<T, object> valueGetter = valueProperty.Compile();

            Func<T, object> displayStringGetter = displayProperty.Compile();

  

            for (int i = 0; i < list.Count; i++)

            {

                T row = list[i];

                string value = valueGetter(row).ToString();

                writer.AddAttribute(HtmlTextWriterAttribute.Type, "radio");

                writer.AddAttribute(HtmlTextWriterAttribute.Id, name + "_" + i);

                writer.AddAttribute(HtmlTextWriterAttribute.Name, name, true);

                writer.AddAttribute(HtmlTextWriterAttribute.Value, value, true);

                if (value == selectedValue)

                {

                    writer.AddAttribute(HtmlTextWriterAttribute.Checked,"checked");

                }

                writer.RenderBeginTag(HtmlTextWriterTag.Input);

                writer.Write(displayStringGetter(row));

                writer.RenderEndTag();

  

                if (orientation == System.Web.UI.WebControls.Orientation.Vertical)

                {

                    writer.RenderBeginTag(HtmlTextWriterTag.Br);

                    writer.RenderEndTag();

                }

            }

        }

    }

}

This implementation uses the type Expression<Func<T,Object>> for the selection of the value and the display string. To invoke the helper, assuming you have a list of Product objects, Product being defined:

       1: public class Product

       2: {

       3:     public int ProductID { get; set; }

       4:     public string Title { get; set; }

       5:     public string Description { get; set; }

       6:     public decimal Price { get; set; }

       7: }

You can now call the helper from your MVC View Page strongly typed with a model List<Product>:

       1: <%@ Page Title="" Language="C#" Inherits="System.Web.Mvc.ViewPage<List<Product>>"

       2:     MasterPageFile="~/Views/Shared/Site.Master" %>

       3:

invoked simply

       1: <% this.ShowRadioButtonList<Product>(Model, 

       2:                             "productRadioButtonList", 

       3:                             a => a.ProductID, 

       4:                             d => d.Title, "4", 

       5:                             Orientation.Horizontal); %>

This call will create a radio button for each product in the list (Model is a List<Product> because we strongly typed the page as such). The radio button will use the ProductID property for the value of the input, and the Title property as the displayed string. If one of the product Id's happens to be 4, that radio button will be selected in the group. The radio buttons will all be named "productRadioButtonList" but their ID will be appended an ordinal number "productRadioButtonList_1","productRadioButtonList_2","productRadioButtonList_3" etc.

There you have it: another day, another MVC control, another blog post.

MVC paged list

Nuri Halperin — Wed, 05 Aug 2009 19:16:34 GMT

The need

As certain as the sun rising tomorrow, there will come the point where you will want to display a list or grid with paging. While many solutions exist, and many component developers are coming in with robust solutions, a simple and satisfactory solution can be created fairly easily.

Implementation

Why create a pager from scratch? Several reasons:

1) You want to control the pager completely – display, style and all.

2) You don't like the idea of JavaScript paging, which will load your hundreds of pages to the browser and do client side paging / grid

3) You want to understand and control exactly how a page subset of record is fetched and take control of database or IO thrashing

Of the quickly surveyed solutions out there, I found this one simple and straightforward. Being small, straightforward and simple means also easy to maintain, extend or modify. Based on that solution, I've created my own pager which breaks into 2 class implementations and one usage guidance.

The first class, is the PagedList class. The whole class is rather small and the only crux is doing correct math and ensuring the logic handles zero items returned. This class is responsible for taking a source list of all items (more on that below in the performance considerations) and presenting simple properties for HasNextPage, HasPreviousPage, TotalPages and CurrentPage. The implementation inherits from the generic List<T>, and so exposes and enumerator and the Count property. The constructor copies only the current page's worth of items into the instance though, so Count will return the number of items on the current page (0 to page size) therefore an additional property TotalItems is populated upon construction which exposes the total number of items in the underlying source.

using System;
using System.Collections.Generic;
using System.Linq;

namespace BL.Models
{

    /// <summary>
    /// Adapted from http://blog.wekeroad.com/2007/12/10/aspnet-mvc-pagedlistt/
    /// </summary>
    /// <typeparam name="T">The type of item this list holds</typeparam>
    public class PagedList<T> : List<T>, IPagedList
    {
        /// <summary>
        /// Initializes a new instance of the <see cref="PagedList&lt;T&gt;"/> class.
        /// </summary>
        /// <param name="source">The source list of elements containing all elements to be paged over.</param>
        /// <param name="currentPage">The current page number (1 based).</param>
        /// <param name="pageSize">Size of a page (number of items per page).</param>
        public PagedList(IEnumerable<T> source, int currentPage, int itemsPerPage)
        {
            this.TotalItems = source.Count();
            this.ItemsPerPage = itemsPerPage;
            this.CurrentPage = Math.Min(Math.Max(1, currentPage), TotalPages);
            this.AddRange(source.Skip((this.CurrentPage - 1) * itemsPerPage).Take(itemsPerPage).ToList());
        }


        public int CurrentPage {get ;private set;}

        public int ItemsPerPage { get; private set; }

        public bool HasPreviousPage { get { return (CurrentPage > 1); } }

        public bool HasNextPage { get { return (CurrentPage * ItemsPerPage) < TotalItems; } }

        public int TotalPages { get { return (int)Math.Ceiling((double)TotalItems / ItemsPerPage); } }

        public int TotalItems { get; private set; }
    }
}

PagedList implements the interface IPagedList, since a static class can not be generic, and the control renderer will need access to the PagedList's properties:

       1: using System;

       2:  

       3: namespace BL.Models

       4: {

       5:     public interface IPagedList

       6:     {

       7:         int CurrentPage { get; }

       8:         bool HasNextPage { get; }

       9:         bool HasPreviousPage { get; }

      10:         int ItemsPerPage { get; }

      11:         int TotalItems { get; }

      12:         int TotalPages { get; }

      13:     }

      14: }

The second class is more like a custom web control. Since this is MVC, we are driven to use a helper like implementation. My approach to developing HTML helpers for MVC is to create an extension method on the System.Web.MVC.ViewPage type. This allows the use of the well known and tested HtmlTextWriter to render the actual HTML rather than creating angled brackets in strings on the fly. I find this approach both more true to the form – rendering output to the output stream and not composing a string to be copied later – and safe: using compliant well tested constants and constructs rather than typing in HTML and hoping your syntax and understanding of the tag is correct.

using System.Web.Mvc;
using System.Web.UI;

public static partial class HtmlHelpers
{
    /// <summary>
    /// Shows a pager control - Creates a list of links that jump to each page
    /// </summary>
    /// <param name="page">The ViewPage instance this method executes on.</param>
    /// <param name="pagedList">A PagedList instance containing the data for the paged control</param>
    /// <param name="controllerName">Name of the controller.</param>
    /// <param name="actionName">Name of the action on the controller.</param>
    public static void ShowPagerControl(this ViewPage page, IPagedList pagedList, string controllerName, string actionName)
    {
        HtmlTextWriter writer = new HtmlTextWriter(page.Response.Output);
        if (writer != null)
        {
            for (int pageNum = 1; pageNum <= pagedList.TotalPages; pageNum++)
            {
                if (pageNum != pagedList.CurrentPage)
                {
                    writer.AddAttribute(HtmlTextWriterAttribute.Href, "/" + controllerName + "/" + actionName + "/" + pageNum);
                    writer.AddAttribute(HtmlTextWriterAttribute.Alt, "Page " + pageNum);
                    writer.RenderBeginTag(HtmlTextWriterTag.A);
                }

                writer.AddAttribute(HtmlTextWriterAttribute.Class,
                                    pageNum == pagedList.CurrentPage ?
                                                        "pageLinkCurrent" :
                                                        "pageLink");

                writer.RenderBeginTag(HtmlTextWriterTag.Span);
                writer.Write(pageNum);
                writer.RenderEndTag();

                if (pageNum != pagedList.CurrentPage)
                {
                    writer.RenderEndTag();
                }
                writer.Write("&nbsp;");
            }

            writer.Write("(");
            writer.Write(pagedList.TotalItems);
            writer.Write(" items in all)");
        }
    }
}

The implementation creates a list of page numbers, with a link on each except for the current page. The link will be of the format "/{controller name}/{action name}/{page number}".

I have added conditional style attribute to the link so that you can style the current page differently from the other pages easily. Since you have the code, you can extend the resultant HTML as you wish. You might want to have text indication of "no more pages" or some indication if the list is empty etc.

Finally, you would want to make use of this shiny new widget. The steps are as follows

1) In your controller, create an action which takes the page number as it's sole parameter. The action would then create a new instance of the PagedList, passing it the "full list" and the current page number from the parameter.

    public ActionResult Page(int id)

            {

                List<Product> products = CatalogService.ListOpenProducts();

                PagedList<Product> data = new PagedList<Product>(products, id, PAGE_SIZE);

                return View(data);

            }

2) Change / create a view which takes the PagedList<your row type> as it's model.

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" 
Inherits="System.Web.Mvc.ViewPage<BL.Models.PagedList<Product>>" %>

3) Place a call to the extension method to display the pager anywhere in your view (multiple placement allowed – you can put one on top and one on the bottom etc). Recall that the method ShowPagerControl() extends ViewPage, so the keyword this should show your intellisence for the method. If you chose a more complex model (MVVM ViewModel containing more data than just the paged list) then you would use Model.{paged list property name}. The use of the view as a bag of random data conjured up by string names should IMHO be universally abandoned and eliminated.

<% this.ShowPagerControl(Model, "Bids", "Page"); %>

Considerations

Take != load all + scroll

The PagedList implementation takes an IEnumerable<T> as it's source data. Internally, it uses Linq syntax which would seem to require all items be loaded, and then skip the first N pages and take the next {page size} worth of items. If your underlying list of items is a huge DB call, you will find that troubling. What you might consider then will be to use deferred loading. Extend the Linq IQueryable<T> or ObjectQuery<T> and let the ORM of your choice do the paging in the database. If your ORM is eager loader, you will need to implement custom partial record loading and paging at the data source level. If it can defer loading you will be in better shape.

Conversely, you might want to actually eager-load all records at the first shot. This will provide you with 2 benefits: cachability and coherency. Loading all items into memory incurs one DB call overhead and the IO required for all records. If you load each page at a time, you would incur {page count} * page clicks DB call overheads which might exceed the former if users scroll often back and forth. Once you load the whole list, you can cache it in memory and expire it based on data change events. If you have the base list in memory, access to it incurs no more IO regardless of pager clicks. Another phenomena caching gets around is coherency problems. If you page ad the DB level and an item is inserted or deleted, the end user experiences skips or stutter items. A skip is when a user clicks from page 1 to 2 an item which was to be on page 2 now is in the range of page 1 because an item on page 1 was deleted. Going to page 2 skips this item, and paging back should reveal it but would be surprising to the user (because she just came from page 1 and it wasn't there before) creating the appearnace of a skipped / missed item. A stutter is the reverse situation: user clicks from page 1 to 2, and an item from page 1 appears again on page 2. This happens when an item was added and "pushed" the repeat item into page 2 because of it's sorting order. This appears to the user as a malfunction and may infuriate some enough to call customer service (alas, advising customers to adjust their medication does not actually calm them down). A solution to coherence is to cache the result list for each user, expiring the cache actively when navigating away or running a different query.

Conclusion

The code above and variations of it are fairly easy to create. If your favorite web control vendor has not solved this for you, if you want to take full control of your paging of if you are just naturally curious – it's a great way to add paging to your MVC application.

MVC + ASP.Net template control and user control

Nuri Halperin — Sat, 25 Jul 2009 02:37:00 GMT

Seeing that I can use a DataBoundControl such as DataList, and binding it to a source control is achievable – what next?

Data bound controls contain various templates. The usual suspects are the item template and alternating template (for a repeating object, with possible varied style), the header and the footer templates (for enclosing HTML pre/post wrap or header / footer effects).

Under MVC, all events are out the window. So we're not concerned at all with event hookup. We might want to provide the various "modes" of display (Edit, Create, Delete etc) which align well with CRUD command structure and may map to MVC quite naturally. But for starters, my project's requirements simply required styling of the repeating item to be easily controlled.

So rather than inline HTML in the <ItemTemplate> tag, I wanted to use a user control (ASCX). This allows my to style the item once and re-use it in pop-ups or other areas of the site, not just the data list view.

The question becomes then – how do I pass data "down" to the user control? The answer turned out to be to easy – you don't have to do anything! That's right, the containing DataList gets bound to data. The user control then can pluck fields from the "data row" (each item in the bound list of the parent) by using the syntax Eval("{some property}")

So the steps are:

Create your user control (MiniItem.ascx)
Register the user control in the hosting ASPX page
Include the user control in the item template of your data bound control

The user control is an .ascx file, but change it to just inherit from System.Web.UI.UserControl. This is MVC so code behind is left behind..

<%@ Control Language="C#" Inherits="System.Web.UI.UserControl" %>
<fieldset>
    <legend>Oh Goodie!</legend>
    <p>
        Product ID:
        <%#Eval("ProductID") %>
    </p>
    <p>
        Title:
        <%#Eval("Title") %>
    </p>
    <img src='/Content/ProductImages/<%#Eval("ImagePath") %>' alt='Image Path' />
    <p>
        Description:
        <%#Eval("Description") %>
    </p>
</fieldset>

Your host ASPX file will need to register your control type in order to use it, so up at the top you place:

<%@ Register Src="MiniItem.ascx" TagName="MiniItem" TagPrefix="uc1" %>

Now you can use the user control simply by adding it to the ItemTemplate tag:

<asp:DataList runat="server" ID="dataList" RepeatColumns="4" RepeatDirection="Horizontal">
    <ItemTemplate>
        <uc1:MiniItem ID="MiniItem1" runat="server" />
    </ItemTemplate>
</asp:DataList>

There you have it. You can use the good concepts of ASPX and the controls and visual components you are familiar with. While HTML helpers and fluent interface libraries are popping up, some find it more convenient and easy to use the "old" familiar ASPX controls. There are some good reasons to learn new things and try new framework or software paradigms. However, we can also leverage many of the successful declarative features of ASPX as a templating engine to achieve rapid development and modular UI.

MVC, helpers and classic ASP.NET data bound controls – Better Together

Nuri Halperin — Wed, 08 Jul 2009 01:14:00 GMT

Technorati Tags: MVC,ASP.NET,Extension Methods,Html Helper

A lot of hype around MVC these days. So, of course, yours truly is working on some project utilizing MVC. While brushing the dust off my raw HTML tag memory and designing the obvious: lists, grids, repeated item displays and the such, I thought "why not use the asp.net controls instead?"

For one, most of the ASP.NET data bound controls have a rich site of event post backs to hook up. MVC says: no dice! You can't rely on the event dispatch loop of asp.net. In fact, this is the whole point of going MVC – to create a simple, well separated delineation between the presentation and the BL. If you have all these states and post back logic pieces all in the code behind you really have a tightly coupled application.

What *is* available though, is the rendering of most controls. So instead of "for each" and "if" statements sprinkled in the "presentation" template, you can actually just use the plain old asp.net controls declaratively. I put "presentation" in quotation marks because the more code (branching is code!) you have in the View, the more brittle it becomes, the more tightly coupled to BL it is and the less testable it is.

The main advantages I find in using the old controls is that:

Familiarity – My developers know them already
Rich – Theming, localization behavior and layout aspects built in and available
Well tested – These controls have been around a while, and are generally well behaved
Modular – The controls isolate the presentation of a particular element and divorce it from the surrounding. In particular, it avoids issues of nesting and other inline logic in the presentation layer.

The main issue to overcome in a DataBoundControl is that with no code behind, how do you specify the data source declaratively? How do you do so with minimum code and maximum flexibility?

One solution is to use a data source object. Yes, they work. In most scenarios you can use them as you did before, but you must note that hooking up events (OnSelecting, OnSelected and the such) would again be challenging to do declaratively.

My approach for my project was to create an extension method for

DataBoundControl has a property "DataSource", to which you assign an object that will be data bound. The most permissive base object System.Object, so we simply create an extension method:

using System.Web.UI.WebControls;

public static class DataboundControlExtensions
{
    /// <summary>
    /// Extends <typeparamref name="System.Object"/> to bind it to a <typeparamref name="System.Web.UI.WebControls.DataList"/>
    /// </summary>
    /// <param name="data">The data source object to bind.</param>
    /// <param name="control">The control to bind the data source object to.</param>
    public static void BindTo(this object data, DataList control)
    {
        control.DataSource = data;
        control.DataBind();
    }

    /// <summary>
    /// Extends <typeparamref name="System.Object"/> to bind it to a <typeparamref name="System.Web.UI.WebControls.ListView"/>
    /// </summary>
    /// <param name="data">The data source object to bind.</param>
    /// <param name="control">The control to bind the data source object to.</param>
    public static void BindTo(this object data, ListView control)
    {
        control.DataSource = data;
        control.DataBind();
    }
}

Note that the control is passed in as the target and is strongly typed. As it turns out, you get a runtime error if you attempt to specify the control parameter typed as DataBoundControl – the base class for all data bound controls. In other words, this doesn't work:

public static void BindTo(this object data, DataBoundControl control) // Runtime error!

With the extension included in my project, I can now add the control and bind it in one code line:

<% Model.BindTo(dataList); %>
<asp:DataList runat="server" ID="dataList" RepeatColumns="2" RepeatDirection="Horizontal">
    <ItemTemplate>
        <fieldset>
            <legend>
                <%# Eval("ID")%></legend>
            <p>
                Title:
                <%#Eval("Title") %>
            </p>
            <a href='<%#Eval("ImagePath") %>'>
                <img src='<%#Eval("ThumbPath") %>'  height="64" width="48" alt="pic"/></a>
            <p>
                Description:
                <%#Eval("Description") %>
            </p>
        </fieldset>
    </ItemTemplate>
</asp:DataList>

This is not as clean as completely declarative binding, but is much cleaner than having loop and branch constructs all over your view.

Most of you would note that the current MVC release includes HTML helpers. The Futures release is promising several more HTML helpers, which would provide with single line calls that would render lists, and other data bound presentation we are accustomed to. The reasons I didn't use the futures HTML helper methods are:

The futures were not in release yet at time
I don't love the mode in which the HTML helpers work
The HTML helpers are not as rich as the asp.net components

The reason I don't love the HTML helpers is simple: they are string valued functions. As string valued functions, they must, internally generate strings and throw away memory. Even when you use StringBuilder, the repetitive appendage of strings creates discarded buffers in the underlying byte array. Asp.Net controls, on the other hand, have access to the underlying output stream via a TextWriter. This means that the appended string snippets do not create intermediary buffers but rather get copied more efficiently to the actual byte stream that would be shipped to the browser.

So if I need to add an HTML helper to MVC what I do is write an extension method that extends System.Web.MVC.ViewPage, like so

using System.Web.Mvc;
using System.Web.UI;

public static class HelloKittyHelper
{
    public static void Meow(this ViewPage page, string text)
    {
        HtmlTextWriter writer = new HtmlTextWriter(page.Response.Output);
        if (writer != null)
        {
            writer.RenderBeginTag(HtmlTextWriterTag.Pre);
            writer.Write(KITTY_ASCII);
            writer.Write(text);
            writer.RenderEndTag();
        }
    }
    /// <summary>
    /// ASCII art of a kitty - source unknown.
    /// </summary>
        private const string KITTY_ASCII = @"
  .-. __ _ .-.
  |  `  / \  |
  /     '.()--\
 |         '._/
_| O   _   O |_
=\    '-'    /=
  '-._____.-'
  /`/\___/\`\
 /\/o     o\/\
(_|         |_)
  |____,____|
  (____|____)
";
}

Then pass it the data from the Model or anything you like from the view:

<%   1:  this.Meow("purrr.. meow");  
%>

With the ambient objects in the page, I just extend "this", and internally utilize the HtmlTextWriter to write directly to the stream – no intermediary StringBuilder and hopefully less wasted immutable objects. The other advantage is that HtmlTextWriter can do things like begin/end tag tracking, add attributes and encode HTML as necessary. Leveraging existing well tested framework again, reducing costs of testing and education to deliver value early and often.

In conclusion, we can use the new MVC concepts and remain true to the separation of view and logic by leveraging existing components and developing minimal custom extensions that help us avoid the pitfalls of "presentation logic".

Localize your MVC with ease.

Nuri Halperin — Mon, 08 Jun 2009 03:08:29 GMT

MVC seems all the rage these days. And while there are many good things it brings to the table, it seams it takes us a step back in terms of I18N.

For instance, if you want to use the special aspx attribute meta:resourceKey="foo", you won't always be able to do so.

The following would work fine:

   1: <asp:Label runat="server" ID="_QueryPrompt" Text="Enter Query" meta:resourcekey="_QueryPrompt" />&nbsp;

But we're out of luck with buttons:

   1: <asp:Button runat="server" ID="btn" Text="Run" meta:resourcekey="_SubmitQuery" />

At runtime, you will get an exception explaining you need a FORM with a runat="Server". Ugh.

After some spelunking I came across this discussion, which basically suggests creating an extension to the System.Web.Mvc.HtmlHelper class. The discussion is thick with issues, specifically that if a UserControl is used, finding it's path in order to get to it's local resource requires all manners of digging around compilation and application with fairly extensive branching and parsing. Ultimately, the extension is complicated by attempting to combine both a resource retrieval, fallback to global from local resource and formatted template substitution in one. A good helper – if the kinks are worked out.

So I wrote my own syntactic sugar to do the same:

       1: public static string Localize(this System.Web.UI.UserControl control, string resourceKey, params object[] args)

       2: {

       3:     string resource = (HttpContext.GetLocalResourceObject(control.AppRelativeVirtualPath, resourceKey) ?? string.Empty).ToString();

       4:     return mergeTokens(resource, args);

       5: }

       6:  

       7: public static string Localize(this System.Web.UI.Page page, string resourceKey, params object[] args)

       8: {

       9:     string resource = (HttpContext.GetLocalResourceObject(page.AppRelativeVirtualPath, resourceKey) ?? string.Empty).ToString();

      10:     return mergeTokens(resource, args);

      11: }

      12:  

      13: private static string mergeTokens(string resource, object[] args)

      14: {

      15:     if (resource != null && args != null && args.Length > 0)

      16:     {

      17:         return string.Format(resource, args);

      18:     }

      19:     else

      20:     {

      21:         return resource;

      22:     }

      23: }

It is substantially shorter and defers to a base class. System.Web.MVC.ViewUserControl inherits from System.Web.UI.UserControl, so the call is true to it's application. I also extend System.Web.UI.Page.

Lastly, there is the issue of a global resource. Since these resources are compiled and accessed at design time using dot notation (MyGlobalRes.MyKey) I felt that providing an extra function would not significantly shorten code or simplify developer's life. That is, given a resx file in the App_GlobalResources containing the file Zones.resx, containing a key Zone1 one would simply write out

   1: <%= Resources.Zones.Zone1 %>

or – if your resource is a template requiring tokens to be merged:

   1: <%= String.Format(Resources.Zones.Zone1,"foo",11) %>

Happy MVC Internationalization, localization and globalization!

Save The Date: time_t 1234567890

Nuri Halperin — Thu, 12 Feb 2009 16:25:47 GMT

You know you are a geek when things like this seem of any importance.
It may comfort you to know that there are others who are excited about the buzz. It may disturb you. Make of it what you will:

On Friday, February 13th 23:31:30 UTC 2009 the time_t structure would contain the the number 1234567890
The time_t is measures seconds past midnight of January 1 1970 (see Unix Epoc, POSIX time etc)

You might celebrate UTC time - those of you not stuck in traffic in New York or at work in California. Or just do it according to your time zone: raise a toast, save some doughnuts from doughnut-Friday or look at the sky or do triple click an icon or something.

Here's a little java script to sneak onto your website which shows the time and the countdown:

<script language="javascript" type="text/javascript">
    function onTick()
    {
        var t = Math.floor( ((new Date()).getTime()) /1000);
        var remaining = (1234567890 - t);
        var display = "Now: " + t + ": " + remaining + " Sec. to 1234567890 (local time zone).";
        document.getElementById("_ShowTime").innerHTML = display;
    }

    setInterval('onTick()', 1000);

</script>
<div id="_ShowTime" style="height: 1.1em; color: white; background-color: navy; font-weight:bolder; border: dashed 1px blue;"></div>

The Flash Myth

Nuri Halperin — Mon, 02 Feb 2009 03:41:16 GMT

Frustrated with square looking web pages, many web designers look to Flash. In addition to freedom of graphic expression, Flash brings interaction and transition effects which are difficult or impossible to duplicate. Why then shouldn't all websites be Flash laden? Several reasons pop to mind:

Loading speed: Way too often, flash movies load complex graphics, forcing the viewer to stare at some progress bar. For people who want to quickly access information this is a huge turn off. A "skip intro" sometimes viewed as lame.
SEO: Flash based sites rarely are digestible or well ranked by search engines. You use flash – you lose top slots in natural search results. It's that simple
Form over content: Flash designs - as beautiful and engaging as they may be – all too often sacrifice text and information quantity in order to not disturb the layout or fit within the containing graphics. Again, ranking will suffer (low authority), viewers seeking comprehensive data will navigate away or become frustrated attempting to dig up more details by clicking every button and link in the movie.
Cost: Although many good web designers can produce Flash movies, the good ones are fewer and more expensive. The problem compounds with natural workplace attrition. The ability to modify the original design, extend the site or give the site a "facelift" becomes constrained or expensive. All too often the original design does not lend itself well to rearrangement or extension.
QA: Automated testing of Flash UI sites is difficult or impossible because the results may not be capture-able by testing tools – and that's in the good case where the inputs are automatable. Unit testing for ActionScript is available by supporting frameworks these days, but finding implementations which include continuous integration is still rare.
Ease of use: Often, the design focus reflects the author's perspective. As long as the viewer wants to view information the way the designer does, everything flows well. Once the viewer wants to navigate in a different way, all bets are off.
Stickiness: By far, one of the more compelling reasons for having used a Flash based site was to engage the viewer and strengthen the brand. The delivery on the promise is a bit mixed. Although some interaction does increase the stickiness of the site, other designs may suffer from slow load and skimpy content actually detracting from the overall perceived quality.

If while reading the points mentioned above you think to yourself "It seems that many of the points indicate poor design – not a technology limitation" you are right, and I couldn't agree with you more.

Yet a good amount of sites out there suffer from these issues. Most of these sites would have been better served producing an HTML / DHTML / CSS + Ajax etc. In fact, my motivation for writing this came from a restaurant website I visited today. While scanning through listings and attempting to learn more, I was forced to watch tab after tab of progress bar latency in order to see the menu, the location, the about us etc. That site would have been cheaper to upgrade by anybody, rank higher on search engines, load faster and create less frustrated visitors. The KISS principle does apply. The pictures were beautiful; the layout was very appealing, the information organized – but the experience utterly annoying. Is that the best impression the business owner could impart on a potential customers?

In another instance, I was searching for a specialty product, and found it about 40 miles away. After having spent the time driving there and making a purchase, I discovered a location much closer to my house. What made the different? The far store had a website with full online catalog in HTML. The close by store had a flash only site. Snazzy – but missed a sale.

I have been to some sites that make great use of Flash though, and it would be foolish to discount the technology for its potential pitfalls. On the contrary – its adoption and application should be studied and considered when new design projects com up. There are many sites containing laundry lists of good vs. bad design. This article is no such list. But when is Flash well suited?

Where a custom tool is created for order processing. Photo order sites, custom printing, fashion model virtualization etc. In these cases Flash serves an interactive function and is typically not the whole site.
Where little textual information is required. Walkthroughs, product 360 views, design concept sites targeting highly interested viewers who don't mind waiting for content and where alternative information sources are not available.
For isolated rich interaction: Games, presentations and doodads that keep the visitor happy watching and engaged – as a single section of the site.
Offline (DVD, CD) or downloadable media presentations, manuals etc.
Anywhere that you can do a better job at winning the mind of the visitor without losing another 3 along the way.

Bottom line – use it wisely. If you suspect that any of the problems mentioned above might harm your online business, consider alternatives. And yes, by all means – do use a flash player to play video clips on the net. It is very well suited for that.

Pex gotcha – watch your predicate expressions

Nuri Halperin — Mon, 26 Jan 2009 16:35:47 GMT

Just came back from another great SoCal Code Camp. I had some valuable insights and discussions about TDD and the use of Pex. Thank you attendees!

While developing the presentation for Pex, I ran into a situation where the Pex.Assume() did not seem to work at all:

Consider the function

public List<short> MakeList(short baseNum, short count)

{

List<short> result = new List<short>(count);

for (short i = 1; i <= count; i++)

{

result.Add((short)(baseNum * i));

}

return result;

}

Pex correctly identifies a potential flaw where the multiplication (baseNum * i) would result in overflow.

Adding a filter

PexAssume.IsTrue(baseNum * count < short.MaxValue);

Seems like it would do the trick – but it doesn't.

Several rebuilds, clean solution, shake heads and searches for bugs later I found the issue: The predicate provided to PexAssume.IsTrue(predicate) produced an overflow! So when pex explores it would have tripped the condition I was trying to avoid by evaluating the parameters I tried to filter out.

The fix was to rewrite the filter as:

PexAssume.IsTrue(short.MaxValue / count > baseNum);

Here, the math would not produce an overflow. Combined with PexAssume(count>0) and PexAssume(baseNum>0) my now filters work as (I) expected.

The take home is pretty obvious – ensure the predicate does not throw – but identifying it took a bit of head scratching.

Code Camp coming up

Nuri Halperin — Sat, 17 Jan 2009 04:25:55 GMT

It's that time of year again - Code Camp is next week, hosted at Cal State Fulerton.

Many good presenters, many good sessions.

Show up for one day both two, it's free to attend!

Check it out, come by

Code better – measure your code with NDepend

Nuri Halperin — Sat, 08 Nov 2008 21:32:20 GMT

If you ask the average developer what might be done to improve code, they would probably come up with "use design patterns" or "do code reviews" or even "write unit tests". While all these are valid and useful, it is rare to hear "measure it". It's odd, when you think about it, because most of us consider ourselves scientists or sorts. Some of use obtained a degree in computer science, and we view the coding practice and a deterministic endeavor. Why is it then that we don't measure our work using standard methodologies and objective tools and evidence?

For one, some of us are blissfully unaware of the existence of such methods. Indeed, the science of quality measurement of code has been the domain of university halls more so than practiced in the "real" world. Six Sigma and CMMI are probably the more familiar endeavors prescribing some sort of measure/improve into the coding practice but both include scant little in terms of measuring code itself. Rather they focus on the results of the software endeavor not on the "internal quality" of code.

Another reason for low adoption of code quality measurement is lack of tools. We have wealth of guidance instruments, but less so code quality focused. For example, FxCop and the addition of Code Analysis to VSTS have brought huge contribution to code reviewing and uniformity in coding among teams. But let's face it – with so much guidance, it's all too easy to either dismiss the whole process as "too picky" or focus too much on one aspect of coding style rather than the underlying runtime binary. This is to say that it is very possible that what would be considered "good style" may not yield good runtime, and vice-versa.

For a professional tool which enables you to view, understand, explore, analyze and improve your code look no further than NDepend. (www.ndepend.com). The tool is quite extensive and robust, and has matured in its presentation, exploration and integration capabilities becoming a great value for those of use interested digging deeper then the "my code seems to work" crowd.

The installation is fairly straightforward. You pretty much unpack the download and place your license file in your installation directory. Upon running the tool, you can chose to install integration to VS2005, VS2008 and Reflector (now a RedGate property btw).

Before using the tool for the first time, you can watch a few basic screen casts available from NDepend. The videos have no narration, so I found myself using the pause button if the text balloons flew by a bit quick. But that's no big deal with a 3-5 minute video. Once you get comfortable with the basics, you can almost immediately reap the benefits. Through a very relevant set of canned queries and screens you can quickly get a feel for how your code measures up. A graphic "size gram" presents methods, types, classes, namespaces or assemblies in varying sizes according to measures like lines of code (LOC – either the source itself or the resultant IL), Cyclometric Complexity and other very useful views of code cohesiveness and complexity. This visual let's you quickly identify or drill into the "biggest offender".

Once you chose a target for exploration, the view in the assembly-method tree, the graphic size-gram and the dependency matrix all work in tandem: you chose an element in one, and the focal point shifts or drills down in the other two. There is also a pane which acts like a context menu which displays the metrics numbers for the selected method, field, assembly etc. This allows you to get the summary very quickly at any given point of your exploration.

When you use the dependency matrix, method or types and their dependents are easily correlated. A measure of code quality is how tightly different types are coupled or dependent on each other. Theory is that if a dependency tree is too deep or too vast, change in a type will ripple through a lot of code whereas shallow or narrow dependency will have less dramatically affected by change. So it's a great thing to have a measure of your dependency relationships among your classes and assemblies. This measure tends to affect code most in the maintenance phase, but of course is as useful during initial prototype/refactor cycles pre-release.

Another great feature is a dependency graph, producing a visual map of dependencies among the assemblies analyzed. I have found it very useful when "cold reading" legacy code I was charged in maintaining. Using the visualization I could more quickly determine what's going on and understand how pieces of code work together rather than follow painstakingly with bookmarks and "follow the code" with a debugger.

As for the metrics themselves, you would probably choose your own policy regarding measures and their relevance. For one, the numbers are great as relative comparison of various code pieces. You may find that some dependencies are "very deep" – which in theory is "bad" – but that the indication points to a base class which you designed very well and serves as the base for everything. For an extreme example, most of us will agree that the "deep dependency" on System.String is well justified and doesn't merit change. It is important for the user to understand and digest the metrics in context, and draw appropriate conclusions.

The tool is built on an underlying query technology called CQL. Once a project is analyzed, the database of findings is exposed both through built in queries. These queries can be modified and new queries can be built to correlate your important factors. Quite honestly, I have not gotten to a point of need for customization yet. The existing presentations are very rich and useful out of the box. One instance where you might want to produce custom queries would be to exclude known "violations" by adding a where clause, thereby preventing code you already analyzed and mitigated from appearing or skewing the view of the rest of your code.

In summary, I found NDepend very useful in examining legacy and new code. It gave me insights beyond empirical style oriented rules. It is much more informative to me to have a complexity measure or IL-LOC rather than a rule like "methods should not span more than 2 screen-full". Microsoft does include code metrics in VS 2010, and code analysis in VSTS or testing editions. If that is not within your budget, then you can have NDepend today and gain valuable insight right away. I would advise taking it slow in the beginning because there is a slight learning curve to the tool usage and navigation, and ascribing relevant weight to the findings takes time. But once you get a hang of it, it becomes indispensible.

Code generatior for Visual Studio - Denum

Nuri Halperin — Sun, 02 Nov 2008 19:26:17 GMT

Annuouncing a newly added a Codeplex project "Denum" code generator.

The Denum is a class / pattern for representing fairly static metadata from a database in an in-memory structure.
The structure behaves much like an Enum, but contains static members for each data member so that compile time type checking helps in transparency and coherency of your application logic and the build itself against the database version.

PDC 2008

Nuri Halperin — Tue, 28 Oct 2008 18:20:34 GMT

Mind boggling things unvailed at PDC.

One big thing to decide is going to be our relation to the cloud.

Cloud computing has hit big and the whole idea of SAS making big business invest big.

Where do we draw the line? Hoe much of our software, data and service runs local vs. remote?

How do we develop good measure for decisionmaking here?

At the very least, aspect to be considered:

Latency
Scale
Time to market
Security
New opportunities not available if you are just "running local" such as ms Live services.

At the very least, if we created a startup on Azure - what is the path of migration off it if / when more local control is necessary?

Asking these questions when architecting your new cloud based application is bound to have long lasting ramifications when your application usage reaches maturity.

WCF Serialization – new in .NET framework 3.5 sp1

Nuri Halperin — Mon, 13 Oct 2008 15:08:45 GMT

You may be surprised to find that classes are serialized by WCF without any [DataContract] attribute attached to them. I certainly was.

When WCF came out, there was much fanfare of the new, improved, superior WCF serializer (justified IMHO). The main policy sizzle was that unlike the [Serializable] marking a POCO object and then [NonSerialized] attribute marking specific fields (opt-out), WCF will now use "opt-in": Only properties specifically decorated will be serialized.

This serialization policy was clearly expressed, and the side effect of it all is that suddenly I have a bunch of projects that fail some unit tests. Upon digging, I found that SP1 has introduced a new kink: if you don't decorate your class at all (omit / not add the [DataContract] attribute) then the object becomes "fully" serializable by WCF. All public properties will be automatically included.

This may seem as a huge step back to those that relied on the opt-in feature to hide certain classes from the serializer. This also may be a huge sigh of relief to those who cringed at the effort of (re)decorating all their message and value objects for WCF.

Note that now with SP1, if you do decorate an object with [DataContract] then the old rules apply – only properties with [DataMember] will be serialized. So to be selective, you may still decorate with [DataContract] and then selectively decorate only the properties you want.

I don't know what led to the exact decision, and the syntax nuance definitely walks a fine line. One could argue that classes without decoration now serialize without effort, but ones marked for WCF specifically still behave as previously advertised.

All in all, 2 hours of head scratching in disbelief, 1 hour to change some unit test expectations, not too awful. Long live refactoring tools in Visual Studio!