Sound familiar? The real problem then comes when you try and define a resource (e.g. a javascript file) using a relative path:

<script
    type="text/javascript"
    src="/Scripts/jquery.js">

This will work fine and dandy when you deploy the website, however on your local machine it will be looking for jquery at the path http://localhost/Scripts/jquery.js” – which more than likely isn’t going to work.

To get around this problem, I wrote a quick helper method called “Locate”, which I find myself reusing time and time again between websites. More often than not, I put it into a static class called “SiteManager” which basically just contains a bunch of helper functions relevant to the current website. Here’s the method:

/// <summary>
/// Resolves the path to a URL
/// </summary>
/// <param name="url">The path to be resolved, relative to the
/// application root</param>
/// <param name="formatArgs">String formatting arguments</param>
/// <returns>The URL</returns>
static public string Locate(string url, params object[] formatArgs)
{
    if (String.IsNullOrEmpty(url))
        url = "/";

    if (formatArgs != null && formatArgs.Length > 0)
        url = String.Format(url, formatArgs);

    HttpContext context = HttpContext.Current;
    return String.Concat(
        context.Request.ApplicationPath,
        !url.StartsWith("/") ? "/" : String.Empty,
        url);
}

To use the method, you simply change your script declaration (or whatever resource you’re trying to find) as follows:

<script
    type="text/javascript"
    src="<%= SiteManager.Locate("/Scripts/jquery.js") %>">
</script>

You’ll also notice that it supports string formatting – so even though it would be pointless in this particular example, you could, if you preferred, do something like this:

<script
    type="text/javascript"
    src="<%= SiteManager.Locate("/Scripts/{0}.js", "jquery") %>">
</script>

In both instances, this will resolve the URL in your output document using the current application path –

• http://localhost/MyProject/Scripts/jquery.js on your local machine; and
• http://myproject.com/Scripts/jquery.js on the web server.

Enjoy!

The simplest solution is to use “overflow:hidden” in the style of your parent element, however this doesn’t work for all browsers scenarios. So, for a much more comprehensive description of the problem, as well as a number of approaches you can use to solve it, check out this post.

function ValidateInput() {
//some slow running code here...
}

function SaveForm() {
//save the form
}

<form>
<input type="text" onchange="ValidateInput()" />
<input type="button" onclick="SaveForm();" value="Submit" />
</form>

The problem here can occur when the user hits the Submit button before the validation method can finish. One way to overcome this is use a semaphore to indicate whether the form still needs validating on the SaveForm method.

In the last 4 weeks I’ve been researching and prototyping apps that use

• .net 3.5
• ado.net entity framework
• ado.net data services – including .net, ajax and silverlight client libraries
• Silverlight 2.0
• Visual Studio for Software Testers – Web Testing

It’s been awesome to have the time and resources to touch across all of these technologies to enjoy their benefits and to loath the limitations.

All in all I reckon all of the technologies are a great addition to the .net stack and look forward to seeing them mature with each new release.

I look forward to documenting my findings as I find time to re-work them into don’t-give-away-IP examples.

Though you can use the alternating item template for this, it typically involves you duplicating a lot of code, since the AlternatingItemTemplate is mostly the same as your ItemTemplate (save perhaps for a CSS class declaration somewhere).

  <asp:Repeater ID="rpt" runat="server">
      <HeaderTemplate>
          <table cellpadding="0" cellspacing="0">
              <tr>
                  <th>First Name</th>
                  <th>Last Name</th>
                  <th>Age</th>
              </tr>
       </HeaderTemplate>
       <ItemTemplate>
              <tr>
                  <td><%# Eval("FirstName") %></td>
                  <td><%# Eval("LastName") %></td>
                  <td><%# Eval("Age") %></td>
              </tr>
       </ItemTemplate>
       <AlternatingItemTemplate>
              <tr class="Alternating">
                  <td><%# Eval("FirstName") %></td>
                  <td><%# Eval("LastName") %></td>
                  <td><%# Eval("Age") %></td>
              </tr>
       </AlternatingItemTemplate>
       <FooterTemplate>
          </table>
       </FooterTemplate>
  </asp:Repeater>

If this sounds like you, then never fear – there IS a better way!

When you’re binding, you have access to the RepeaterItem via the Container property, which contains an ItemIndex property. As such, the simplest way of alternating your items is simply to check if the number divides evenly by two:

  <asp:Repeater ID="rpt" runat="server">
      <HeaderTemplate>
          <table cellpadding="0" cellspacing="0">
              <tr>
                  <th>First Name</th>
                  <th>Last Name</th>
                  <th>Age</th>
              </tr>
       </HeaderTemplate>
       <ItemTemplate>
              <tr class="<%# Container.ItemIndex % 2 == 0 ? "Alternating" : String.Empty %>">
                  <td><%# Eval("FirstName") %></td>
                  <td><%# Eval("LastName") %></td>
                  <td><%# Eval("Age") %></td>
              </tr>
       </ItemTemplate>
       <FooterTemplate>
          </table>
       </FooterTemplate>
  </asp:Repeater>

There is a minor downside using this approach – the non-alternating rows will all declare an empty CSS class within them. But, this is a sacrifice I think is acceptable to decrease repetition of code.

// in code-behind
rpt.DataSource = document.SelectNodes("/ROOT/students/student");
rpt.DataBind();

<!-- in aspx page -->
<asp:Repeater id="rpt" runat="server">
    <ItemTemplate>
        <%# XPath("name/text()") %>
    </ItemTemplate>
</asp:Repeater>

The first challenge was getting the ibox to open and display the form correctly. I chose to use a hidden div as my “form”, and let the ibox display it on the screen when appropriate. It all seemed to work correctly, however when I tried to read the values out of the fields on the ibox form, it kept telling me they were empty!

