v0.7 (4/29/2008)

• Updated embedded Highslide version to 3.3.17.
• Improved caption rendering, using inline caption divs. This should result in more semantic markup, pairing your captions with your images.
• Added HighslideManager property: NumberOfImagesToPreload. This allows you to control how many images are automatically preloaded.
• Added HighslideManager property: FadeInOut. When true, this fades the enlargement in and out as it’s resizing.
• Added HighslideManager property: RenderScriptInPlace. This allows you to control where on the page the Highslide JS script is inserted in your page.
• Updated download to include a sample site, to make it a little easier to get up and running quickly.

As always, the latest version is available on the Highslide JS .NET project page.

Originally posted at: Encosia.

I’d like to take a moment to strongly recommend against doing that.

I’m going to explain what I believe are the three most dangerous drawbacks inherent to UpdatePanel based navigation: Performance degradation, usability concerns, and lack of maintainability.

Note: I would add SEO concerns to the list of drawbacks, but I’m going to assume that anyone who cares about SEO knows better than to use an UpdatePanel for content they wish to be indexed.

Performance degradation (read: obliteration)

As I’ve mentioned in the past, UpdatePanels endanger the performance of your application. While the UpdatePanel does have its place, the underpinning for your entire site’s navigation system is not one of those places. A quick comparison makes this clear.

This is what happens when you use a LinkButton to trigger an UpdatePanel refresh:

• The PageRequestManager catches the event on the client side and runs through its pre-request events, while preparing an XmlHttpRequest object.
• This XHR object makes an HTTP POST request to the server. This request includes every form field on the page, including the entire ViewState (even for areas of the page not being updated).
• ASP.NET creates a new instance of the Page class, using the ViewState and other POST data to restore its state to that of your last postback or partial postback.
• The Page runs through its lifecycle and returns its rendered HTML result to the ASP.NET AJAX framework.
• The ASP.NET AJAX framework parses out the specific HTML section(s) that will be sent back to refresh the UpdatePanel(s) affected by the partial postback.
• This response is combined with other control information, such as JavaScript content registered via the ScriptManager’s various methods, and sent back to the XHR object.
• The PageRequestManger parses the response and updates the DOM to refresh the affected UpdatePanel(s).
• Finally, the browser renders the updated DOM.

Using a traditional HTML <a> link to navigate the browser to a different page:

• The browser makes a simple HTTP GET request to the URL.
• ASP.NET creates a new instance of that Page.
• The Page runs through its lifecycle and returns its rendered HTML.
• The browser receives this HTML and renders it.

As you can see, these two methods of requesting an update are two very different animals. Not only is the partial postback pipeline far more complex, but some of the additional steps are potentially very expensive.

Perceived performance is usually more important than actual performance. The UpdatePanel is not going to bring this to the table.

When considering performance, it’s also important to keep in mind that what seems fast enough in a local development environment may be devastatingly slow when deployed. It is essential that you test your application’s performance over a WAN connection early and often.

Usability? What’s that?

When you choose to discard the browser’s navigation system for one of your own creation, you also discard usability benefits that you might not be aware of. Each individual browser provides progress indication and other subtle cues that your users have spent years becoming accustomed to. Replacing that with a foreign system is jarring and needlessly introduces an artificial learning curve.

Further, you suddenly make yourself responsible for providing accurate progress indication in every browser. When’s the last time you tested your UpdateProgress template on an iPhone? Yeah, me either.

Personally, I make heavy use of the DragAndGo add-on for regular browsing. When I come across a site that won’t allow me to toss its links into tabs this way, I typically won’t spend much of my time fighting with it.

Needless to say, the LinkButton’s __doPostBack href quickly sends me packing.

Who will you find to maintain it? Not me!

Your single, monolithic page will add tremendous maintenance overhead to your entire application. Worse still, many of the problems don’t present immediately, so it’s easy to start down this road and find yourself painted into a corner later.

For just a taste of what you could be in for, consider these potential pitfalls:

• Imagine if every time you made a modification to page A, you had to carefully avoid breaking pages B-Z and then regression test them all.
• Imagine when your designer(s) want to make changes to the site, but its HTML is locked inside this single page structure. That interaction tends to already be painful enough even with a traditional page structure. Complicating it further is going to be a non-starter in just about any organization.
• Imagine trying to work in a multi-developer environment at all.
  • If you’re using VSS or TFS for source control, one developer checking out for a minor edit would lock the rest of the team out of the entire presentation layer.
  • If you’re using something like SVN, nearly every change to the presentation layer would result in a merge operation, instead of a simple commit.

