Total votes: 0
Print: Print Article
Please login to rate or to leave a comment.
Published: 23 Oct 2008
Brain Mains talks about rendering the UI of a control with ASP.NET AJAX.
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
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.
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.
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
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
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
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
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.
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.
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.
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.
Please login to rate or to leave a comment.