Transcript Trends in Rich Client Development

Triangle Technology Executive Council
September 11, 2007
Trends in Rich Client
Development
Presented by
Christopher M. Park
CTO, Starta Development, Inc.
http://www.startadev.com/
Agenda
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)
Introduction
About Starta
Starta Development,
Inc. is a very small
application service
provider, or ASP,
targeted at the
Affordable Housing
Industry.
Christopher M. Park
has been with Starta
since 2001, and
became the
company’s head
software architect in
2003.
About Starta
On the server side, Starta works primarily with
Microsoft technologies such as ASP.NET and
SQL Server, but in many cases we’ve found the
“standard” way of handling these technologies to
be inadequate.
We’ve therefore taken the initiative to create our
own custom rich client web platform, which we
call the Business Operating System, or BOS.
Starta’s BOS
The BOS is coded entirely in C#, JavaScript/DHTML,
and TSQL for Microsoft SQL 2000.
The bulk of our platform is designed for a web interface,
but in the past we’ve 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 as Outlook
and Office plug-ins, TWAIN scanner software, and an
Internet-Explorer wrapper that allows us full rich-clientstyle access to the desktop while still using our webbased interface.
Starta’s BOS
The primary purpose of the BOS is to provide a platform
for Starta to create and host modular data, reporting,
document management, CRM, and project management
tools (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 handling clusterability,
Remoting/SOAP, state management, HTTP request
pipeline control, Queuing, Scheduling, and a lot more.
Presentation Goals
Discuss the problems and challenges facing developers
of contemporary rich client applications.
Look at what some of the major software shops have
been doing lately, as well as some of the solutions that
Starta and other companies have come up with over the
past six years.
And with that, let’s move into the presentation proper...
Contemporary
Rich Clients
Contemporary Rich Clients
“Rich clients” were once synonymous with desktop
applications.

Only the desktop platforms had advanced graphics, dragand-drop, file system access capabilities, etc.
AJAX, DHTML, and frameworks like Flash have
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 of
design rather than underlying platform.
Google Docs & Spreadsheets
Google’s online office suite offers similar functionality to
Microsoft Office, but in an entirely web-based interface.

No extra components – not even Flash or ActiveX – are needed
for the base functionality.
Google’s AJAX implementations with both their Docs
program as well as their services like GMail are among
the most advanced on the Internet.
However, lower
performance with
large documents,
and the
inconvenience or
unavailability of
some features, make
this not a completely
ideal solution.
Google’s Picasa
Google’s Picasa is an excellent example of the
limitations of purely web-based offerings.
Advanced services such as multi-upload, scheduled
uploading, automatic image discovery on the client
computer, and CD burning are only possible using their
desktop version of the
software.
However, the primary
means for managing the
web sharing portions of
the program are still
web-based.
Google’s GMail
The “perfect” web-based rich client application?
Virtually no loss of functionality versus desktopbased counterparts.
Takes full
advantage of its
server-based
nature – spam
and virus filtering,
incredibly fast
search, etc.
Attributes of Successful
Rich Clients
Usability is more important now than ever.

Users expect to be able to look at a system and
immediately understand what is going on.
Prettiness is also demonstrably important to user
acceptance of products.

However, when prettiness trumps functionality or
performance – as in Windows Vista – users are not
forgiving.
Response time is still key.

Part of the success of Google is not just their
ingenious (and secret) server model, but also their
clear, simple, and above all efficient interface.
The Dark Side of
Progress
Trends that are hopefully going to
be short-lived
Functionality Overload
The balance between too much and too little
functionality.

Overwhelming new users vs. irritating expert users.
Microsoft Office combats via its 2007 interface
overhaul.
Adobe Photoshop combats via its Elements
lightweight version.
Mozilla FireFox combats via optional add-ons.
Starta combats via extreme configurability.
Ribbons in Microsoft Access 2007
Smaller lists of options
Easy mix of icons and text
But, new groupings for users to learn
Adobe
PS CS3
Complexity
Too Many
Options!




Tree
Menus
Dynamic
Toolbars
MultiPanels
Detail
Windows
Mozilla FireFox Add-ons
Limited base
functionality
Add-ons from
community
and core
developers
Keeps base
install small
and simple
Configurability in Starta
Starta’s approach is to offer massive amounts of
functionality, but to hide most of it by default.
Client administrators can then enable only those
functions that they want, and roll out functionality to their
users without 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.
Configurability in Starta
On the left is a partially-expanded
view of the full sidebar of Starta’s
“development” entity.
On the right is that same sidebar,
but customized to a specific
client’s 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 vs. Form
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 3D’s 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?
DAZ 3D’s Bryce
An excellent example of a software product that has advanced
capabilities, but which is so aimed at the novice-level users that 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, but many advanced features are buried
in sub-menus so 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
exactly fits the target market
they 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.
SQL Server 2000 vs. 2005
The interface of the older version of Microsoft’s SQL
Server was actually more usable in 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
Microsoft’s programmer’s needs, not the needs of users.
Too Much Middleware!
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 with thirdparty components or 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.
Build vs. Buy
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 is efficient both at design-time
and at runtime.
Prefab components such as DotNetNuke have 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 by Aspose are so focused
and well-designed that it would be a fool’s 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.
Cross-Platform Issues
Cross-Platform Issues
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
Cross-Browser Issues
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
Internet Explorer - Versions
Version 5.01 and before are almost unusable for a modern interactive
UI.
Version 5.5 adds 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.
Version 6.0 adds better CSS support, some new JavaScript options,
and fixes some glitches from 5.5.
Version 7.0 adds 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+, you’ll need to add wrapper methods.
Internet Explorer - Issues
There is a horrible memory leak in IE7 on most AJAXbased 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.
Internet Explorer - Issues
Behaviors were 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 Microsoft’s own
MSDN website, though it takes a fair amount of cross-clicking before
it is really apparent.

Don’t 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 can’t 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.
Internet Explorer - Issues
All installations of a given version of IE are not the same,
unfortunately.



For inexplicable reasons, even in centrally-managed corporate
environments, there are often corrupted installations on some
computers.
In Starta’s 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.
Mozilla FireFox - Versions
Works the same on Windows, Linux, and Macintosh!
The core “Mozilla” browser is different than the FireFox
browser, even though both run on the Gecko engine.

FireFox includes a “Quirks mode” that allows it to be much more
compatible with IE-centric web pages.
Version 1.0.x and before is pretty limited for an interactive
UI. Not recommended.
Version 1.5.x and up is when FireFox really came into its
own as a viable platform for cross-browser rich web client
development.
Version 2.0.x and up adds a number of new rich client
programmability enhancements similar to those in IE7
(although with different interfaces).

These aren’t backwards-compatible or compatible with other
browsers, unfortunately.
Mozilla FireFox - Issues
Even FireFox 2.0 running in Quirks Mode has some
very frustrating differences from the IE code model.



These differences are closer to the official W3C 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.
Apple’s Safari
This is the de facto browser on the Macintosh.


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.
Branching JavaScript – Option 1
The cross-browser JavaScript example 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.
Javascript/Com/Main.js
From the Starta Enterprise System
Branching JavaScript – Option 2
Some systems opt to have separate .js source files for 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.
Alternate HTML Emissions
The server-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 to return 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.
Starta.Jericho.UI.Controls.WebComboBox.cs
From the Starta Enterprise System
CSS Hacks
The simple Cascading Style Sheet code below illustrates two
different “browser hacks.”
The first begins with HTML>BODY, which IE ignores since it
can’t parse it properly – hence the first style rule is only applied
in non-IE browsers.
The second begins with * HTML, which only IE knows how to
interpret properly. This makes it so that FireFox and other
browsers don’t apply the second style rule.
Style/panel.css
From the Starta Enterprise System
Cross-Browser Conclusions
Branching JavaScript is a standard technique that is
utterly unavoidable when coding for multiple browsers at
present.
Alternate HTML Emissions works 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 can’t validly be cached,
anyway, since each request is unique and user-specific.
CSS Hacks are commonly frowned upon because future
updates to the relevant browsers may well change the
rules of which browsers can parse what.

So, it’s a good idea to only use CSS hacks for minor graphical
items that won’t 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 nonIE-only rules.
Desktop Development
Basic Windows Forms
The “vanilla” user
interface control set in
most desktop
environments – Java and
.NET included – 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 a no-frills .NET 2.0
Windows Forms
interface.
Windows Forms Utility Program
(Used by Starta Programmers Only)
From the Starta Enterprise System
Advanced UI – Third Parties
There are a great many vendors that sell components that help you
make your windows applications look like Vista programs, or include
Office 2007-style ribbons and buttons.
These are most prominently available for Java and .NET.
The cost of
these tools
varies widely,
and may
include
royalties to the
vendor.
The
component at
right, from
Professional UI
Solutions,
starts at $145
per developer.
Advanced UI – Open Source
For most graphical needs, there are often open-source examples for
many languages on sites such as Code Project.
These often give the same-or-similar work to the commercial
projects, but often are not 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.
Desktop UI Limitations
Modern users are extremely accustomed to the web, and for many
applications, using web-style paging, linking, searching, etc, is
appropriate.
The Windows 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 actually
hosting the IE runtime in 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.
Hosted Browser Runtime
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 is native IE and DHTML, except for the
toolbar at the very bottom – that’s 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, the Starta
Optimized program
opens (if it isn’t 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
files without knowing how
to navigate their file
system.
Hosted Browser Runtime
The most exciting thing about hosting a browser runtime in
a desktop application is that you can then create “cyborg”
applications that are a true mix of web and desktop
programming.
In this
screenshot, the
dropdown in the
upload window
is still native
HTML – but it is
filled by a
JavaScript call
to a C# method.
Hosted Browser Runtime - JS
The JavaScript code shown 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 to window.external are the calls into the hosting .NET
desktop application.
Javascript/Projects/Document/UploadDocumentSelection.js
From the Starta Enterprise System
Hosted Browser Runtime – C#
Below is the C# method that 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 a string representation of JavaScript
code, which the JavaScript receives and then executes to immediately create
an array in its memory space.
StartaOptimized.Data.DHTMLBroker.cs
From the Starta Enterprise System
Hosted Browser Conclusion
Using techniques like those shown on the last few slides, Starta
enables not only easier uploads, but also automatic login, automatic
updates, and more.
Depending on the needs of your web application, the integration
possibilities of hosting browser runtimes are limitless.
Mozilla also 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.
Automatic Updates
The general user expectation is
that modern 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 a ping process
that is either timed on the user’s
system or which silently runs at
startup of the program.
Automatic Updates
With automatic updates, you will need a separate updater
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 don’t want them to miss
notification of an important desktop client updates because of that.
The Client Side of
Web Development
DHTML is Platform Neutral
What many people who haven’t worked extensively in a
web environment don’t realize is that the client side of
web pages are technology neutral.
It doesn’t matter if you use ASP, JSP, PHP, Coldfusion,
ASP.NET, or even just SHTML, the most basic serverside 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 is the web browser
itself.
Web App Memory Management
Using memory in web applications is more difficult than in any other
kind of application, because web applications are stateless by nature.
In other words, every request to a web server is an entirely isolated
event from the client and the server’s points of view.



From the server’s 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.
Passing Data to the Server
Despite the elaborate setups that many web platform
vendors espouse, there are only three possible ways to
send data from the client code to the server.
They are:



Form / POST data
QueryString parameters (the url itself)
Cookies
Other concepts, such as Microsoft’s ViewState, are all
simply built upon one of these three other mechanisms
(ViewState is based upon encrypted POST data).
Even Session State is just server-side data that is
indexed into via client-passed keys (Cookies or
QueryString).
POST Data
Only works on POST
browser actions.
Only includes data from
INPUT, SELECT, and
TEXTAREA fields that
are located inside the
submitted FORM tag.
Hidden form fields can be
used to have the client
“remember” data for the
server, and most users
won’t be able to tamper
with that.

However, advanced web
programmers could
falsify such data, so
nothing sensitive should
be placed there.
QueryString
The QueryString example above is from the Starta system, and
includes a number of keys.
The content key tells the system what “page” to load.

All our pages are dynamically generated, and are really just objectoriented classes in a dll. We have no physical files to correspond with
pages, unless you count occasional attendant JavaScript files.
The aid, sid, and cid keys are all part of the session management
system in Starta.
The mode, personid, organizationid, and stlid keys 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
Cookies are stored as text files on the client side, and get
sent with every request to 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 user’s last search
term / search type in cookies, but little else.
Thoughts on Passing Data
to the Server
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 that none of these methods were actually
designed with applications in mind is why it’s so
important to have a robust framework for centrally
managing data through these three pipelines.
What about AJAX?
AJAX, or Asynchronous JavaScript And XML, is in fact
just another technique that rides on top of the
mechanisms already outlined.
Using an XML Request Object in the browser, you simply
send a request to the server and get back some XML,
which you then parse. That’s 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 isn’t as much black magic to AJAX as some people
make out. It’s just a tool that opens up a lot of positive design
options.
Example AJAX Code
This JavaScript
code simply loads
the AJAX object,
tells it what page to
call, and passes it
a pointer to a
method to call
when the request
finishes (that’s the
“asynchronous”
part).
Javascript/Com/AJAX.js
From the Starta Enterprise System
The Limitations of AJAX
As I mentioned before, AJAX must always return a 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 to populate a listing, or even
when you want to get values that will tell you how to
dynamically create new content on the page in clientside 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, you’d completely out of luck
with AJAX.

With AJAX, you can’t do either of these things unless you
encode the HTML/JavaScript and embed it inside XML. This isn’t
exactly efficient, and it’s not the easiest thing to do, either. Better
have your ASCII Codes table handy.
An Alternative to AJAX
Instead of always using AJAX, many systems also use
Hidden IFRAMEs to 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.
IFRAMEs vs. AJAX
At Starta, we use hidden IFRAMEs and AJAX side-by-side. We
determine which to use simply by what kind of data we want to return.
An example of a hidden IFRAME is below, along with some code to
use it to open a person’s VCard on the client machine.

This is also a great example of how to effectively use QueryString to
make requests from the client.
Javascript/ComSmallExport.js
From the Starta Enterprise System
XML Data Islands
Before AJAX, this was a popular technique for
embedding optional-use data in 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 it’s nice to be able to embed optional-use data in a
page.
XML Data Islands Alternative
The downside of using an XML data island is that the
XML is bulkier than raw data, which makes your page
larger (and therefore slower to transmit), and the XML
also has to be parsed, which can get pretty slow and tie
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 jagged
JavaScript arrays.
When you send the data in a format that can be
immediately parsed by the browser without an
intermediary step, the response time is faster, you do
less programming, and the page size is smaller. It’s a
win all around.
Outputting A JavaScript Array
Below is an example of using C# to create a linear JavaScript array on
the server-side. This array will then be embedded into the appropriate
part of the page and it will automatically become available in clientside memory. No parsing required!
Starta.Jericho.Factories.DynamicTableFactory.cs
From the Starta Enterprise System
Client Side Display Methods
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 aren’t using VML in IE), etc.
In the screenshots from the various Google applications
and the Starta system you’ve seen a number of
examples of 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.
The Server Side of
Web Development
The Server-Side is NOT
Platform Neutral
I’m going to focus on .NET-based implementations of 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 concepts can be successfully used in
procedural language server platforms like PHP, though
these implementations tend not to be nearly as graceful.
Passing Data to the Client
This is, after all, the primary purpose of the web server.
At the most basic level, the client makes a request to
your web application, maybe including some data or files
with it, and the server portion of your application takes
some actions and then the server returns some DHTML.
That’s 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 evaluating best practices, in this case I
feel it is useful to step back to this level for a moment.
The ASP.NET Model
The standard ASP.NET model treats every page as a
separate file, as do most web coding platforms.
In its simplest form, a .NET page is just an aspx file with
a mix 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).
ASP.NET Code Example
This is a simple .aspx page in VB.NET from the Innova Studio
InnovaEditor examples.

