Dan Miser - ASP.NET MVC

ASP.NET MVC list binding differences between TextBox and TextBoxFor

Dan Miser — Wed, 24 Feb 2010 04:12:13 GMT

I use list binding in my ASP.NET MVC applications in several places. When it works, it is truly magnificent. When it doesn't, it's just maddening. Here's a quick heads up for those of you that use list binding in MVC. You would expect the following 2 lines to render the same HTML, but they don't. To get list binding to work, you need the HTML to read something like this (I'm just listing the attributes in question here):

 <input name="Results[0].Score" />

The old TextBox helper works fine, since you're assigning the name attribute:

 Html.TextBox("Results["+id+"].Score", Model.Score)

This code, however:

 Html.TextBoxFor(r => r.Score, new { name = "Results["
+ id + "].Score" })

produces the following output, which means the Score property won't get bound properly.

 <input
name="Score" />

The problem is that in the TextBoxFor code, the name attribute is ignored. To be more precise, the custom name is added, but the attribute is then replaced by the name derived from the model.

ASP.NET MVC 2 RC Changes

Dan Miser — Tue, 19 Jan 2010 02:52:39 GMT

I just updated my ASP.NET MVC 1.0 application to use ASP.NET MVC 2 RC. It was a pretty painless process. Be sure to follow the Release Notes on the download page, and many applications will be ready to go. Here are some extra things that might help get you unstuck:

If you're using the ASP.NET MVC Futures (Microsoft.Web.Mvc) assembly, be sure to download the new one that works with ASP.NET MVC 2.
If you're using the Telerik ASP.NET MVC components, be sure to download version BETA 2009.3.1218 or later.
Way, way, way back in the ASP.NET MVC 1.0 beta days, they had a very nice mechanism to update lists of items by tying UI fields to index numbers, so you could use primary key identifiers to help keep track of what fields were modified where. In the 1.0 RC release, Microsoft changed how it worked to do things sequentially instead. I was using the IndexModelBinder found in that thread with great success ever since then. However, Microsoft added back in the index support to ASP.NET MVC 2 RC. This means that you will have to delete the old IndexModelBinder since it won't compile anymore. Thankfully, I didn't have to change a line of my code. Nice job of code compatibility!!

Telerik Extensions for ASP.NET MVC

Dan Miser — Sun, 08 Nov 2009 03:00:21 GMT

Telerik just released an extremely impressive library of components (Grid, Menu, TabStrip, and MenuBar), written for MVC. They are truly first-class, from the architecture, to the development experience, to the finished screens that your user sees. They released them as open-source, and even better, these controls are written from the ground up to support ASP.NET MVC.

Be sure to check out this awesome write up on how to Use the grid in a CRUD scenario. Very nicely done.

I'm not a fan of the whole "Edit/Delete" action column. I'd much rather just have a link on the column to take me to the detail screen. Here's the way I solved that:

 <%
Html.Telerik().Grid(Model) .Name("Grid") .PrefixUrlParameters(false) .Columns(columns
=> { columns.Add(o => o.CollectionDate).Template(c => { %> <%= Html.ActionLink(c.CollectionDate.ToShortDateString(),
"View", new { Id = c.Id })%> <% }).Width(40); columns.Add(o => o.Location.Name).Width(40);
}) .Scrollable() .Sortable() .Pageable() .Filterable() .Render(); %>

ASP.NET MVC on the iPhone

Dan Miser — Fri, 06 Nov 2009 23:44:02 GMT

I've never been happier that I chose a technology after today. I have a production web application built using ASP.NET MVC, and it has been working with almost no issues for over a year now. As a matter of fact, it is the cornerstone used to run our business. I've had the default blue skin in use since day 1 (ya, ya, I know, I know. I've been so lazy, I haven't even switched out to pre-built templates), and we run the app on the iPhone. It works, but there's always pinching, zooming and scrolling going on. I finally bit the bullet after thinking to myself "Why not create a view tailored to the iPhone to enhance the experience?" one too many times. About 12 hours later, the entire application was done with an auto-detected, optimized look and feel for the iPhone. I am now convinced that I've just been paid back with the technical dividends for investing in ASP.NET MVC. :)

