Published: 23 Oct 2008
By: Brian Mains

Brain Mains talks about rendering the UI of a control with ASP.NET AJAX.

Contents [hide]

Introduction

So far we've looked at the way to develop a custom control using the ASP.NET AJAX framework. I want to turn my focus now toward the various ways the UI of a control can be rendered. Server-side rendering isn't the only way this can be done anymore, especially since JavaScript is involved and there is a client lifecycle available.

ASP.NET AJAX framework Series

  • Part 1 Overview of the client portion of the ASP.NET AJAX framework.
  • Part 2 Overview of the client portion of the ASP.NET AJAX framework.
  • Part 3 Overview of the client portion of the ASP.NET AJAX framework.
  • Part 4 Overview of the server portion of the ASP.NET AJAX framework.
  • Part 5 Overview of rendering the UI of a control with ASP.NET AJAX.
  • Rendering on the client

    JavaScript has full capability to render the user interface on the client. In some ways, this is a good thing. The challenge with data-intensive web sites often becomes an issue with the volume of data being displayed. With latency always an issue, pages may take a longer time to render and load for the user, which may be unacceptable to them. To offset this issue, it may become a better strategy to push the data down to the client or retrieve the data on the client-side, rather than rendering on the server-side.

    Right now, there isn't a built-in way to do this. There are a couple of projects coming on board that implement these features. For instance, future versions of the ASP.NET AJAX framework contain more data-bound controls that work on the client side. The AJAX Data Controls project is another project striving to create data controls that operate on the client side, providing a lot of dynamic client-side features. I'm also working on a project called Nucleo.NET that will contain client-side data binding features; my framework is more geared toward input/list/tabular controls, with some data controls included.

    All of these frameworks do some rendering on the client, which pushes the work off to the client rather than on the server. This can be a good thing, as long as the browser settings are supported (meaning that the user can turn off JavaScript, which is a very bad thing in this scenario).

    JavaScript supports dynamic rendering of the UI. This can be done in one of two ways: rendering an HTML string, or using the document object model (DOM) to create the HTML tags. Both options have their pros and cons. Let's begin by looking at ways to create objects using the DOM. The document object has a createElement method just for this purpose. Check out the code below that creates a checkbox.

    Listing 1: Creating a checkbox dynamically

    A checkbox is an INPUT element with a type of "checkbox." The document object model approach uses the document.createElement method to create the object, followed by the setAttribute method to set the actual values. Every DOM element has an appendChild method to append children to its childNodes collection, presenting it in the UI.

    The alternative approach to this is using a string statement. Below is the alternative to the previous approach, creating a string using the ASP.NET AJAX StringBuilder class.

    Listing 2: Creating a checkbox as a string

    Both options yield the same results on the screen: showing a checkbox in its checked state.

    Binding Data

    Let's take this scenario into a client data-binding scenario. Imagine using the following data source for a client data-binding scenario, as in the following:

    Listing 3: Sample data source

    The above data source can be easily used to create a dynamic table on the client side, as in the following:

    Listing 4: Dynamically generating a table based upon a data source

    As you can see, because JavaScript can work with objects, an interface can be rendered via JavaScript. In this sample, this code is embedded in a page, but this could easily exist in the initialize method of an AJAX component as well. Conceptually, the code and the approach is the same.

    Working With Tables

    Previously, when creating a dynamic table, I used the childNodes collections to work with the table. But that isn't the only approach. Instead, I've outlined an alternative approach in this section. The TABLE, THEAD, and TBODY elements have specific properties and methods for working with the table structure, like the rows collection of TR elements and an insertRow method, all shown in Figure 5.

    Listing 5: Creating a table using an alternative approach

    The TR element has some useful features too. It has a cells collection, representing each TH or TD cell in that row. The rows and cells collection is nice because these collections only contain TR or TH/TD elements, and not additional elements that may be in the HTML markup (or if you use FireFox's FireBug utility, you'll see that childNode also contains literals too).

    So these collections make it handy to work with table. There are other handy methods, like insertRow above, or deleteRow for deleting rows, or even deleteTHead, deleteTFoot or insertCell.

    Working with Styles

    The Style object is a convenient way to apply styles to a region of the underlying HTML output. A style can be transformed into a CSSStyleCollection collection, which is subsequently passed as a string to the client using the following code in the description process. Obviously this is used in an AJAX component, because of the use of the descriptor.

    Listing 6: Converting a Style to a string

    On the client, this style is a string that is in the format of attribute:value pair separated by semi-colons. These styles can be applied to most HTML elements through its style property. The style property can't be set directly; the style property is an object that doesn't directly assign to strings. The two approaches I've seen to assign a style string to an object via:

    Listing 7: Setting a style on the client side

    I ran a quick test against the latest versions of the internet explorer, firefox, safari, and opera browsers. Internet Explorer is the only browser that doesn't support both approaches to setting the style, not supporting the setAttribute approach of passing a string. In the other three browsers, both approaches work fine. I did a little research and found that setAttribute was a recommended approach for older browsers, as I believe cssText was introduced later.

    Script Manager Assistance

    The script manager contains some additional useful features for rendering on the client. It can register hidden fields using the ScriptManager.RegisterHiddenField static method. It can register some scripts registered on the server-side, and pass data to the client. I've used this approach to pass data to JavaScript variables through an assignment in the script. This can be easily done by adding a client variable and doing the following on the server:

    Listing 8: Passing a querystring value to the client

    Of course this could be anything, as long as the statement can be rendered easily. This is equivalent to the <%= %> approach (like $get(<%= TextBox1.ClientID %>);) you see to get the real ID of a control. In this case, we're passing serialized data to the client.

    The thing to watch out is where the _key variable is used, because placement is important. If the variable used in the ASP.NET AJAX client load event, the variable will contain the correct value. This is because load runs after the script initializes. The load event is delayed in a sense meaning that load runs after the script have been initialized. If the _key variable is used immediately after declaration, this approach won't work because the assignment with RegisterStartupScript happens near the end of the page, and thus _key would be null. So placement is key, and JavaScript can be tricky in that sense.

    In the following example, the value "1" returned to me.

    Listing 9: Sample Code

    The Benefit to Client Rendering

    So why even mention rendering on the client? There isn't always a need to render on the client, but picture this situation: as applications get more complex, the desire to add more and more information increases. What this means is that the size of HTML content posted from server to client in a typical ASP.NET application increases. This can be problematic because .NET controls render a lot of content, sometimes excessively, and that content is what gets sent over the wire.

    It's not too long before the content gets so big that the users of an application complain of its speed. By rendering HTML content via JavaScript, this minimizes the total payload over the wire because there isn't as much HTML content when the page renders and served up from the server. The data can be passed via web services, so only the raw data itself, and not HTML markup gets passed to the client, and at a different time than the rendering.

    The challenge becomes avoiding unnecessary postbacks because served-up content rendered on the client isn't remembered in ViewState, since ViewState is a server-based mechanism. There are some alternatives that can be used (using hidden fields to store data or trying to give it an ID so the control posts back to the LoadPostData method), but overall if a postback can be prevented, that would be the best approach.

    Conclusion

    Content can be rendered on the client, rather than the server, and this approach is sometimes a good one to take. As applications grow, they tend to render and consume a lot of data that increases performance issues. An alternative can be to render the content on the client, while only passing the data via web services to the client, reducing the overall payload.

    Rendering on the client may be a challenge, but I've included some steps to understand how it works, how styles can be applied. Look for more in the future with ASP.NET AJAX 4, which will support expressions, client-side templates, and more features.

    <<  Previous Article Continue reading and see our next or previous articles Next Article >>

    About Brian Mains

    Brian Mains is an application developer consultant with Computer Aid Inc. He formerly worked with the Department of Public Welfare. In both places of business, he developed both windows and web applications, small and large, using the latest .NET technologies. In addition, he had spent many hou...

    This author has published 73 articles on DotNetSlackers. View other articles or the complete profile here.

    Other articles in this category


    Animating a Web Form using ASP.NET AJAX
    In this article you will learn how to animate a webform using asp.net ajax.
    Jquery Ajax
    JQuery makes communicating with the server very, very easy. JQuery uses get(), getJSON(), and post(...
    jQuery Deferred Objects Promise Callbacks
    jQuery Deferred/Promise objects untangle spaghetti-like asynchronous code.
    jQuery in Action 2nd edition: Queuing functions for execution
    This article is taken from the book jQuery in Action, second edition. This segment shows how you can...
    Test120Jan
    This is my custom article

    You might also be interested in the following related blog posts


    MSDN Guidance on ASP.NET MVC vs WebForms and its Impact on my EF + ASP.NET Work read more
    Introducing SharePoint 2010 Training at U2U read more
    TIP: How To Generate a Fully Qualified URL in ASP.NET (E.g., http://www.yourserver.com/folder/file.aspx) read more
    Why not Classic (Legacy) ASP? read more
    Creating a Filtering User Interface With jQuery In a Web Forms Application: Part 1 read more
    Make SharePoint 2007 Act Like SharePoint 2010, Updated read more
    GiveCamps Get a new Sponsor read more
    Announcing the WebsiteSpark Program read more
    Gaia Ajax 3.6 Alpha released: Ajax GridView and Adaptive Rendering ++ read more
    Scenarios for WS-Passive and OpenID read more
    Top
     
     
     

    Please login to rate or to leave a comment.