Once you start thinking about the potential maintenance issues, you can probably think of a dozen more on your own. I won’t belabor the point.

Conclusion

Hopefully, this laundry list of drawbacks will save you from making the mistake of using an UpdatePanel for site navigation. If not, I hope that it has at least raised your awareness about the problems that lie ahead, so that you may prepare for them now.

So how should you do it instead? Iframes. It’s that simple.

Originally posted at: Encosia.

However, it is an important question, the answer to which is important to understand. So, in an attempt to fill in this gap for the searchers and perhaps preemptively help others, I want to proceed to answer it as thoroughly as possible without overly complicating the whole business.

In order to do this, we’ll have to take a brief tour of WebForms, including:

• Understanding what the Page class is, and why we have it.
• One specific thing that the Page class does for us.
• How this is accomplished, behind the scenes.
• What the static keyword entails, when used with a method.
• Finally, why page methods must be static.

Note: Please bear in mind that I have taken great liberties in simplifying these concepts down to only what is necessary to answer the central question. What I will show you is conceptually accurate, but some of the implementation details are much more complex than what you will see here.

Understanding what the Page class is, and why we have it

Contorting the stateless HTTP protocol to accommodate ASP.NET’s WebForm paradigm was a considerable task for the ASP.NET team to accomplish. On top of that, going from the inline execution model of ASP classic to the event-driven model of ASP.NET also required major changes.

As such, the ubiquitous WebForms Page class was created to solve these various problems. Take this snippet, for example:

public partial class _Default : System.Web.UI.Page 
{
  protected void Page_Load(object sender, EventArgs e) 
  { 
    // Hello World.
  }
}

I’m sure you’re familiar with the Page_Load event. The very first ASP.NET code example you were exposed to probably involved the Page_Load event. How about this portion of it though?

public partial class _Default : System.Web.UI.Page

To get you started quickly, those examples may not have explained that part very well (if at all). Later, after you get up and running, it can be easy to simply gloss over this line as cruft that comes with writing an ASP.NET page.

What this declaration means is that your code extends the Page class. Because of this, your code will include the functionality of the entire ASP.NET Page class, instead of standing on its own and requiring you to implement the mundane details.

If you’re more familiar with something like ASP classic or PHP, you can think of this Page inheritance as being functionally similar to a powerful include file that you use site-wide.

One of the Page’s most powerful features: Persistence

The Page brings a lot to the table. However, to answer the question of why page methods must be static, we need to focus on persistence.

Consider this example:

<asp:Label runat="server" id="Label1" />
<asp:Button runat="server" id="Button1" OnClick="Button1_Click" />

protected void Button1_Click(object sender, EventArgs e)
{
  Label1.Text += DateTime.Now.ToString();
}

Each time the button is clicked, the label will have the current time and date appended to its current contents. Even this elementary example illustrates how the WebForms Page automatically provides persistence for us.

We take for granted that the Page will provide us this Label1 object after an HTTP POST from the browser. We also assume that it will automatically have a Text property with that Label’s current value.

However, this data would not normally be included in the POST data sent to the server. Only form elements are sent from the browser. The Label renders as a span element, which means that its state is not POSTed by the browser.

So, how does the Page provide us with this data anyway? Persistence.

Understanding how the Page does this

To implement this encompassing layer of persistence, the ViewState was created.

Each time a page is rendered to the browser, the Page serializes the state of its controls and then includes that information in the returned HTML, via a hidden form field named __ViewState. When a postback occurs, this hidden field can then be de-serialized to create an instance of the Page in the same state that it was at the end of the last request.

Oversimplifying, you can envision this constructor being used to re-instantiate the Page, at the beginning of every postback:

Page _Default = new Page(Request["__ViewState"]);

In our example above, the Page created through that process would look something like this after one postback:

This re-instantiation of the Page from the ViewState is what keeps the entire WebForms machine rolling, postback after postback.

What does it mean that a method is static?

A static method is simply one that is disassociated from any instance of its containing class. The more common alternative is an instance method, which is a method whose result is dependent on the state of a particular instance of the class it belongs to.

For example, both of these statements would return precisely the same string, but accomplish it through different types of methods:

// ToString() is an instance method of the DateTime class.
//  Its result depends on the value of each DateTime instance.
return DateTime.Now.ToString();
 
// String.Format is a static method of the String class.
//  Its result is not related to any instance of the String.
return String.Format("{0}", DateTime.Now);

The key difference to understand is that a static method can be called without setting up a proper instance of the class it belongs to.