After a lot of mucking around, cursing, and rude gestures directed at the computer – you know, the standard debugging drill – I worked out that when you use a hidden div as your ibox, it actually *clones* the entire InnerHTML of the hidden div! So in effect, you get *two* of every field with duplicate IDs. And, since the HTML generated by ibox goes at the *end* of your document, when you call document.getElementById, you get back the *first matching element*, which will always be the one that’s still safely hidden away in your form. Handy – not!!

But never fear, the solution is actually quite simple. You just have to create an external file containing your ibox form, and then use that as the HREF in your link:

<a href="FindAddress.aspx" rel="ibox&height=400" title="Find an address">Find address</a>

Ahh, finally things started working properly! So now that I could read the postcode that the user entered, I wanted to hit a handler to…. err… “handle” the web service request. To do that, I used prototype.js – a javascript library with a whole bunch of wicked cool functionality (all of which is way beyond the scope of this article). Check it out -to execute a cross browser friendly AJAX request, you simply do this:

  var url = "Handlers/FindAddressHandler.ashx?Id=" + id;
  new Ajax.Request(url, {
    onSuccess: OnAddressFound,
    onFailure: OnError
  });

Of course, you can inline the callback functions, but I wanted to separate them for readability. Anyway, the next part was setting up the FindAddressHandler. I won’t go into too much detail here as it’s just a standard implementation of IHttpHandler which then hits a web service. The part I want to talk about though is writing back the address object using JSON. A dude named Jason Newton King has written a brilliant library called Json.NET which makes life a hell of a lot easier!

Basically, you just have to create a JsonWriter, then serialise the properties of your object that you want to send back to the client. So in my case with an Address object (stored in local variable “address”):

StringBuilder builder = new StringBuilder();
using (JsonWriter writer = new JsonWriter(new StringWriter(builder))) {
  writer.WriteStartObject();
  writer.WritePropertyName("PostCode");
  writer.WriteValue(address.Postcode);
  writer.WritePropertyName("Address1");
  writer.WriteValue(address.Line1);
  writer.WritePropertyName("Address2");
  writer.WriteValue(address.Line2);
  writer.WritePropertyName("Address3");
  writer.WriteValue(address.Line3);
  writer.WritePropertyName("PostalTown");
  writer.WriteValue(address.PostTown);
  writer.WriteEndObject();

  writer.Flush();
}

_context.Response.AddHeader("X-JSON", builder.ToString());

Easy, right? So the thing to note here, besides how simple it is to persist your object in JSON, is that I’m sending back the JSON string in a response header called “X-JSON”. Now back on the client side again – one of the bonus features of Prototype is that it automatically interprets whatever is in the “X-JSON” header, and builds your objects for you! So, here’s the code I wrote for my client-side callback:

function OnAddressFound(transport, address) {
    $("txtAddress1").value = address.Address1;
    $("txtAddress2").value = address.Address2;
    $("txtAddress3").value = address.Address3;
    $("txtPostCode").value = address.PostCode;
    $("txtPostalTown").value = address.PostalTown;

    hideIbox();
}

The first argument – transport – is the XmlHttpRequest object which was used. (You can find a great document which outlines the properties of the XmlHttpRequest object on the Apple Developer Connection website). The second argument is the object which Prototype interpreted from the X-JSON response header. You can see also that prototype implements a function – $ – which is effectively a suped-up version of document.getElementById.

Using all of these technologies together was surprisingly easy! I’m super impressed with how you can grab so many rich frameworks to enhance your websites, all for free!

private void OnItemDataBound(object sender, RepeaterItemEventArgs e) {
    // skip header row
    if (e.Item.ItemIndex < 0) {
        return;
    }

    // custom logic
}

Today however, I found out there's a nicer way:

private void OnItemDataBound(object sender, RepeaterItemEventArgs e) {
    // skip header row
    if (e.Item.ItemType == ListItemType.Header) {
        return;
    }

    // custom logic
}

Sure, given that both ways work equally well, it seems as though the difference is for aesthetics only (i.e it's nicer to read); but there are actually two other big advantages:

1. It is not tied into the implementation of the repeater - that is, it does not rely on the header row index being less than zero; and
2. You can use the ListItemType enumeration to detect many different types of items - for example, the Footer row for performing summary calculations.

I was working on the weirdest bug with a colleague today where we were receiving a javascript “Object expected” error when we migrated a page into our new ASP .Net Master Page format.

We thought we hadn’t made any breaking changes, all we had done was move the <script> tags into the MasterPage file from the content page.

That didn’t work, so we created a header content place holder in the master page <head> element and in the content page put back the <script> includes. That didn’t work either.

We then included the <script> tags in both the master and content page. That seemed to work. Very odd.

In the end after many attempts to figure out what was going wrong, we found the problem was with how MSIE parses <script> tags, it cannot use self closing tags or an empty element – ie. <script … />.

It has to have the <script></script> tag.

For more info check out quirksmode.org.

<connectionStrings>
  <add name="cs"
    connectionString="Data Source=localhost;Initial Catalog=MyDB;Connection Timeout=60;"
</connectionStrings>

Sure looks OK, but as it turns out, this wasn’t working for him. The reason is actually quite straightforward – the Connection Timeout property is used to specify how long the application will wait to establish a connection to the server before giving up and throwing an exception. In most cases (where connections are properly managed), the connection will be returned almost instantaneously, hence changing this value is usually not required.

Instead, the timeout that he needed to change was the CommandTimeout on the SqlCommand object which was being passed to the database.

  SqlCommand command = new SqlCommand();
  command.CommandTimeout = 60;

As the MSDN doco states, this property "Gets or sets the wait time before terminating the attempt to execute a command and generating an error". And sure enough, once he changed this value to 60, everything was dandy.