The usual way to handle this issue is by using the ClientID property in Javascript, like <%= lblCountTotal.ClientID %>. However, there are some situations when you can’t use the ClientID of a control. A notable one is when the control is inside the ItemTemplate of a Repeater. So if you’re thinking, for example, to update all the label values in your Repeater on a Javascript event, you realize you can’t really access them and start thinking of a work-around. I’m going to describe you how I handled the issue.

My use case

In a couple of my recent projects at work, we are developing some in-house web applications for a network of hospitals and part of the web apps is porting all their reporting logic. More exactly, they have a lot of excels with different data input forms and, from those filled-in forms, reports must be generated.

Now, when recreating those data input forms on the web, we try to keep as much of the existing look & feel as possible, so we won’t confuse the users too much with the changes. This means that those calculations Excel makes “on the fly” have to work the same way when the user goes from field to field on our webform. And if the forms are large (and they usually are) and we want those calculations to run as fast as not-noticeable, we have to use Javascript (so purely client-side code) to do them.

The ‘didactic’ example

In order not to bore you to death and make some sense with what I’m talking about, I made a small form to help you follow me.

 
As the user fills in the fields with the number of visitors per time zone, the form must calculate the total number of visitors and the percentages (visitors for a time zone / total number of visitors). Each time a field has been changed, the total is changed and consequently all the percentages.

Some of the ASP.NET mark-up for the page:

<tr style="background-color: #FFFFCC;">
    <td>
        Total
    </td>
    <td>
        <asp:Label ID="lblCountTotal" runat="server">0</asp:Label>
    </td>
    <td>
        &nbsp;
    </td>
</tr>
<asp:Repeater ID="rptVisitors" runat="server">
    <ItemTemplate>
        <tr style="background-color: #EEEEEE;">
            <td>
                <%#Eval("TimeZoneName") %>
            </td>
            <td>
                <asp:TextBox ID="txtCount" runat="server" onblur='<%# "UpdateValues(" + Eval("Index") + ", this.value)" %>'></asp:TextBox>
            </td>
            <td>
                <asp:Label ID="lblPercent" runat="server">n/a</asp:Label>
            </td>
        </tr>
    </ItemTemplate>
</asp:Repeater>
<asp:HiddenField ID="repeaterRowsCount" runat="server" />

 
The Repeater there is bound using GetSystemTimeZones(), a method I talked about in my previous blog post:

protected void Page_Load(object sender, EventArgs e)
{
    int index = 0;
    rptVisitors.DataSource = TimeZoneInfo.GetSystemTimeZones()
                                         .OrderBy(tz => tz.StandardName)
                                         .Select(tz => new
                                         {
                                             TimeZoneName = tz.StandardName,
                                             Index = index++
                                         });
    rptVisitors.DataBind();

    repeaterRowsCount.Value = rptVisitors.Items.Count.ToString();
}

 
You can see in the ASP.NET mark-up how, on the onblur event of txtCount, so when the user tabs to the next field, the UpdateValues() Javascript method is called. UpdateValues() calculates the total number of visitors and then the percentages, and the catch is setting those percentages for each lblPercent.

As I said, you can’t use the ClientID property to access controls inside Repeaters. The labels get IDs like ctl00_ContentPlaceHolder1_rptVisitors_ctl01_lblPercent, ctl00_ContentPlaceHolder1_rptVisitors_ctl02_lblPercent, and the trick I finally used was building their IDs on the go, by getting the base part from the ClientID of the Repeater.

This is how my Javascript code turned out to look:

var repeaterId = '<%= rptVisitors.ClientID %>';
var repeaterRowsCount = 0;
var values = [];

window.onload = function() {
    repeaterRowsCount = eval(document.getElementById('<%=repeaterRowsCount.ClientID %>').value);

    for (i = 0; i < repeaterRowsCount; i++)
        values[i] = 0;
}

function UpdateValues(row, value) {
    values[row] = 0;
    if (value != '' && !isNaN(value))
        values[row] = eval(value);

    var totalCount = 0;
    for (i = 0; i < repeaterRowsCount; i++)
        totalCount += values[i];

    document.getElementById('<%= lblCountTotal.ClientID %>').innerHTML = totalCount;

    for (i = 0; i < repeaterRowsCount; i++) {
        var percent = 'n/a';
        if (totalCount > 0)
            percent = ((values[i] / totalCount) * 100).toFixed(1) + "%";

        var rowNo = i;
        if (rowNo < 10)
            rowNo = "0" + rowNo;

        document.getElementById(repeaterId + '_ctl' + rowNo + '_lblPercent').innerHTML = percent;
    }
}