In a sense, it is a stateless method.

So, why do page method calls have to be static?

If you’re implementing page methods, you’re probably well aware of their excellent performance. They are especially performant compared to the UpdatePanel’s partial postbacks.

They are efficient largely because they do not require the ViewState to be POSTed and they do not create an instance of the Page, while partial postbacks do both of these things. As we now know, a page method couldn’t create an instance of the page even if desired, since the ViewState isn’t provided in the request.

This is exactly why they must be marked as static. They cannot interact with the instance properties and methods of your Page class, because a page method call creates no instance of the Page or any of its controls.

Page methods are roughly equivalent to shorthand for standalone web services. In fact, the ScriptManager even calls them exactly as it would a regular web service.

Conclusion

While forcing the page method to be static is primarily due to technical reasons, I would suggest that it’s actually a good thing. If page methods transmitted the ViewState along with their request, in order to instantiate the Page, they would immediately lose a majority of their benefit.

Forcing the method to be static is necessary to confer most of the benefits of using page methods. Sure, it would be nice to be able to access control properties directly from within page methods, but not at the expense of transmitting volumes of extraneous data about every other control on the page.

Instead of fighting against this limitation, I say embrace efficiency.

Originally posted at: Encosia.

My recent deferred content loading post is an excellent example of that. I was using jQuery for presentational effects, and using a ScriptManager to call a web service. Loading the JavaScript for both frameworks was a bit counterproductive, since the whole point was to improve initial load time.

In this post, I intend to correct that.

First, I’ll cover the two requirements necessary when calling an ASMX web service that’s being JSON serialized by the ASP.NET AJAX extensions. Then, I’ll show you how to do this with jQuery. Finally, I’ll update the deferred content loading example accordingly.

Additional security when calling JSON serialized services

A security feature of ASP.NET web services that are JSON serialized through the ASP.NET AJAX extensions is that they must be requested in a specific way. This is an important deterrent against your services being used in XSS attacks. Scott Guthrie has a great post providing detailed information on the particulars. It boils down to is two things:

• The request must be an HTTP POST request
• The request’s content-type must be: “application/json; charset=utf-8″

When you register and call a web service through ASP.NET AJAX’s ScriptManager, you may safely enjoy blissful ignorance of these requirements. The framework transparently handles everything for you.

However, if you want to use a third party AJAX framework to request the JSON serialized output, you may run into trouble due to these security features.

How to make jQuery jump through these hoops

The solution is a bit less intuitive than using the ScriptManager or what you would normally expect from jQuery. Using jQuery’s getJSON() would make sense, but it unfortunately meets neither of the above security criteria.

The most reliable way that I’ve found is to use jQuery.ajax() as follows:

$.ajax({
  type: "POST",
  url: "WebService.asmx/WebMethodName",
  beforeSend: function(xhr) {
    xhr.setRequestHeader("Content-type", 
                         "application/json; charset=utf-8");
  },
  dataType: "json"
});

Setting the request type to POST is self explanatory.

The beforeSend option is the key. It allows you to handle a jQuery event very similar to the PageRequestManager’s InitializeRequest event. The function is called with a reference to the actual XmlHttpRequest object about to be used in the AJAX call. This allows us to set its content-type to what the ASP.NET AJAX framework requires, just before the request is made.

Note: jQuery.ajax() does have a contentType option, but it will be ignored if there is no data included in the POST. For read-only requests, this will cause the call to unexpectedly fail.

Putting it all together

Now that we know how to call the web service, appropriately modifying the original example is easy. Here’s the new ASPX code:

<div id="Container">
  <div id="RSSBlock">
    <div id="RSSContent" class="loading"></div>
  </div>
 
  <div id="Content">
    <p>Lorem ipsum dolor sit amet, consectetuer adipiscing...</p>
  </div>
</div>
 
<script type="text/javascript" src="jquery-1.2.3.min.js"></script>
<script type="text/javascript" src="Default.js"></script>

Notice that I’ve placed the JavaScript references below the rest of the page’s content. Since browsers block while requesting, loading, and executing JavaScript, it makes sense to defer that until as late as possible. This will serve to further boost the page’s perceived performance.

Finally, the jQuery code to call the web service and appropriately handle its result:

$(document).ready(function() {
  $.ajax({
    type: "POST",
    url: "RSSReader.asmx/GetRSSReader",
    beforeSend: function(xhr) {
      xhr.setRequestHeader("Content-type", 
                           "application/json; charset=utf-8");
    },
    dataType: "json",
    success: function(msg) {
      // Hide the fake progress indicator graphic.
      $('#RSSContent').removeClass('loading');
 
      // Insert the returned HTML into the <div>.
      $('#RSSContent').html(msg.d);
    }
  });
});