To help the next guy out who walks down this path, here are all of the links that I used during this process:

Aaron Lerch's seminal article on using iUI
iUI project home page (Be sure to use 0.31. It is lightning fast!)
Scott Hanselman's article that introduced the auto-detect view engine
CW Zachary's article that gives some extensions to iUI (like tables, load/unload, and script/css execution)
Joe Hewitt's introductory video. Nice presentation, and the _replace nugget was worth the 15 minutes to watch it.

Populating Date Ranges, part 2

Dan Miser — Tue, 13 Oct 2009 04:11:13 GMT

Since my last post, the date has changed from October 9th to October 12th. The reason this is important is that the functions that needed to calculate the date based on the current date are now coming through a different code path. Before, everything worked great. As of October 10th, not so much. The fix is simple - the getDate function was missing the parentheses to make it a method call. The fix is quite simple and is listed below:

 var
day = (now.getDate() < 10) ? "0" + now.getDate() : now.getDate();

Populating Date Ranges

Dan Miser — Fri, 09 Oct 2009 01:44:07 GMT

I have several reports in my ASP.NET MVC application that are date-oriented. I had start date and end date text boxes, and things worked fine. What I really wanted was something that would allow those date boxes to be populated with a variety of canned date ranges (e.g. Year to Date, Last Month, etc.). I found just what I was looking for in a pure JavaScript implementation here.

The one problem I found was that "Last Month" was being calculated incorrectly. Below is the simple fix. Thanks to epalla for the original code.

 // last month case "lastmo": // we need a new month variable for month-1,