I highlighted there the two lines, getting the ClientID of the Repeater, and then building the ID for each label. Besides providing a way to access the labels, using the Repeater’s ClientID as a base ensures that this code won’t break when subsequent changes are made to the project.

I’ve let the rest of the code there, so you’d see the whole solution. Most notably, the way I got the number of items in the Repeater, which I needed in the Javascript code, by using the repeaterRowsCount hidden field.

Alternatives

The first thought I had when I started working at the webforms was making the calculations in code-behind, by using AJAX calls. But, even if it would have been nicer, I soon found out that it was too slow for forms with lots of fields. As soon as you got at about 200 fields, you could notice the delay, and I even had forms with 1600 fields!

Another nice solution would have been jQuery’s ‘ends-with’ selector. Actually, on my first take I was using, instead of this:

document.getElementById(repeaterId + '_ctl' + rowNo + '_lblPercent').innerHTML = percent;

, this:

$('id$=_ctl' + rowNo + '_lblPercent').html(percent);

Which is, of course, shorter, and worked perfectly on my IE8 browser. However, the ‘ends-with’ selector is terribly slower on older browsers, as Dave Ward points out (execution time of a ‘ends-with’ selector, in milliseconds):

And this made my form unusable on IE7, for example, so I had to ditch the jQuery. I must note, however, that jQuery is a wonderful library, it just wasn’t the “tool for the job”.

TimeZoneInfo timezone_EST = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");

DateTime now_EST = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, timezone_EST);

And now for the yada yada.

As standard as the ‘Eastern Standard Time’ might seem to you, C# doesn’t know a thing about it. In fact, it doesn’t know much about any timezone, except the local timezone (the one on the computer running the application) and the UTC.

Why that, it beats me. I would have expected to have at least the more used timezones kept inside the basic library. But I guess it wasn’t meant to be.

Instead, to get information about a specific timezone, you have to retrieve it from your system’s registry, with the FindSystemTimeZoneById method. This means you have to hardcode the timezone’s ID, and this after you made sure the computer that runs the code has your intended timezone with that ID in the registry.

To get a complete list of the timezones available on your system, you can go ahead and check the registry! (just joking, there’s a method for that)

Fortunately, these timezone IDs are pretty standard across Windows installations. And I’ll just throw here a list, to easily grab an ID when I need it (these are the timezones on my Windows 7; compared with a list I got from a Windows XP, there are ~7 different entries, rather obscure timezones):

If you like reading in-depth articles from the Creators, I highly recommend a post called A Brief History of DateTime, not by Stephen Hawking, on the BCL Team Blog. It’s about how the DateTime types evolved across .NET versions and how, in order to preserve backwards-compatibility and reliability, the usage of these types may not be that intuitive in some cases.

And the following method, which returns an enumeration of all the categories having the given ParentId:

public static IEnumerable<Category> Enumerate(int? parentId)
{
    RiotingDataContext dataContext = new RiotingDataContext();

    return dataContext.Categories.Where(c => c.ParentId == parentId);
}

Now, this works as expected… right until you pass a parentId which is null. At that moment, the returned sequence is empty, although there are categories in the database that have a null ParentId.

I ran into this more than once and, needless to say, you are quite surprised when you see this for the first time. What to do? Of course, a quick check with SQL Profiler, to see what the hell Linq-to-SQL is doing underneath.

exec sp_executesql N'SELECT [t0].[Id], [t0].[Name], [t0].[ParentId]
FROM [dbo].[Categories] AS [t0]
WHERE [t0].[ParentId] = @p0',N'@p0 int',@p0=NULL

The problem is that the parameterized stored procedure that is generated checks if our nullable int equals null by doing ParentId = NULL, when the right way to do it (SQL-style) is ParentId IS NULL. So the code we would want to be generated, when ParentId is null, is:

SELECT [t0].[Id], [t0].[Name], [t0].[ParentId]
FROM [dbo].[Categories] AS [t0]
WHERE [t0].[ParentId] IS NULL

, and is the result we will get if we modify our method like this:

