Trends in Rich Client Development

1. Trends in Rich Client Development Presented by Christopher M. Park CTO, Starta Development, Inc. http://www.startadev.com/ Triangle Technology Executive Council September 11, 2007

Introduction(3)

Contemporary Rich Clients(9)

The Dark Side of Progress(15)

Cross-Platform Issues(27)

Desktop Development(42)

The Client Side of Web Development(54)

The Server Side of Web Development(71)

Conclusion(92)

Q&A(94)

Starta Development, Inc. is a very small application service provider, orASP , targeted at the Affordable Housing Industry.

Christopher M. Park has been with Starta since 2001, and became the companys head software architect in 2003.

On the server side, Starta works primarily with Microsoft technologies such asASP.NETandSQL Server , but in many cases weve found the standard way of handling these technologies to be inadequate.

Weve therefore taken the initiative to create our owncustom rich client web platform , which we call the Business Operating System, orBOS .

The BOS is coded entirely inC# ,JavaScript / DHTML , andTSQLfor Microsoft SQL 2000.

The bulk of our platform is designed for aweb interface , but in the past weve also had a Desktop-based version that rode on top of the same underlying server architecture.

We dropped the desktop version because it was redundant and time consuming to maintain, and we found a better way to handle full rich-client-style access to the desktop (see below).

We still retain Desktop-based elements, such asOutlookandOfficeplug-ins, TWAIN scanner software, and anInternet-Explorer wrapperthat allows us full rich-client-style access to the desktop while still using our web-based interface.

The primary purpose of the BOS is to provide a platform for Starta to create and host modulardata ,reporting ,document management ,CRM , andproject managementtools (among many others) under the umbrella of a single central system.

To accomplish this efficiently and on a limited budget, we had to design custom solutions for handlingclusterability ,Remoting/SOAP ,state management ,HTTP request pipeline control ,Queuing ,Scheduling , and a lot more.

Discuss theproblems and challengesfacing developers of contemporary rich client applications.

Look at what some of the major software shops have been doing lately, as well as some of thesolutionsthat Starta and other companies have come up with over the past six years.

And with that, lets move into the presentation proper...

Rich clients were once synonymous with desktop applications.

Only the desktop platforms had advanced graphics, drag-and-drop, file system access capabilities, etc.

AJAX ,DHTML , and frameworks likeFlashhave extended the rich client concept to the Web.

Client-side file system access is still extremely limited, but the other requirements of rich clients are readily filled.

Client-side memory utilization or processing efficiency is not always the best with Web applications, but they are exceedingly easy to deploy.

Now, having a rich client is mostly a matter ofdesignrather than underlying platform.

Googles online office suite offers similar functionality to Microsoft Office, but in anentirely web-based interface .

No extra components not even Flash or ActiveX are needed for the base functionality.

GooglesAJAX implementationswith both their Docs program as well as their services like GMail are among the most advanced on the Internet.

However,lower performancewith large documents, and theinconvenience or unavailabilityof some features, make this not a completely ideal solution.

Googles Picasa is an excellent example of the limitations of purely web-based offerings.

Advanced servicessuch as multi-upload, scheduled uploading, automatic image discovery on the client computer, and CD burning areonly possible using their

desktop versionof the software.

However, the primary means for managing the web sharing portions of the program are still web-based.

The perfect web-based rich client application?

Virtuallyno loss of functionalityversus desktop-based counterparts.

Takesfull advantage of its server-based nature spam and virus filtering, incredibly fast search, etc.

Usabilityis more important now than ever.

Users expect to be able to look at a system and immediately understand what is going on.

Prettinessis also demonstrably important to user acceptance of products.

However, when prettiness trumps functionality or performance as in Windows Vista users are not forgiving.

Response timeis still key.

Part of the success of Google is not just their ingenious (and secret) server model, but also their clear, simple, and above allefficientinterface.

The balance between too much and too little functionality.

Overwhelming new users vs. irritating expert users.

Microsoft Office combats via its 2007interface overhaul .

