Trends in Rich Client Development

1
Trends in Rich Client Development
Triangle Technology Executive Council September
11, 2007

• Presented by
• Christopher M. Park
• CTO, Starta Development, Inc.
• http//www.startadev.com/

2
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)
• QA (94)

3
Introduction
4
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 companys head software
  architect in 2003.

5
About Starta

• On the server side, Starta works primarily with
  Microsoft technologies such as ASP.NET and SQL
  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 own custom rich client web platform, which we
  call the Business Operating System, or BOS.

6
Startas 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 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 as
  Outlook and Office plug-ins, TWAIN scanner
  software, and an Internet-Explorer wrapper that
  allows us full rich-client-style access to the
  desktop while still using our web-based
  interface.

7
Startas 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.

8
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, lets move into the presentation
  proper...

9
Contemporary Rich Clients
10
Contemporary Rich Clients

• 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 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.

11
Google Docs Spreadsheets

• Googles 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.
• Googles 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.

12
Googles Picasa

• Googles 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.

13
Googles GMail

• The perfect web-based rich client application?
• Virtually no loss of functionality versus
  desktop-based counterparts.

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

14
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.

15
The Dark Side of Progress

• Trends that are hopefully going to be short-lived

16
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.

17
Ribbons in Microsoft Access 2007

• Smaller lists of options
• Easy mix of icons and text
• But, new groupings for users to learn

18
AdobePS CS3Complexity

• Too Many Options!
• Tree Menus
• Dynamic Toolbars
• Multi-Panels
• Detail Windows

19
Mozilla FireFox Add-ons

• Limited base functionality
• Add-ons from community and core developers
• Keeps base install small and simple

20
Configurability in Starta

• Startas 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.

21
Configurability in Starta

• On the left is a partially-expanded view of the
  full sidebar of Startas development entity.
• On the right is that same sidebar, but customized
  to 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.

22
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 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?

23
DAZ 3Ds 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.

24
SQL Server 2000 vs. 2005

• The interface of the older version of Microsofts
  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 Microsofts programmers needs,
  not the needs of users.

25
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
  third-party 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.

26
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
  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.

27
Cross-Platform Issues
28
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

29
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

30
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, youll need to add
  wrapper methods.

31
Internet Explorer - Issues

• There is a horrible memory leak in IE7 on 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.

32
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 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.

33
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 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.

34
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 arent backwards-compatible or compatible
  with other browsers, unfortunately.

35
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.

36
Apples 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.

37
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
38
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.

39
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
40
CSS Hacks

• The simple Cascading Style Sheet code below
  illustrates two different browser hacks.
• The first begins with HTMLgtBODY, which IE ignores
  since it cant 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 dont apply the
  second style rule.

Style/panel.css From the Starta Enterprise System
41
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 cant
  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, 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.

42
Desktop Development
43
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
44
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.

45
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.

46
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.

47
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
  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, the Starta
  Optimized program 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
  files without knowing how to navigate their file
  system.

48
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.

49
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/UploadDocumentSelecti
on.js From the Starta Enterprise System
50
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
51
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.

52
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 users system
  or which silently runs at startup of the program.

53
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 dont want them to miss
  notification of an important desktop client
  updates because of that.

54
The Client Side of Web Development
55
DHTML is Platform Neutral

• What many people who havent worked extensively
  in a web environment dont realize is that the
  client side of web 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 is the web
  browser itself.

56
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 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.

57
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 Microsofts 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).

58
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
  wont be able to tamper with that.
• However, advanced web programmers could falsify
  such data, so nothing sensitive should be placed
  there.

59
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 object-oriented 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.

60
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
  users last search term / search type in cookies,
  but little else.

61
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 its so
  important to have a robust framework for
  centrally managing data through these three
  pipelines.

62
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. 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 that opens
  up a lot of positive design options.

63
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 (thats the asynchronous part).
Javascript/Com/AJAX.js From the Starta Enterprise
System
64
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 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.

65
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.

66
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 persons 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
67
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 its nice to be able to embed
  optional-use data in a page.

68
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. Its a win all around.

69
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 client-side memory. No parsing
  required!

Starta.Jericho.Factories.DynamicTableFactory.cs Fr
om the Starta Enterprise System
70
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 arent
  using VML in IE), etc.
• In the screenshots from the various Google
  applications and the Starta system youve 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.

71
The Server Side ofWeb Development
72
The Server-Side is NOT Platform Neutral

• Im 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.

73
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. 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 evaluating best
  practices, in this case I feel it is useful to
  step back to this level for a moment.

74
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).

75
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 runatserver
  attribute is parsed on the server-side before
  being sent to the client.

76
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.

77
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 Ive 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 applications specific design
  needs.
• Fortunately, Microsoft provided an easy way to
  accomplish just this with their IHttpHandler
  interface.

78
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 F
rom the Starta Enterprise System
79
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 its relatively easy to
  mimic the broad structures of your page.

80
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.
• Its better to create classes that map to actual
  business-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 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

81
Startas 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.

82
Example Control

• 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 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.

83
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.

84
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.

85
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.

86
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.

87
Investor Summary Part 4/5

• The topmost panel is now filled.
• Note how simple it is to add all the text fields
  in columns.

88
Investor Summary Part 5/5

• The middle panel is now filled.
• Note how simple it is to set up the complex
  listing.

89
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.

90
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 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...

91
IHttpHandler Conclusion

• If you use a custom IHttpHandler-style model
  whatever your platform your long term
  efficiency improvements 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 the most conductive to
  large-scale application development.

92
Conclusion
93
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.
  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.

94
QA

• 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/