also formatted correctly var lastmonth = ((month - 1) < 10) ? "0" + (month - 1)
: (month - 1); startbox.value = lastmonth + "/01/" + year; // now grab the last day
of the month (30, 31? we don't know!) var moend = new Date(year, (month - 1), 0);
endbox.value = lastmonth + "/" + moend.getDate() + "/" + year; break;

Why AJAX posts go to a new page instead of updating UpdateTargetId

Dan Miser — Sun, 31 May 2009 16:38:24 GMT

Given a set up like this (where ExpenseSummaryData returns some arbitrary HTML fragment) :

 <%using
(Ajax.BeginForm("ExpenseSummaryData", new AjaxOptions { UpdateTargetId = "result"
})) { %> <label for="startDate">Start Date:</label> <%= Html.TextBox("startDate")
%> <br /> <label for="endDate">End Date:</label> <%= Html.TextBox("endDate")%>
<br /> <input type="submit"/> <br /> <span id="result"/> <%
} %>

If that is all your page does, you will notice that you get taken to a new page when pressing Submit. The data on the new page is the HTML fragment returned by the AJAX call, but that's all it contains (e.g. no master page), and it's clearly not replacing the result span.

The reason for this is that I forgot to add the following lines to the <head> section in the original page:

 <script src='<%=ResolveUrl("~/Content/js/MicrosoftAjax.debug.js")%>'
type="text/javascript"></script> <script src='<%=ResolveUrl("~/Content/js/MicrosoftMvcAjax.debug.js")%>'
type="text/javascript"></script>

After adding those declarations in, the content in the span tag is properly updated and it looks like a real AJAX call.

ASP.NET MVC Architecture Round-up

Dan Miser — Thu, 26 Feb 2009 21:17:53 GMT

I've been playing with ways to write a solid (and even SOLID :)) architecture with ASP.NET MVC. I started with a plain LINQ to SQL approach, and then migrated to LightSpeed, and finally ended up checking out S#arp last week. Here are my notes of pros/cons on each approach. Yes, I could (and most likely will) address some concerns by writing code for it. This is more of a laundry list of the state of things as I see them at this point in time.

LINQ to SQL

Pros

Visual designer

Cons

MS is talking about phasing LINQ to SQL out and forcing people towards Entity Framework. I'm pretty sick of chasing MS's data-access strategies around every year.
LINQ to SQL mostly defaults you to a 1:1 mapping between your database and your model.
Support for modifications to the schema sucks, to be generous.
No UnitOfWork concept. Of course, as I prepared this blog entry, I found this article published just today, so maybe that would address this point.

LightSpeed

Pros

Support is outstanding.
Nightly builds are available.
Visual designer.
Proven patterns bundled in their core libraries (UnitOfWork, Repository, Entity, etc.).
Picks up changes from the schema flawlessly.

Cons

Commercial and propietary.
Lacks quite a bit of LINQ support. For example, groupby and join are not supported. This meant that I use LINQ to SQL when I need these features. Fortunately, that's all isolated to my report module, so it's not as horrible as it could be.

S#arp

Pros

Open Source
Uses standard, widely adopted open source libraries: NHibernate, Windsor, etc.
Convention over Configuration
Scaffolding

Cons

I'm not digging the T4 templating mechanism. They conflict with VisualSVN and Developer Express tools, and having to write a template for each and every entity is cumbersome.
No visual designer
No ability to import entities from an existing database. Yes, they like DDD, but in almost every project I've been a part of, the database is the thing that already exists.
No UnitOfWork pattern (I might be able to fit code out there that does this in with S#arp). The [Transaction] attribute approach feels a bit dirty.
The scaffolding is a bit too simple. It doesn't build up object graphs with links (for display) or SelectLists (for editing). Yes, I can add that. It probably will get that functionality at some point, too. But it doesn't do it right now.

For now, I think I'll be staying with LightSpeed, but I'll be watching S#arp very carefully.

RenderPartial for a collection

Dan Miser — Fri, 30 Jan 2009 22:40:58 GMT

At work, a debate broke out over MVC. In that debate, Chris Peterson commented that he hated the way things looked on the view pages, specifically with code executing in the view context. By way of example, he talked about the need for a for loop to display a collection, and how he didn't like that. Geoff Lane commented that Grails had support for this built-in.

To overcome these objections, I wrote the following simple extension method:

public static class RenderPartialCollectionExtension

{

    public static void RenderPartialCollection<T>(this HtmlHelper htmlHelper, string partialViewName, IList<T>
list)

    {

        foreach (T
item in list)

        {

            htmlHelper.RenderPartial(partialViewName,
item);

        }

    }

}

This means that instead of the old-style View page code, like this:

<% 

   foreach (Foo foo in Model)

   {

       Html.RenderPartial("~/Partials/DisplayFoo.aspx",
foo);

   }

 %>

You can just write code like this:

<% Html.RenderPartialCollection<Foo>("~/Partials/DisplayFoo.aspx",
Model); %>

Strongly typed Partial Views

Dan Miser — Thu, 29 Jan 2009 19:22:09 GMT

It seems that ASP.NET MVC doesn't allow for strongly-typed partial views. If anyone knows of a clean way to do it, I'd love to know!

Take the following typical page declaration:

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<Foo>"
%>

This declaration allows us to access the Foo.Bar property in the view page using the following syntax: Model.Bar. This works really well, and we even get Intellisense for Foo when accessing the Model property in the editor. In contrast, if we inherited from the non-generic ViewPage, Model becomes a simple object type, which means type-casting to get to our passed in model object.

However, using partial pages with a similar technique does not work. For example, if we have a partial page (ViewPage or ViewUserControl) and call it like below, it will not allow for strong typing of the page:

Html.RenderPartial("DisplayFoo",
foo)

If we try to strongly type the page, it will result in an error like this at run-time:

Parser
Error Message: Could not load type 'System.Web.Mvc.ViewPage
'.

One work-around is to create a code-behind file, and specify the strong typing there, and then inherit the partial page from the code-behind. But I really don't like that. RC1 made great strides to get rid of the code-behind mess, and I would prefer not to reintroduce it just for this.

Update: Thanks to bradleylandis in the ASP.NET MVC forum, he correctly figured out that I had my partial page in a folder other than the Views folder. He mentioned that you need to copy the web.config file from the Views folder to any folder that you serve view pages out of. After doing that, I now have a strongly typed partial page.