Adobe Photoshop combats via its Elementslightweight version .

Mozilla FireFox combats viaoptional add-ons .

Starta combats viaextreme configurability .

Smaller lists of options

Easy mix of icons and text

But, new groupings for users to learn

Too Many Options!

Tree Menus

Dynamic Toolbars

Multi-Panels

Detail Windows

Limited base functionality

Add-ons from community and core developers

Keeps base install small and simple

Startas approach is to offer massive amounts of functionality, but to hide most of it by default.

Client administrators can then enableonly those functions that they want , and roll out functionality to their userswithout causing overload .

This customization applies to our sidebar nodes, individual page fields, and even the values in many dropdowns (among others).

Using these tools, our clients often use the same underlying objects for many different purposes, and tailor them to the individual needs of their various departments all that has to change is the configuration .

On the left is a partially-expanded view of the full sidebar of Startas development entity.

On the right is that same sidebar, butcustomizedto a specific clients needs.

Users invariably get lost when exposed to the full feature set on the left, but generally find adapting to a partial rollout much easier.

Even the view on the right was rolled out over time, and it actually is continuing to grow as this particular client engages more of its user groups.

Function taking a backseat to Form?

Tabs replacing MDI seemingly everywhere.

When all you have is a hammer, everything looks like a nail.

Interface Simplicity obscuring advanced functionality.

Easier for the novices, harder for the experts?

DAZ 3Ds Bryce software (formerly of MetaCreations and then Corel) is a great example of this issue.

Hardware usage of some modern software, such as Windows Vista, is egregious.

Microsoft trying to catch up in the Apple-driven generation of pretty apps but at what price?

An excellent example of a software product that has advanced capabilities, but which is soaimed at the novice-level usersthat experts are largely turned away.

The power of many of the rendering tools in this program is immense, and certain aspects like texturing and terrain height mapping are extremely simple and intuitive, butmany advanced features are buried

in sub-menusso that they are much more difficult to use in this program than in most other 3D programs.

Also: remember that complexity is relative!

For DAZ 3D, fortunately, this exactlyfits the target marketthey are aiming for. They have more expensive, more professional, offerings for expert 3D modelers.

In their case, this is not a design flaw, but rather a valid design choice.

The interface of theolder versionof Microsofts SQL Server was actuallymore usablein many ways.

In 2005, you can only see/edit one only item at a time thanks to tabs replacing MDI.

In 2005, the awkward mechanism for updating content reflects Microsofts programmers needs, not the needs of users.

Often this can be literal middleware applications that connect discrete applications and systems together.

This is generally in response to another core issue: too-little interoperability in the underlying systems being connected.

However, this can also be a problem withthird-party componentsor platforms that are commonly used as time savers.

This can result in multiple layers of inefficient translation code that serves more purpose at design time than at runtime.

While there is certainly a benefit to using prefab components and not reinventing the wheel, in many cases a good software architect can create a modular object-oriented design that isefficient both at design-time and at runtime .

Prefab components such asDotNetNukehave to be generic enough to accomplish many different purposes other than the ones your company is actually trying to accomplish.

This can lead to a massive drop in efficiency.

Conversely, components such as the native-.NET Office management libraries offered byAsposeare sofocused and well-designedthat it would be a fools errand to try to duplicate even a portion of what they are doing for a single project.

The problem is that too many component vendors offerings do not meet this criteria.

Windows vs. Linux vs. Macintosh

Java or .NET (intermediate code languages)

.NET has limited support on non-Windows

Java has some differences between OSes

Flash (interpreted content frameworks)

Wonderfully consistent on every platform

Some limitations as an application framework

Pure web-based applications

Cross-browser compatibility issues

Limited ability to interact with client resources

Web Browser Wars

Most Functional & Flexible:

Internet Explorer 5.5+ (or even 6.0+)

FireFox 1.5+ (or even 2.0+)

Safari 3.0+

Other Alternatives:

Netscape (uses engine of IE or FF)

Opera (standards-compliant to a fault)

