asp:Cover Story
LANGUAGES: VB .NET
ASP.NET VERSIONS: 1.0 | 1.1
Create Rich-Looking Apps
Yes, it's possible to get a rich-client look in your thin-client Web apps.
By Brad McCabe
Developers today face new challenges as technology and economic pressures change the once familiar IT landscape. The entire industry is under pressure from business units driven by the bottom line to deliver more value and to "do more with less." One strategy many development groups have adopted to achieve these goals is thin-client, or browser-based, delivery of applications with ASP.NET.
This thin-client approach lets companies avoid the issues surrounding versioning, deployment, and the infamous DLL hell. But it comes with a price. Users are accustomed to the rich and robust graphic interfaces delivered by Windows client-server applications, and it is a lack of a real-time, engaging interface that often becomes the biggest inhibitor of ASP.NET-based applications in numerous organizations and groups.
A well-designed and accepted interface is a must for most applications that corporations develop. The design and development of the presentation layer can take more than one-third of any project's entire development cycle. Upon seeing and interacting with this interface, users develop their first impressions of the application and shape their views on the success or failure of the development effort. Thanks to many innovations in ASP.NET, you continually can deliver this rich-client look and feel end users demand while still delivering the lower Total Cost of Ownership (TCO) IT managers seek fervently.
To achieve this rich interface, you need to slip behind the basic "drag-and-drop" applications you can create with ASP.NET and instead think outside the box. By applying the ideas and principles of this article, you can produce stunning interfaces.
Remember that ASP.NET is a technology, and like all technologies it has right and wrong times to be used. For creating graphics-intensive or extremely high-performance applications, Windows-based applications with No-Touch deployment might be a better option. Organizations must use due diligence and evaluate all the technical options .NET provides because a one-size-fits-all approach to application design is not always the correct answer.
Real-Time Interaction is Key
One of the first steps to creating a rich-looking interface is to provide the real-time interaction and feedback users expect. Visual Studio .NET's standard controls provide most of these features and services via a postback to the server. This postback introduces latency to your application, both from the network and the Web server, which slows the responsiveness.
Performing as many actions as possible on the client side is one of the keys to improving both the real and perceived speed of an application. Some ASP.NET controls such as validators provide this client-side support by default. Others such as the DataGrid, however, require either some work or outright replacement to enhance this support.
One of the easiest ways to enhance server-side controls functioning on the client is to attach custom JavaScript functions to them. One easy way is when the control lacks a server event with the same name, simply put the client event on the tag:
When you add the name of the client event, Visual Studio .NET underlines the attribute as a warning. This is natural. Visual Studio .NET is notifying the developer properly that an incorrect attribute has been added. When the ASP.NET engine renders this page to the browser, these "foreign" tags are passed - unchanged - to the browser. The onMouseOver tag works like a standard HTML attribute and hooks the event to the defined function. This simple addition to the ASP Image control lets you perform more interactive events and interfaces with the end user in real time.
Hook Up Client Events
This approach works well for situations where the client-side event name does not conflict with a server-side name or when you want to hook up a client-side event at design time. But how do you handle other scenarios?
Using a server-side control's Attributes collection, you can hook up client-side events easily to meet these other challenges. In any event, such as the page load event, you could add basic code such as this:
Button1.Attributes.Add("onclick", "alert('Clicked');")
In this simple example, which is included in this article's downloadable project file (see the Download box for details), when you click on Button1, an alert box is displayed on the client immediately. The real power of this method is that client events, or other attributes, are added dynamically while processing server-side code.
The following lines of code in the page load event can turn a rather boring ASP.NET image button into an interactive button with mouse-over and mouse-out effects:
Me.ImageButton1.Attributes.Add_
("onMouseOver", "document.all_
['ImageButton1'].src=_
'Print_Red.Gif'")
Me.ImageButton1.Attributes.Add_
("onMouseOut", "document.all_
['ImageButton1'].src=_
'Print.Gif'")
The previous example uses two simple lines of JavaScript code that you place in the attributes to generate this HTML:
id="ImageButton1" onMouseOver=
"document.all['ImageButton1'].src=
'Print_Red.Gif'" onMouseOut=
"document.all['ImageButton1'].src='Print.Gif'"
... />
If you're going to use this technique on more than one image, the JavaScript to change the image source property would best be encapsulated into a standalone function and called from the mouse-over and mouse-out events.
You also can use client-side JavaScript to interact with server-side controls after they have rendered to their corresponding HTML tags. For example, what if you wanted to disable the contents of an ASP panel control without a postback? Create a basic panel with a few controls inside it, similar to this:
Label1
Label2
Now add either a standard HTML input button with the listed JavaScript code to the page or an ASP.NET button control and attach it to the onclick method with one of the approaches discussed previously:
value="Button" language="javascript"
onclick="document.all['Panel1'].disabled =
'disabled';">
When this page runs, it renders the two lines of text and the command button. So when a user clicks on the command button, the content of the panel (now a DIV tag) is disabled.
Many developers assume the need for knowledge and understanding of JavaScript and DHTML would go away when they migrated to ASP.NET. But as these simple examples have shown, ASP.NET only reduces the need to know JavaScript to create a quick and basic application. To create a rich and responsive application, however, you still must roll up your sleeves and dig into the HTML world.
Buy, then Build
In addition to extending the standard inbox controls with custom JavaScript, you also can choose from a wide array of advanced controls from Independent Component Publishers (ICPs). Today, you can choose from many great toolsets to add that rich-client look and feel to any ASP.NET application with features such as toolbars, menus, trees, interactive charting, and sophisticated grids and tables. Component toolsets from premier ICPs not only provide many more features than you can get with Visual Studio .NET's built-in controls, but these features require little coding or maintenance.
Like the Visual Studio .NET server-side components, ICP products create standard HTML and JavaScript to render to the browser. This means you can create every feature found in these controls themselves with their own custom code. Except for the most demanding situations and applications, however, this makes little financial sense given the current market price and quality of presentation-layer toolsets.
When evaluating components from any ICP, you need to look for certain key requirements in the toolset, such as an advanced client-side object and event models. Some ICPs have done extensive work to provide large quantities of built-in client-side events to save you the time of attempting to wire these up to built-in components, such as providing AfterSelectChange, BeforeEditEnterMode, and CellClick handlers. These rich object models and events make it much easier to write less client-side JavaScript than the standard controls, and they offer more functionality (see Figure 1).
Figure 1. The use of advanced
Independent Component Publisher (ICP) components lets you create your own rich,
engaging interfaces while minimizing your effort. Notice the desktop-like
features such as the dropdown form for editing the grid, movable menus, and
tabs.
Other features to look for when evaluating components are a complete integrated toolset or the availability of source code from the vendor. Obtaining the source code not only gives you complete asset security, but it lets you extend and customize the component easily as well.
Reduce Postback Impact With IFrames
Besides the use of client-side events and functions and the integration of advanced components, you also need to think about the overall feel of your applications. Although client-side JavaScript can reduce the need for postbacks greatly as well as the related screen flicker and latency, sometimes you still must make a trip back to the server to perform an action.
One way to reduce the impact of this postback is to use an IFrame, so long as you are certain the app will be used only on up-level browsers. Many corporations are standardizing their browsers to be up-level, using applications such as Internet Explorer 5.0 and 6.0, which makes this a viable option for most intranet developers.
The IFrame is an inline frame; in other words, a window within a Web page. When given a value on its name attribute, you can manipulate the IFrame using JavaScript. The IFrame exposes a source property (SRC) that, when changed, reloads the page from the server. For example, a system developer can use the IFrame to create a powerful Explorer-style intranet interface. A menu and toolbar can be positioned across the top of the page (similar to a standard Windows application), and a tree or other navigation tool can be applied to the left-hand side of the page (see Figure 2).
Figure 2. The chart and grid region
on the right side of the page is in a separate IFrame region. When a user
selects a node on the tree to the right of the source (SRC) property, the
IFrame is updated.
With the basic navigation components in place, you can position an IFrame in the right corner of the screen. Then, with a few lines of JavaScript, the menu and tree components can update the IFrame's source property. This causes the right corner only to refresh, thus avoiding any screen flicker or browser-back issues. Because the entire page was not reloaded from the server, preserving the state of the tree and menus isn't required. You can view a smaller sample of this in the downloadable project file; the sample uses three simple buttons to demonstrate updating the contents of the IFrame window without posting back the entire Web page.
You can extend other basic concepts to create a desktop feel for your ASP.NET application, such as hiding the browser's navigation and command buttons - an easy operation with browsers such as Internet Explorer 5.0 and higher. One way to do this is to create a simple default.aspx page with nothing in it but a couple of lines of JavaScript code. Then add this line of JavaScript to the client-side window's onload event:
window.open("/lmain.aspx","YOURAPP_MAIN",
"height=" + (window.screen.availHeight - 60) +
", width=" + (window.screen.availWidth - 14) +
", top=0, left=0, menubar=0, location=0,
resizable=1, status=1");
When a user accesses this page, a new browser window containing the lmain.aspx page is opened automatically without any menus or toolbars, and it expands to consume almost the entire screen (see Figure 3).
Figure 3. The new Microsoft Customer
Relationship Management (CRM) system is an ASP.NET-based application. With
careful design and basic tricks, such as hiding the browser buttons, Microsoft
made the application feel just like a Windows Forms application.
You even can take this one step further by adding a couple of additional lines to the client-side window's onload event:
if (window.name != "YOURAPP_MAIN")
{
var oMe = window.self;
oMe.opener = window.self;
oMe.close();
}
The preceding six lines of code first check to ensure this code is not running inside the newly opened windows (titled YOURAPP_MAIN). Once it has been confirmed that this is not the new window, the JavaScript function gets a pointer to itself and closes. This leaves your application running full-screen with no sign of the original browser window.
Create Custom Context Menus
Another useful event Internet Explorer exposes to help ASP.NET developers deliver richer applications is the OnContextMenu event of some HTML tags such as span (see Figure 4). You can use a simple span tag to wrap an entire page or individual server controls like this:
In this example, right-clicking on Box1 or Box2 invokes two different right-click menus. Creating this right-click menu and positioning it at the exact location of the right-click is a bit tricky because the coding for it can get complex. In this case, you might be better off turning to component vendors for this functionality if you have neither the time nor inclination to do this yourself. (Look for more information about how you can build a right-click menu of your own in an upcoming issue of the asp.netNOW newsletter; see the More in asp.netNOW box for details.)
Figure 4. Using Internet Explorer's
OnContextMenu client event, you can customize and override the browser's
right-click menu to respond as a Windows application would, and you can provide
context-specific help or functions.
It now should be clear that you can create very interactive and compelling application interfaces with ASP.NET that rival a Windows application. There is no one magic bullet tip to creating these advanced interfaces; rather, it's a process of combining the best of ASP.NET and standard Web technologies such as DHTML into one complete application. By combining these technologies, ASP.NET has made tremendous strides toward reducing the complexity and challenges of creating great-looking Web-based applications.
The sample code in this article is available for download.
Brad McCabe is the technical evangelist for Infragistics. He also has been a systems architect and consultant for Verizon Communications and many other clients, and he was a leading .NET evangelist within Ajilon Consulting. His primary interests include ASP.NET, Windows CE .NET, .NET Compact Framework, and Microsoft's networking technologies. E-mail him at [email protected].
Tell us what you think! Please send any comments about this article to [email protected]. Please include the article title and author.