Conclusion: Is it worth it?

By using jQuery to call the web service directly, we’ve eliminated over 100 KB of JavaScript and three extra HTTP requests. The ASP.NET AJAX client side framework accounted for over half of the original example’s total download size, and those three extra HTTP requests unnecessarily delayed the progress indicator.

That may not sound like much, but it’s significant. When it comes to loading speed and responsiveness, users do not perceive changes linearly. Fractions of a second make the difference between a site that feels sluggish and one that appears responsive.

A word about web services

Web services are great tools that afford you substantial flexibility. It’s important not to overlook them.

You’ve no doubt seen many AJAX examples that involve using the XmlHttpRequest to request the output of a specially designed page, resulting in CSV or otherwise arbitrarily formatted data instead of HTML. For instance, I’ve noticed that a lot of the auto-complete plugins for jQuery expect this sort of kludge.

I believe that to be a short-sighted and counterproductive way to do things.

Web services have often been maligned in the past, due to the XML bloat associated with SOAP. However, JSON makes this drawback a thing of the past. JSON is very lightweight, making it ideal for structured AJAX communication. With the inefficiencies of SOAP neutralized, I think the power and flexibility of web services cannot be overstated.

For example, if I decide to move my sites from WebForms to MVC, there is a large amount of functionality encapsulated in web services that I won’t have to worry about recoding or redesigning. It’s a great feeling to have that flexibility and ease of reuse.

When used well, I think web services are to WebForms what object oriented programming was to procedural and functional programming.

Try it for yourself: download the source

The full example’s source code (ASP.NET 3.5 required):

Originally posted at: Encosia.

However, what if you wanted to be more thorough and disable all of the buttons on a page?

In this post, I’m going to show you how to do just that. I’ll also show you how to disable only the buttons in the UpdatePanel raising the event. Finally, for the jQuery users out there, I’ll show you how to simplify the process down to one line of code.

Building a demonstration page

To demonstrate this technique, we’re going to need a page with several buttons that generate partial postbacks. An expanded version of the typical Hello World AJAX sample (a la DateTime.Now) will get the job done:

<asp:ScriptManager runat="server" ID="ScriptManager1" />
 
<asp:UpdatePanel runat="server" ID="UpdatePanel1">
  <ContentTemplate>
      <asp:Button runat="server" ID="Button1" Text="Button1" 
        onclick="Button1_Click" />
      <asp:Literal runat="server" ID="Literal1" />
 
      <asp:Button runat="server" ID="Button2" Text="Button2" 
        onclick="Button2_Click" />
      <asp:Literal runat="server" ID="Literal2" />
  </ContentTemplate>
</asp:UpdatePanel>

protected void Button1_Click(object sender, EventArgs e)
{
  System.Threading.Thread.Sleep(1500);
  Literal1.Text = DateTime.Now.ToString();
}
 
protected void Button2_Click(object sender, EventArgs e)
{
  System.Threading.Thread.Sleep(1500);
  Literal2.Text = DateTime.Now.ToString();
}

Using getElementsByTagName to find the buttons

You’re probably familiar with the JavaScript function getElementById and our handy $get shortcut for it, but how about GetElementsByTagName?

This useful JavaScript function returns an array of elements matching a specified HTML tag name. For example, document.getElementsByTagName(’div’) would return an array of every <div> on the page.

Since we know that ASP.NET Button controls render as <input type=”submit”> elements, the solution is clear. We can use a BeginRequest and EndRequest handler to put that to work during a partial postback:

function BeginRequest(sender, args) {
  // Get an array of all the input elements on the page.
  var inputs = document.getElementsByTagName('input');
 
  // Loop through the elements and check each one's type.
  //  if it's a submit type element, disable it.
  for (element in inputs)
    if (inputs[element].type == 'submit')
      inputs[element].disabled = true;
}
 
function EndRequest(sender, args) {  
  // Get an array of all the input elements on the page.
  var inputs = document.getElementsByTagName('input');  
 
  // Loop through the elements and check each one's type.
  //  if it's a submit type element, enable it.  
  for (element in inputs)
    if (inputs[element].type == 'submit')
      inputs[element].disabled = false;
}

Limiting the technique to a single UpdatePanel’s Buttons

A nice feature of getElementsByTagName is that it can be used to search the children of most any element. So, if you’d like to limit this functionality to a particular region of a page, that’s easy too.