Konquerer and other small-time implementations

Version5.01and before are almost unusable for a modern interactive UI.

Version5.5adds a baseline feature set that makes for excellent interactive UI.

The Macintosh version 5.5 is not at all the same as the Windows version. It is best avoided.

Version6.0adds better CSS support, some new JavaScript options, and fixes some glitches from 5.5.

Version7.0adds more user interface improvements, but from a programming standpoint offers little new that is compatible with prior versions or other browsers.

If you are developing in a homogenous IE7.0 environment (as Microsoft no doubt hopes you will), there are a number of extremely useful enhancements targeted at rich client development.

There are counterparts to most of these enhancements in FireFox 2.0, but the code interfaces are different. If you want to support IE7.0+ and FireFox 2.0+, youll need to add wrapper methods.

There is a horriblememory leak in IE7on most AJAX-based web pages.

It can take days or weeks to become apparent, but try leaving GMail open in IE7 for some time, and you will notice literally hundreds of megabytes lost.

This issue gets little press for unknown reasons, but Microsoft has acknowledged it in blog posts.

The issue is a very fundamental problem with how IE separates the HTML and JavaScript memory spaces and garbage collectors an easy fix probably does not exist.

Behaviorswere a touted addition to IE 5.5, and are supposed to help ease rich client development.

However, these suffer from a gradual memory leak, at least in IE5.5 and 6.0.

You can see this leak in the tree view on the side of Microsofts own MSDN website, though it takes a fair amount of cross-clicking before it is really apparent.

Dont use them behaviors lock you in to IE while giving you a memory leak and not giving you any new functionality that plain old JavaScript cant replicate.

The one good use that some people have for Behaviors is making IE more consistent with other browsers such as extending the hover CSS property beyond just hyperlinks.

This same functionality can be achieved with just JavaScript, however, for all browsers and without risk of a memory leak.

All installations of a given version of IE arenot the same , unfortunately.

For inexplicable reasons, even in centrally-managed corporate environments, there are often corrupted installations on some computers.

In Startas experience, there has been about 1 in 400 corrupted installations of IE 6.

The only foolproof option when an installation of IE is corrupt is to reinstall the operating system (or reapply the workstation image).

This alone is an excellent reason to support other browsers beyond just IE for your rich web services.

Works the same on Windows, Linux, and Macintosh!

The core Mozilla browser is different than the FireFox browser, even though both run on theGecko engine .

FireFox includes a Quirks mode that allows it to be much more compatible with IE-centric web pages.

Version1.0.xand before is pretty limited for an interactive UI. Not recommended.

Version1.5.xand up is when FireFox really came into its own as a viable platform for cross-browser rich web client development.

Version2.0.xand up adds a number of new rich client programmability enhancements similar to those in IE7 (although with different interfaces).

These arent backwards-compatible or compatible with other browsers, unfortunately.

Even FireFox 2.0 running in Quirks Mode has some very frustrating differences from the IE code model.

These differences are closer to the officialW3C specifications , but still not exactly based on them.

This can make programming to both browsers frustrating and more time-consuming than it should be.

This is why having a centralized DHTML code generation library is so important.

This is the de facto browser on theMacintosh .

As of version 3.0, there is now a version for Windows.

The Safari engine can work very similarly to the quirks mode of FireFox this makes it comparatively easy to support in addition to the main two browsers.

Thecross-browser JavaScriptexample below shows mandatory coding differences between IE and FF/Safari.

By checking for the existence of an IE-only property or method (in this case window.createPopup), we can determine what browser logic to use.

Some systems opt to haveseparate .js source filesfor IE and non-IE browsers.

In these cases, the server sends back a different script reference depending on the reported browser.

This approach works, but tends to create a lot of duplicate code, since actually 60%-80% of most JavaScript code is compatible between IE and FF.

The first branching approach I outlined causes larger .js files to be sent to the client than the split-file approach.

However, since these files are cached on the client anyway, the performance difference is almost nothing, and the branching approach is much easier for programmers to maintain.