public static IEnumerable<Category> Enumerate(int? parentId)
{
    RiotingDataContext dataContext = new RiotingDataContext();

    if (parentId != null)
        return dataContext.Categories.Where(c => c.ParentId == parentId);
    else
        return dataContext.Categories.Where(c => c.ParentId == null);
}

Or, in a more compact manner (and the way I like to use it):

public static IEnumerable<Category> Enumerate(int? parentId)
{
    RiotingDataContext dataContext = new RiotingDataContext();

    return dataContext.Categories.Where(c => parentId != null ? c.ParentId == parentId : c.ParentId == null);
}

But, if you stumbled-upon this post, you probably know these by now. I should add a small explanation by Rick Strahl about the behaviour of the DataContext:

Linq to SQL has a persistent approach to managing its ‘connection’ to the database via this data context and it basically assumes that you use a single DataContext to make all of your data related access. This doesn’t mean that it makes persistent connections to the database, but means that the DataContext instance maintains state about active result sets, which is especially important if change tracking is on which is the default.

Now, Linq-to-SQL, especially with its language enhancements, greatly improves the handling of database data, making the code more fast-to-produce, maintainable and most of all readable. The classes included in Linq’s standard libraries are enough for most of small-scale project architectures.

However, when trying to develop a multi-tired web application, most people get to problems where their objects get detached from the DataContext and awkward ways are used to track their changes. The scenario is as follows: the object is retrieved from the DataContext, some changes are made to it, the object is passed through different layers of abstraction in the project architecture (and possibly a postback or two) and finally you end up with a detached object. There are several ways of attaching it back, but they either imply some changes to the table mapped by the object, either some cumbersome code that you have to repeat each time you have the problem.

The solution I’m using is one of the options Rick Strahl talks about in his article, creating a thread-specific DataContext, but using the CallContext to make the DataContext persistent, and in rather few lines of code. The basic idea is keeping the same DataContext during a given session, which will be the only one responsible for keeping track of your objects and thus avoiding them to get detached.

Enough with the talk. The code now. Basically it revolves around using a DataContext Factory to keep your DataContext in the CallContext:

using System.Data.Linq;
using System.Runtime.Remoting.Messaging;

namespace RiotingBits.Data
{
    public class DataContextFactory<T> where T : DataContext, new()
    {
        public static T RetrieveDataContext()
        {
            string key = string.Format("DataContext_{0}", typeof(T));

            T currentDataContext = (T)CallContext.GetData(key);
            if (currentDataContext == null)
            {
                currentDataContext = new T();
                CallContext.SetData(key, currentDataContext);
            }

            return currentDataContext;
        }
    }
}

As you can see, the Factory works with generic DataContext types, to allow its usage with different data contexts you may have in your application. The next step is creating an extender for the DataContext you want to persist:

namespace RiotingBits.Data
{
    public class DataContextExtender : DataContextFactory<RiotingBitsDataContext>
    {
        public static RiotingBitsDataContext DataContext
        {
            get
            {
                return RetrieveDataContext();
            }
        }
    }
}

Here, RiotingBitsDataContext is the name I gave to my DataContext.

After adding these two classes, you don’t even have to instantiate your DataContext each time you use it. You simply use the static property of the Extender. Some examples of usage for Read/Update/Insert on a normal Users table:

public static User GetById(int userId)
{
    return DataContextExtender.DataContext.Users.Where(u => u.Id == userId).SingleOrDefault();
}

public void Save()
{
    if (this.Id == 0)
        DataContextExtender.DataContext.Users.InsertOnSubmit(this);

    DataContextExtender.DataContext.SubmitChanges();
}

As a closing-paragraph, I’d like to debate about the necessity of such kind of a solution. Is it something terribly wrong with Linq-to-SQL that you may need this? I tend to say no. When you have complex architectures, this is a thing that’s bound to happen, making your own custom classes to address your project’s architectural needs. Linq-to-SQL behaves exactly as an Object-Relational Mapping tool is expected to. So my thoughts go more on the line of Ian Cooper’s:

I read a fair number of opinions that are suprised by the behavior of LINQ To SQL. However, having used ORMs for a number of years, I find LINQ To SQL conforms to my expectations as to how an ORM should behave. Indeed a reading of something as old now as Martin Fowler’s Patterns of Enteprise Application Architecture and you will find exactly this pattern of behavior for an ORM discussed. Indeed WORM (Wilson O/R Mapper now open source BTW) and NHibernate both behave in a similar fashion. So some of this seems to be based on expectations that don’t come from experience of using ORM tools.