An UpdatePanel renders its ContentTemplate as a <div> element. With that in mind, the trick here is to call getElementsByTagName on the <div>’s children instead of on the entire document. To do so, only a few changes to the code are needed:

function BeginRequest(sender, args) {
  // Find the ID of the UpdatePanel raising the partial postback.
  var panelID = sender._postBackSettings.panelID.split("|")[0];
 
  // Using that ID, get a reference to that UpdatePanel's div.
  var sendingPanel = document.getElementById(sendingPanelID);
 
  // Get an array of all the input elements in that div.
  var inputs = sendingPanel.getElementsByTagName('input');
 
  // Loop through the elements and check each one's type.
  //  if it's a submit type element, disable it.
  for (element in inputs)
    if (inputs[element].type == 'submit')
      inputs[element].disabled = true;
}
 
function EndRequest(sender, args) {
  // Find the ID of the UpdatePanel raising the partial postback.
  var panelID = sender._postBackSettings.panelID.split("|")[0];
 
  // Using that ID, get a reference to that UpdatePanel's div.
  var sendingPanel = document.getElementById(sendingPanelID);
 
  // Get an array of all the input elements in that div.
  var inputs = sendingPanel.getElementsByTagName('input');
 
  // Loop through the elements and check each one's type.
  //  if it's a submit type element, disable it.  
  for (element in inputs)
    if (inputs[element].type == 'submit')
      inputs[element].disabled = false;
}

As you can see, it’s basically the same code. It takes a slight bit more work to find which UpdatePanel raised the partial postback, but it’s identical after that.

You can use this same method to target the children of any control that renders as an HTML element. This includes Accordion panels, Wizard steps, TabPanel containers, and many others. If you’re unsure how a particular control renders, using FireBug to inspect your page can dramatically accelerate the discovery process.

jQuery could become your new best friend

If you haven’t tried using jQuery with ASP.NET AJAX before, I highly recommend it. To give you an idea of why, here’s how you could use jQuery to re-write the first example:

function BeginRequest(sender, args) {
  $('input[@type=submit]').attr('disabled', true);
}
 
function EndRequest(sender, args) {
  $('input[@type=submit]').attr('disabled', false)
}

That’s all there is to it. Really.

The UpdatePanel targeted functionality can also be accomplished with similarly concise jQuery code:

function BeginRequest(sender, args) {
  var panelID = sender._postBackSettings.panelID.split("|")[0];
 
  $('#' + panelID + ' input[@type=submit]').attr('disabled', true);
}
 
function EndRequest(sender, args) {
  var panelID = sender._postBackSettings.panelID.split("|")[0];
 
  $('#' + panelID + ' input[@type=submit]').attr('disabled', false)
}

It’s hard not to love that!

Conclusion: We’ve only just begun

In your own implementation, you might want to limit the technique to only a certain, focal UpdatePanel (or other container) instead of any that raises a postback. You might also want to add a few UI improvements, such as changing button text, blurring the buttons, or changing the mouse cursor during the partial postback.

All of this is possible, with only slight modifications to the sample code. In fact, the download below includes the blurring (it makes a noticeable difference in FireFox).

Additionally, keep in mind that this code contains no error handling. I’m assuming that there are buttons on the page, buttons in every UpdatePanel, and that a button inside an UpdatePanel raises every event.

In production, you should definitely be more careful than I have been here. At very least, check that the array is actually an array before trying to iterate over it.

Source download

Finally, here is the source code download for the full demonstration page, including the client script for the second example:

Shameless plug

If you like the idea of having this functionality, but don’t like the idea of having to implement it, then keep an eye out for the next version of PostBack Ritalin. I’ll be integrating this into it as an optional feature in the next release.

Originally posted at: Encosia.

In this post, I’m going to show you one way to circumvent that problem. By placing ancillary content in user controls and delaying their load until the core page content has been displayed, you can drastically improve perceived performance.

When broken down into digestible chunks, the technique is easy to implement and lends your application a level of polish that your users are sure to appreciate. The four steps required to accomplish this will be: building the user control, statelessly rendering the control as HTML, providing progress indication, and using ASP.NET AJAX to request and inject that HTML.

Building the user control

First, we need some slow-loading, auxiliary content to encapsulate in a user control. For this example, that’s going to be a minimal RSS feed reader widget that displays the most recent posts from this site.

The key activity here is retrieving my RSS feed and querying it for some basic information. To expedite this, I’m going to use one of ASP.NET 3.5’s great new features: LINQ to XML. LINQ really makes short work of this normally tedious task. It still blows me away every time I use it.