Theserver-side C#example below shows another technique for handling cross-browser compatibility.

The browser automatically reports its type and version to the server, which can then use that information toreturn different DHTML based on the needs of each browser .

In the case below, in order to show correctly in anything but IE, the extra span wrapper is needed around the text below.

The simpleCascading Style Sheetcode below illustrates two different browser hacks.

The first begins with HTML>BODY, whichIE ignoressince it cant parse it properly hence the first style rule is only applied in non-IE browsers.

The second begins with * HTML, whichonly IE knows how to interpret properly . This makes it so that FireFox and other browsers dont apply the second style rule.

Branching JavaScriptis a standard technique that is utterly unavoidable when coding for multiple browsers at present.

Alternate HTML Emissionsworks great for dynamic systems, but it precludes any hope of server-side or proxy caching (client-side caching is still okay).

Most interactive rich client applications cant validly be cached, anyway, since each request is unique and user-specific.

CSS Hacksare commonly frowned upon because future updates to the relevant browsers may well change the rules of which browsers can parse what.

So, its a good idea to only use CSS hacks for minor graphical items that wont cause a major uproar if suddenly FireFox 3.0 is applying all of your IE-only rules, or IE 8.0 takes on all your non-IE-only rules.

The vanilla user interface control set in most desktop environments Java and .NETincluded is fairly unimpressive, but very configurable so that you can create your own custom look.

The application to the right is a minor utility from the Starta system that has ano-frills .NET 2.0 Windows Formsinterface.

There are a great many vendors that sell components that help you make your windows applicationslook like Vistaprograms, or includeOffice 2007-style ribbonsand buttons.

These are most prominently available for Java and .NET.

The cost of these tools varies widely, and may includeroyaltiesto the vendor.

The component at right, fromProfessional UI Solutions , starts at $145 per developer.

For most graphical needs, there are often open-source examples for many languages on sites such asCode Project .

These often give the same-or-similar work to the commercial projects, but often arenot as optimized and/or are somewhat buggy .

They generally include the source code, however, so can provide ideas on how to create your own version of the component, or how

to fix their bugs.

Often it is easier to look at such an example and then just start from scratch, if you have the time.

The thorough testing and optimization of the commercial components can often make them worthwhile purchases.

Modern users areextremely accustomed to the web , and for many applications, using web-style paging, linking, searching, etc, is appropriate.

TheWindows XP Help Center(below) is an excellent example of a desktop program that makes use of a web-style interface.

In the case of the Help Center, you can see that they are actuallyhosting the IE runtimein a desktop application you can even see various IE toolbar options at the top of the window.

Such uses of IE in core windows widgets are common enough that Microsoft successfully claimed IE was part of their operating system before the Justice Department in 1997.

Many companies use hosted browser engines with their information-dissemination programs, because it presents a pleasing interface to the users and an easy development path.

Below is an example of how Starta has created a desktop application that hosts the IE runtime to extend the rich client experience.

Everything in the shot below isnative IE and DHTML , except for the toolbar at the very bottom thats a standard .NET 2.0 toolbar.

With a snap-in to Microsoft Word and Excel (not pictured), we put a button in those programs toolbars that reads Send to Starta.

When users click that button, theStarta Optimizedprogram opens (if it isnt open already), and the Upload queue in the bottom left becomes active.

This sort of Office hook is also used by Salesforce.com.

This makes it easier for novice users to upload fileswithout knowing how to navigate their file system .

The most exciting thing about hosting a browser runtime in a desktop application is that you can then create cyborg applications that are atrue mix of web and desktop programming .

In this screenshot, the dropdown in the upload window is still native HTML but it is filled by aJavaScript call to a C# method .

TheJavaScript codeshown below is all that is needed to populate the dropdown from the C# method (shown on next page).

The loadUploadQueue method is only called if the browser detects the presence of the Starta Optimized runtimes in the browser window (that code is not shown).

The calls towindow.externalare the calls into the hosting .NET desktop application.

Below is theC# methodthat JavaScript called on the previous page.