Note that every tag with the runat=server attribute is parsed on the serverside before being sent to the client.
ASP.NET Model Limitations
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 be completely 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
at design time rather than runtime.
Cutting the Bloat from ASP.NET
The core ideas of the ASP.NET model really are
excellent ones, though, and .NET is a great platform.
The problems I’ve outlined are all simply problems in the
higher levels of the ASP.NET model.
The solution is to cut out those levels and replace them
with custom solutions that are more tailored to your
application’s specific design needs.
Fortunately, Microsoft provided an easy way to
accomplish just this with their IHttpHandler interface.
IHttpHandler
The primary method on this interface is ProcessRequest.



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.
Starta.Jericho.RequestFramework.RequestBroker.cs
From the Starta Enterprise System
Emitting DHTML with IHttpHandler
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
a custom control tree.

All HTML is a tree, so it’s relatively easy to mimic the
broad structures of your page.
Filling Your Control Tree
Start with a Body class, give it a collection of sub-controls,
and start creating classes for Textboxes, Panels, Listings, etc.
It’s better to create classes that map to actual business-level
page objects, rather than simple HTML controls.



In other words, don’t 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.
You’ll get the best productivity if you code in terms of these conceptual
objects, rather than literal HTML objects.
In Starta’s case, we implemented a very robust control tree
and a custom call stack that triggers all of our needed events
and encapsulates and centralizes most 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
Starta’s Call Stack
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.
Example Control
Pictured below is the Render method of Starta’s 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 called automatically and recursively on 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.
Example Page Construction
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 only 206 lines of page-specific code.
Investor Summary Part 1/5
First we get the relevant values from QueryString and put
them into member variables of the class.
Next we log a page hit that extrapolates out 12 distinct kinds
of variables – note that this takes only one line of code.
Finally, we make our call to the database – again in one
statement – and the Compact Dataset (another Starta
customization) is returned to the superclass call stack.
Investor Summary Part 2/5
EvaluateSecurity pulls some aliases from session and does a quick
security check. This security check is secondary to the module-wide
security check that will have already happened in the superclass.
LoadPageHeader quickly insures that the 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.
Investor Summary Part 3/5
This is the central control method for actually defining 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.
Investor Summary Part 4/5
The topmost panel is now filled.
Note how simple it is to add all the text fields in columns.
Investor Summary Part 5/5
The middle panel is now filled.
Note how simple it is to set up the complex listing.
Investor Summary Conclusion
The RenderDevelopments method is very similar to the RenderFunds
method, so there is little point in showing that.
The C# code in this example was 206 lines long, and the emitted
DHTML was only 133 lines long (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.
Other Custom Server Components
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 to centralize and customize all 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 don’t 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 modulerelated 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...
IHttpHandler Conclusion
If you use a custom IHttpHandler-style model – whatever
your platform – your long term efficiency improvements
should be immense.

At Starta, we’ve 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 I’ve professionally
worked with, but from what I’ve seen of it, it seems to be
following the same general design principles that I’m
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 the
most conductive to large-scale application development.
Conclusion
Conclusion
Web development is 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.
A core 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 certainly always
remain on the desktop. I’m 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.
Q&A
For a copy of this presentation, please visit:
http://www.startadev.com/pub/data/ttec9-11-07.ppt
Presented by
Christopher M. Park
CTO, Starta Development, Inc.
http://www.startadev.com/