protected void Page_Load(object sender, EventArgs e)
{
  XDocument feedXML = 
    XDocument.Load("http://feeds.encosia.com/Encosia");
 
  var feeds = from feed in feedXML.Descendants("item")
              select new
              {
                Title = feed.Element("title").Value,
                Link = feed.Element("link").Value,
                Description = feed.Element("description").Value
              };
 
  PostList.DataSource = feeds;
  PostList.DataBind();
}

To display this, I’m going to use another of ASP.NET 3.5’s new features, the ListView control:

<asp:ListView runat="server" ID="PostList">
  <LayoutTemplate>
    <ul>
      <asp:PlaceHolder runat="server" ID="itemPlaceholder" />
    </ul>
  </LayoutTemplate>
  <ItemTemplate>
    <li><a href='<%# Eval("Link") %>'><%# Eval("Title") %></a><br />
      <%# Eval("Description") %>          
    </li>
  </ItemTemplate>
</asp:ListView>

With a little bit of CSS (included in the source download later), this results in something resembling the screenshot to the right.

The ListView comes in especially handy for our purposes here, because it gives you such effortless control over the rendered HTML. When injecting generated HTML into a page, you really appreciate knowing exactly what markup to expect.

Rendering the user control as HTML

The next step is to create a web service that statelessly renders our user control as an HTML string. By statelessly, I mean that we need to render this user control outside the context of an active ASP.NET Page instance, where user controls are normally intended to be used.

To solve that problem, you can create a temporary instance of the ASP.NET Page class, dynamically add the user control to it, and then execute it within the web service’s context. Doing this turns out to be easier than it is to accurately describe:

[WebMethod]
public string GetRSSReader()
{
  // Create a new Page and add the control to it.
  Page page = new Page();
  UserControl ctl = 
    (UserControl)page.LoadControl("~/RSSReaderControl.ascx");
  page.Controls.Add(ctl);
 
  // Render the page and capture the resulting HTML.
  StringWriter writer = new StringWriter();
  HttpContext.Current.Server.Execute(page, writer, false);
 
  // Return that HTML, as a string.
  return writer.ToString();
}

You might worry about creating an entire Page instance for what is supposed to be a performance enhancing technique. At first, I shared the same concern.

However, since our Page instance is created outside of the normal ASP.NET HTTP pipeline and only contains one control, the overhead is negligible. The Page itself is fairly performant compared to all of the other work involved in a typical HTTP round-trip.

Setting up the demonstration page

To demonstrate, we’ll need a page with some fast-loading content to provide contrast. Inside that, we can embed an empty DIV which will be used to accurately inject the user control’s rendered HTML.

<asp:ScriptManager runat="server">
  <Services>
    <asp:ServiceReference Path="~/RSSReader.asmx" />
  </Services>
  <Scripts>
    <asp:ScriptReference Path="~/Default.js" />
  </Scripts>
</asp:ScriptManager>
<div id="Container">
  <div id="RSSBlock" class="loading"></div>
  <div id="Content">
    <p>Lorem ipsum dolor sit amet, consectetuer adipiscing...</p>
  </div>
</div>

As you can see, the RSSBlock DIV is initially assigned a CSS class of “loading”. This is the CSS for the loading class:

.loading { 
  background: url('progress-indicator.gif') no-repeat center; 
}

What this does is give us a bit of rudimentary progress indication. Until we update it later, it will display an empty placeholder with an indicator.

You and I know that it’s a bit of a scam, but your users will never realize the progress indicator isn’t real. I won’t tell if you won’t!

Calling the web service from JavaScript

Now that we’ve got a place to inject it, the final step is to retrieve the HTML rendering of our user control and insert it into the page. ASP.NET AJAX takes all of the hard work out of this step:

Sys.Application.add_init(AppInit);
 
function AppInit() {
  RSSReader.GetRSSReader(OnSuccess, OnFailure);
}
 
function OnSuccess(result) {
  // Remove the .loading CSS from the div, to remove the 
  //  progress indicator background.
  Sys.UI.DomElement.removeCssClass($get('RSSBlock'), 'loading');
 
  // Fill the div with the HTML generated from the user control.
  $get('RSSBlock').innerHTML = result;
}
 
function OnFailure() {
  // Do something if our callback fails.  Retry it, perhaps.
}

Since it’s only a CSS class, disabling the progress indication is as simple as using removeCssClass to remove it from the DIV. For more on removeCssClass, check out my recent article about ASP.NET AJAX’s client side UI methods.