This method is part of a class that was marked as COM visible, and which was registered as the external object for the hosted browser runtime.

Since the conversion of a literal array of elements would be difficult between the two languages, the C# constructs astring representation of JavaScript code , which the JavaScript receives and then executes to immediately create an array in its memory space.

Using techniques like those shown on the last few slides, Starta enables not only easier uploads, but alsoautomatic login ,automatic updates , and more.

Depending on the needs of your web application, theintegration possibilitiesof hosting browser runtimes are limitless.

Mozillaalso offers a browser runtime that you can host (it is C-based), but since it did not include the FireFox extensions like Quirks Mode last time Starta evaluated it, it could not be used for our purposes.

The general user expectation is thatmodern desktop programs are self-updating .

The beauty of the hosted browser runtime is that you can update your server-side content quite often without having to update the client.

In general, however, most programs have aping processthat is either timed on the users system or which silently runs at startup of the program.

With automatic updates, you will need a separateupdater program .

This program is responsible for replacing the main program after the main program shuts down during an update.

To be truly seamless, the main program must also be able to update the updater program.

In Starta Optimized, we actually use a single JavaScript variable and C# method call to check for outdated desktop client versions on every call to the server.

This is useful because our users often leave their client application open for days or weeks at a time, and we dont want them to miss notification of an important desktop client updates because of that.

What many people who havent worked extensively in a web environment dont realize is that the client side ofweb pages are technology neutral .

It doesnt matter if you use ASP, JSP, PHP, Coldfusion, ASP.NET, or even just SHTML, the most basic server-side parsing of all:the resultant output to the web client is exactly the same .

This makes the ideas and techniques in this section relevant to any web application, regardless of server-side platform.

The only platform that counts here isthe web browser itself .

Using memory in web applications is more difficult than in any other kind of application, because web applications arestatelessby nature.

In other words, every request to a web server isan entirely isolated eventfrom the clientandthe servers points of view.

From the servers perspective, it uses multiple threads in the web server application to handle client requests in the order they are received.

For an individual client, there might be seconds between requests, or it might be hours or even days.

For anything but the most low-traffic sites, storing all the data for each individual client in memory is unlikely to be feasible.

This means that every request from the client to the server must identify itself, and often that non-volatile pieces of memory from the server must be persisted to the client, or else sent to the central database.

The following sections focus on ways in which these data points and identifiers can be retrieved from the client once they are sent there from the server.

Sending the data points from the server is easy just embed them as JavaScript variables or HTML elements in the page.

Despite the elaborate setups that many web platform vendors espouse, there areonly three possible waysto send data from the client code to the server.

They are:

Form / POST data

QueryStringparameters (the url itself)

Cookies

Other concepts, such as MicrosoftsViewState , are all simply built upon one of these three other mechanisms (ViewState is based upon encrypted POST data).

EvenSession Stateis just server-side data that is indexed into via client-passed keys (Cookies or QueryString).

Only works onPOSTbrowser actions.

Only includes data fromINPUT ,SELECT , andTEXTAREAfields that are located inside the submittedFORMtag.

Hidden form fieldscan be used to have the client remember data for the server, and most users wont be able to tamper with that.

However, advanced web programmers could falsify such data, so nothing sensitive should be placed there.

The QueryString example above is from the Starta system, and includes a number of keys.

Thecontentkey tells the system what page to load.

All our pages are dynamically generated, and are really just object-oriented classes in a dll. We have no physical files to correspond with pages, unless you count occasional attendant JavaScript files.

Theaid ,sid , andcidkeys are all part of the session management system in Starta.

Themode ,personid ,organizationid , andstlidkeys are all specific to the individual page being requested.

None of these values are security-sensitive the user can see and even change these values.

Of course, if the user changes their session keys, they will lose their place in the system and be forced to log in again.

Cookies are stored as text files on the client side, and getsent with every requestto the domain or sub-domain that they are tied to.

This means it can be important not to put too much data into cookies.

You can store small amounts of data in cookies, but it all has to be text-based and all of it can be easily tampered with by the user, or disallowed entirely.

In Starta, we remember minor settings such as the users last search term / search type in cookies, but little else.

None of these methods for passing data to the server exactly scream application ready, but when used carefully and in conjunction with one another, they can do a great job.

The fact thatnone of these methods were actually designed with applications in mindis why its so important to have a robust framework for centrally managing data through these three pipelines.

AJAX , or Asynchronous JavaScript And XML, is in fact just another technique that rides on top of the mechanisms already outlined.

Using anXML Request Objectin the browser, you simply send a request to the server and get back some XML, which you then parse. Thats it.

Your request can be in the form of a GET or a POST (and so can include POST data in the case of a POST).

Most likely your request will include QueryString as part of the url you are making the request to, and of course your cookies are sent along with the request, just like any other request.

There really isnt as much black magic to AJAX as some people make out. Its just a tool thatopens up a lot of positive design options .

As I mentioned before, AJAX must always returna valid snippet of XML , which must then be parsed.

This is fine for many cases, such as when you want to get a list of new values topopulate a listing , or even when you want to get values that will tell you how todynamically create new contenton the page in client-side memory.

However, what if you just wanted to pass back some HTML from the server? Or what if you wanted to pass back JavaScript code which the client could then execute? And if you wanted to open a file without redirecting the current page, youd completely out of luck with AJAX.

With AJAX, you cant do either of these things unless you encode the HTML/JavaScript and embed it inside XML. This isnt exactly efficient, and its not the easiest thing to do, either. Better have your ASCII Codes table handy.

Instead of always using AJAX, many systems also useHidden IFRAMEsto make asynchronous calls.

An IFRAME, or inline frame, is a mini-window that you can embed anywhere in your page.

A hidden IFRAME is the same thing, just not visible to the user.

You can programmatically manipulate the window of an IFRAME just like you can the central window that your system runs in.

You can redirect it, you can create custom content in it (to then programmatically POST to the server), and so on.

When content is returned from the server most likely in the form of a DHTML page it executes just like on any other page.

This means that you can have JavaScript that executes immediately upon page load inside the IFRAME, and it can change things, insert HTML, or whatever else in the parent window.

At Starta, we use hidden IFRAMEs and AJAX side-by-side. We determine which to use simply bywhat kind of data we want to return .

An example of a hidden IFRAME is below, along with some code to use it toopen a persons VCardon the client machine.

This is also a great example of how to effectively use QueryString to make requests from the client.

Before AJAX, this was a popular technique forembedding optional-use datain web pages.

A common example is for storing the values that go in the secondary dropdown in a pair of chained dropdowns (where the selected value of the first dropdown causes the second dropdown to populate).

Now AJAX and other asynchronous methods are more commonly used in such cases, but there are still times when its nice to be able to embed optional-use data in a page.

The downside of using an XML data island is that the XML is bulkier than raw data, which makes your page larger (and thereforeslower to transmit ), and the XML also has to be parsed, which can get pretty slow andtie up the processor on the client .

My preferred alternative is to never use XML Data Islands, but instead to just send the raw data as JavaScript variables usually as linear or jaggedJavaScript arrays .

When you send the data in a format that can be immediately parsed by the browser without an intermediary step, theresponse time is faster , you doless programming , and thepage size is smaller . Its a win all around.

Below is an example ofusing C# to create a linear JavaScript arrayon the server-side. This array will then be embedded into the appropriate part of the page andit will automatically become available in client-side memory . No parsing required!

Unfortunately, we have to end our discussion of the client side development environment without talking about methods for creating rich-client-style interface functionality on the web:

Pop-ups, floating elements (like faux windows), drag-and-drop, abstract drawing (even just diagonal lines can be a challenge if you arent using VML in IE), etc.

In the screenshots from the various Google applications and the Starta system youve seen a number ofexamplesof this, however.

Suffice it to say for the purposes of this discussion that such effects can be readily created in a cross-browser environment by expert web developers.