With the animated background removed, we are now free to insert the rendered HTML into the DIV’s innerHTML. The end result is exactly the same as if we had placed the user control inside that DIV, without unnecessarily delaying the entire page load.

Conclusion

I think you’ll find that this technique is very powerful. It allows you to leverage your existing knowledge of ASP.NET and its server controls as a robust templating solution for lightweight AJAX. At the same time, it exudes the kind of professional usability that typically requires more tedious and less maintainable client side coding.

Note that there is not an UpdatePanel anywhere on this page. Using this technique does not require relying on partial postbacks. Not only does that improve performance, but also allows UpdatePanels elsewhere on the page to operate normally, while the deferred content loads.

Check out the full demonstration by downloading the source and running it yourself. You really have to see it in action to truly appreciate it. The download also includes at least one improvement that I didn’t have room to write about in this post. Give it a try and let me know what you think.

Originally posted at: Encosia.

v0.9 (1/30/2008)

• Resolved all remaining issues with master pages. Nested naming containers should no longer cause any issues.
• Added the ability to provide UpdatePanel specific WaitText and WaitImage properties for each MonitoredUpdatePanel.
• Added correct handling for virtual paths in all WaitImage properties.
• Added CSS to change cursor style to “wait” when hovering over the disabled control.
• General improvements to client side code.

The download is available on the PostBack Ritalin page.

I have several more ASP.NET AJAX example posts and at least one book review in the pipeline. January has just been a very busy month so far (it started with our primary web server’s RAID array crashing on New Year’s Eve, so you can imagine). Stay tuned for more of what you’re used to here soon.

Originally posted at: Encosia.

v0.5 (1/11/2008)

• Updated embedded Highslide JS version to 3.3.6.
• Cleaned up Alt and Title attribute handling.
• Added TitleText property to HighslideImage.
• Added LinkTarget property to HighslideImage.

The download is available on the Highslide JS .NET page, as always.

Summary of the changes

Previously, the thumbnail image’s Title and Alt text were hard coded, for reasons I cannot imagine. Now, the base Image control’s AlternateText is respected. If no AlternateText is supplied, then “Thumbnail image for FullImageURL” is used.

Another new property, TitleText, is added to allow you to add a Title to the image. If omitted, no title is added.

Finally, a LinkTarget property is also added in this version. This is a string value that is passed through to the <a> tag that encloses the thumbnail image.

Normally, when a user clicks a thumbnail image with JavaScript disabled, the current page navigates to the FullImageURL. You can use LinkTarget to specify something like “_new”, to cause non-JavaScript users to open the full images in a new window/tab instead.

The future

I’ve begun adding ITemplate support for customizing the control bar. That will hopefully be done for the next build, in the near future.

Aside from that, what other features would you like to see added or improved? I’m completely open to suggestions, as long as they remain mostly within the current scope (e.g. I have no intention of turning it into a full-blown gallery control).

Originally posted at: Encosia.

Specifically, I’m going to show you examples of using addCssClass, getBounds, getLocation, and setLocation to accomplish a few client side UI tasks.

Easily adding and removing CSS classes

A relatively underused feature of CSS allows you to directly apply multiple CSS classes to the same element. For example, maybe you’ve got an online test and want to style the test results to display correct answers in green and incorrect ones in red. This is one way you might do that:

.answerResult {  font-weight: bold; }
 
.correct      { color: green; }
.incorrect    { color: red; }

Answer #1: <span class="answerResult correct">correct</span>
Answer #2: <span class="answerResult incorrect">incorrect</span>

This is a clean solution to the problem. The markup is semantic and avoids repetition by splitting the highlight from the base styling. However, if we need to manipulate this on the client side, it’s going to take more work than is ideal.

Luckily, the ASP.NET AJAX client side framework provides helper functions to alleviate that complexity. DomElement’s addCssClass and removeCssClass are exactly what we need. Assuming the span was given an ID of answerResult, this is all that would be necessary to dynamically add the CSS for a correct answer:

Sys.UI.DomElement.addCssClass($get('answerResult'), 'correct');

I often use this technique in production by creating CSS classes with the same names as the status states of a field’s range of values. Then, when displaying that data, it’s trivially easy to also add some contextual styling with addCssClass.

Determining the size of an element

If you work on client side UI functionality long enough, you’re eventually going to want to determine the size of HTML elements at runtime. This turns out to be no fun at all, if you want to do it accurately cross-browser. Instead of suffering through that ordeal, you can use DomElement’s getBounds method. It returns an associative array with an element’s size and position.

For example, what if you’ve filled a GridView with an arbitrary amount of data and want to find out how tall it is? How would you go about that?

var height = Sys.UI.DomElement.getBounds($get('GridView1')).height;

It doesn’t get much easier than that, does it?

Locating and moving an element

The final methods that I want to take a look at are getLocation and setLocation. After all, the next logical step after finding the size of something is figuring out where it’s at and moving it around.

For example, let’s say you want to move a div, SomeDiv, 75px to the right:

var loc = Sys.UI.DomElement.getLocation($get('SomeDiv'));
 
Sys.UI.DomElement.setLocation($get('SomeDiv'), loc.x + 75, loc.y);

Throw it in a loop and you’ve got yourself a basic animation:

for (i = 1; i <= 75; i++)
{
  Sys.UI.DomElement.setLocation($get('SomeDiv'), loc.x + i, loc.y);
}

Conclusion

You probably aren’t going to use these functions as often as $addHandler or the base type extensions. However, when you do need them you’re going to be really glad you know about them. They save a lot of work, and help to automatically ensure a level of cross browser compatibility that is tedious to constantly write from scratch.

Originally posted at: Encosia.

I would like to sincerely thank every one of you for making this past year such a blast. Without all of your great comments, emails, links, and kicks, I doubt that I would have been motivated enough to keep putting in all the work that it takes to run this site.

I would also like to especially thank Joe Stagner, Scott Guthrie, and the DotNetKicks community for their considerable support this year.

2007’s most popular posts:

Easily refresh an UpdatePanel, using JavaScript: Even to this day, it’s one of my most viewed posts. The __doPostBack technique is something that I’ve been dogfooding extensively since, and I can say without hesitation that it’s a great way to programmatically trigger server side events from client script.

I owe Joe Stagner big time for the popularity of this post. Thank you, Joe.

Why ASP.NET AJAX UpdatePanels are dangerous: This post exploded my traffic. It seemed to really strike a nerve with a lot of people, which wasn’t my intent at all. However, I still absolutely stand by every word of the post. Continuing real-world experience has only served to reinforce my opinion on the matter. Just a cursory search of the ASP.NET forums backs it up strongly as well.

Are you making these 3 common ASP.NET AJAX mistakes?: I didn’t expect this to be a popular post. If anything, I felt like it was rushed and not as complete as I would’ve liked. However, it’s my third most viewed page for the year, so who am I to judge?

Seamless inline text editing with ASP.NET AJAX: This one, I was really proud of. I was tired of seeing all the flashy, lightweight techniques on other platforms, while we all wallowed in UpdatePanel bloat. So, I wanted to demo something that was heavy on the client side magic and didn’t rely on partial postbacks at all. Goal achieved!

I owe ScottGu for a lot of this post’s popularity. Thanks, Scott.

Display data updates in real-time with AJAX: I don’t know if it was due to a bad title or what, but this one was a bit of a sleeper. It drew almost no interest at first, but its popularity eventually began to grow rapidly after a month or two.

I plan on reprising this post with a completely client side solution soon, using no partial postbacks at all. I’ve been using that technique in production, gaining amazing performance gains of 20-80x over partial postbacks to render GridViews.

Honorable mention

The post that I most wish had done better than it did is Easy incremental status updates for long requests. It’s something that I see people struggling with almost daily on the ASP.NET forums, and I wish that I could have put the post in front of more eyeballs than I did.

I hold out hope that it will gain popularity over time, like the real-time updates post did. Until then, I suppose I’ll just have to keep watching the ASP.NET forums and pointing people to it when they’re in need.

Contest winners

Okay, I feel a bit like a news weatherman, putting the part you actually care about at the end of the post. I know this is what you’re really interested in, so let’s get on with it.

Winner #1 (Comment): Clinton Gallagher

Winner #2 (RSS entry): Nichole Dugan

Winner #3 (Email list): JStengel@*****.***

Congratulations to the winners, and check your email. I’ll be in touch soon.

To those who didn’t win this time, stay tuned. The success of this week’s contest has definitely paved the way for more in the future.

Thanks to our sponsor

Again, I would like to thank Manning Publications and Alessandro Gallo for providing these books to give away. Without them, none of this week’s fun would have been possible.

If you didn’t win, I hope you’ll still consider picking the book up. It’s a great book to begin with, and you just have to love a company that supports the .NET community like this.

I hope you all have a safe and happy holiday, and I’ll see you back here next year!

Originally posted at: Encosia.