This topic is simply an entire discussion in itself.

Im going to focus on.NET-based implementationsof the concepts discussed here, since that is what I have code examples in, but most of these ideas apply to all OOP server platforms.

Also, most of these conceptscan be successfully used in procedural languageserver platforms like PHP, though these implementations tend not to be nearly as graceful.

This is, after all, the primary purpose of the web server.

At the most basic level,the client makes a requestto your web application, maybe including some data or files with it, and the server portion of your application takes some actions and thenthe server returns some DHTML . Thats it.

Everything else that happens in the middle is just geared towards taking actions on the server side or constructing the DHTML code to send back to the client.

Of course, this is a somewhat limiting thing to say. You could make the same argument that the only purpose of fiber optic network cards is to emit and detect light; while that is essentially true, it does obscure the complex underlying logic that goes into it.

However, for purposes of evaluatingbest practices , in this case I feel it is useful to step back to this level for a moment.

The standard ASP.NET model treats every page as aseparate file , as do most web coding platforms.

In its simplest form, a .NET page is just an aspx file with amix of literal DHTML and C# or VB(or another .NET language.

As an alternative, there can be an associated aspx.cs file that contains a Code Behind that is entirely coded in the .NET server-side language.

The .NET language components are then compiled into a dll that sits in a central bin folder for the web project, and any requests to that project are routed through both the individual requested aspx page, and the associated dll(s).

This is a simple.aspx page in VB.NETfrom the Innova Studio InnovaEditor examples.

Note that every tag with the runat=server attribute is parsed on the server-side before being sent to the client.

The standard ASP.NET model has a lot of advantages in that it is an OOP platform, and provides access to the huge .NET libraries for all sorts of purposes.

The standard model also is very customizable, and has great WYSIWYG support.

However, it is needlessly inefficient in order to offer WYSIWYG support and the integrated mix of DHTML scripting and back-end language coding.

The aspx page has to becompletely parsed by the server , then the .NET language code has to be executed, and then a DHTML response is formulated and sent back to the client.

Even this would not be so bad, but there is a lot of bloat in the page and control models of ASP.NET mostly this seems centered around providing functionality that is useful atdesign time rather than runtime .

The core ideas of the ASP.NET model really are excellent ones, though, and .NET is a great platform. The problems Ive outlined areall simply problems in the higher levelsof the ASP.NET model.

The solution is tocut out those levelsand replace them with custom solutions that are more tailored to your applications specific design needs.

Fortunately, Microsoft provided an easy way to accomplish just this with theirIHttpHandlerinterface.

The primary method on this interface isProcessRequest .

This method passes in an HttpContext object generated from the web server.

The HttpContext object contains everything you need to know to see the current state of the client request, the server response, and all the related properties.

The Response object is also how you emit the DHTML response back to the client.

At the most basic level, you could simply put all your code inside the ProcessRequest method, and send a big long string of text back to the client by typing it all out in statements of:

Context.Response.Write( Your text here );

This would be tedious as well as difficult to maintain, of course, so this is where you create acustom control tree .

All HTML is a tree, so its relatively easy to mimic the broad structures of your page.

Start with a Body class, give it a collection of sub-controls, and start creating classes for Textboxes, Panels, Listings, etc.

Its better to create classes that map to actualbusiness-level page objects , rather than simple HTML controls.

In other words, dont just create a table class.

Instead, create a more complex Panel class that includes your logic for how panels work, and a Listing class that includes your logic for listings even if both of these classes are essentially mapping to tables of various sorts.

Youll get the best productivity if you code in terms of these conceptual objects, rather than literal HTML objects.

In Startas case, we implemented a very robust control tree and a custom call stack that triggers all of our needed events andencapsulates and centralizesmost of the page logic so that individual page code is often 5%-10% the size of what the corresponding code would be in traditional ASP.NET

Perhaps this seems at first glance to be as involved as the base ASP.NET functionality, but every method here is exceedingly efficient and has a distinct purpose within the context of our specific application.

Pictured below is the Render method of Startas very simplest control,HtmlBreak .

The Render method is responsible for outputting DHTML based on the properties set on the control object.

The Render method is calledautomatically and recursivelyon all objects in the control tree as part of the overarching page construction logic, so the DHTML is sent to the HtmlTextWriter in the proper sequence with all the other controls on the page.

All of the following code snippets are key lines for creating the simple page pictured below,Investor Summary .

Some trivial lines of code will be omitted, but this page is entirely created in only206 linesof page-specific code.

First we get the relevant values fromQueryStringand put them into member variables of the class.

Next welog a page hitthat extrapolates out 12 distinct kinds of variables note that this takes only one line of code.

Finally, we make ourcall to the database again in one statement and the Compact Dataset (another Starta customization) is returned to the superclass call stack.

EvaluateSecurity pulls some aliases from session and does a quicksecurity check . This security check is secondary to the module-wide security check that will have already happened in the superclass.

LoadPageHeader quickly insures thatthe correct sidebar will be loaded(not pictured on the initial screenshot), and also makes sure that the correct node in the tree is highlighted if the sidebar is already visible.

This is the central control method for actuallydefining the page content .

Here the three panels are all created and added to the page content collection, and at the bottom the panels are each populated by a specific sub-method.

The topmost panel is now filled.

Note how simple it is to add all the text fields in columns.

The middle panel is now filled.

Note how simple it is to set up the complex listing.

The RenderDevelopments method is very similar to the RenderFunds method, so there is little point in showing that.

The C# code in this example was206 lineslong, and the emitted DHTML was only133 lineslong (or perhaps more relevantly,6.99 KB ).

If there was more data pictured here, the number of emitted lines would of course increase.

The DHTML is able to be so brief because it references eight JavaScript source files, as well as two CSS style sheets.

By maximizing these cacheable components, the emitted code is able to remain as tight and efficient as the C# code that created it. This increases responsiveness of the system and also reduces bandwidth costs.

Creating your own custom control tree has many far-reaching benefits for your overall design, but one of the best is that you gain the ability tocentralize and customizeall kinds of logic.

In Starta, we used this freedom to create:

Completely custom, SQL-driven Session State Logic.

Automated form parsing.

Semi-automated saving of dynamic field sets.

Automated configurability of field visibility/order/aliases on data-heavy pages.

Compact Datasets that are more efficient than the default Microsoft Datasets (and which dont need to be Disposed).

Automated handling of complex pagination, sorting, and filtering logic on our larger listings.

A selection of module-level superclasses for pages (eliminates module-related redundant coding).

Hit and event logging that requires little coding and which tracks detailed usage and history data that is then shared with our clients.

Much more...

If you use a custom IHttpHandler-style model whatever your platform yourlong term efficiencyimprovements should be immense.

At Starta, weve found that our architecture lets us complete work in less than a third of the time it would otherwise take.

Ruby on Rails is not a technology that Ive professionally worked with, but from what Ive seen of it, it seems to be following the same general design principles that Im advocating here.

Centralization, encapsulation, and yet customization are all key in both platform models.

Whatever model you choose, whether you are doing web or desktop development, this type of architecture is themost conductive to large-scale application development .

Web developmentis likely to become the de facto solution for many rich client business applications.

Web-based applications are simply easier and faster to create and deploy (issues of server capacity planning and cross-browser compatibility notwithstanding).

As the various browsers mature even more, hopefully they will become increasingly homogenous in their core code interfaces.

Acore of staple desktop-based business programs like Photoshop and even Office is likely to remain for the foreseeable future.

Of course, many other kinds of programs, such as firewalls, virus protection, games, 3D rendering suites like Bryce, and other complex or hardware-intensive/specific applications will almost certainlyalwaysremain on the desktop. Im really discussing business productivity software here.

Many web applications are likely to have generally optional, and often small desktop-based components .

Salesforce.com is an excellent example of a program that is entirely web-based except for its Office plug-ins.

Trends in Rich Client Development

Documents

Transcript of Trends in Rich Client Development