In the past couple of months, I've been learning more and more about the business of writing very customizable user interfaces for browser-based applications.
To me the best system architecture is a strong model-view-controller architecture.
- The model is your business logic
- The controller is your user-interface navigation logic (screen to screen)
- The view is the user-interface presentation (including intrascreen navigation logic)
I'm well versed in the way you assemble and partition business logic into reasonable layers (utilities, data access, business objects, business services). These days, I'm expressing this using the .Net runtime and my common classes, nHibernate, simple non-mutable objects for the business object entities, and state-less service objects for business rules. I've developed these techniques in 20+ years of PL/I, C, C++, VB6 COM and now C# programming.
What's been new to me recently is learning about advanced user-interface development. My old days were in console-mode (text) applications and then Windows™ forms-based stuff. I've
grokked the separation of the controller from the presentation and benefited from
The Humble Dialog Box and the ease of unit-testing it enables. HTML web interfaces, however, were really a dark corner of my mind until the last couple of years. I knew HTML markup, but doing anything interactive was new to me. Thankfully, I didn't have to learn the "old way". I got to play with ASP.Net from the get-go, and it really did save me a huge learning curve. I learned about post-backs without having to unlearn posting to a different page when that was the strategy of the day. But nothing in the web grabbed my attention until I started playing with applications that put someone of the UI-specific controller logic on the pages. Those appplications (gmail, Google Maps, Outlook Web Access, and earlier things like the old Sears Photos site) let me feel immedately in control of the application without all the distaste that the typical usability-be-damned Flash applications didn't. That methodology has a moniker now... it's
AJAX, and I like it.
I'm converted. How do I build a real application without inventing all that plumbing? As usual, it is time to hit the blogs and start playing. There's a gold mine of great parts that I want to mention:
First, as I'm a server-guy at heart, I've got the find the .Net support for the controller. That's easy... Microsoft has announced the up-and-coming Atlas, but why wait when
Ajax.Net is already here, and does almost anything you could possibly want; once again the goodness of open-source makes me happy. Make sure you check out Michael Schwarz's
blog.
OpenRico is the best collection of client-side user-interface tools for AJAX that I've found. It's an amazing piece of engineering, in that it does everything that is hard to get right, it is free, and it is open source. Go play for a minute, then come back and tell me why I should write a WinForms application for the average data-entry application. You'll find a drag-and-drop handler with constrained targets, cinematic stuff for sizing, positioning, corner rounding, fading and some animation effects (some are even tolerable). The really sweet bit is the client-side AJAX for a lazy-loaded, sortable, scrollable data-grid!
OpenRico is built upon the
very clean object-oriented
JavaScript framework
Prototype. This set of methods and coding style solves the "how do I do this cleanly" on the client side. Don't structure your code without it.
Now the next problem I've noticed is that the pages are getting to be a real tag-soup. This is bad, I can't read the content of the page because it is lost in all of the
JavaScript eventing and identifiers and style-sheets. Come on! There are only a few "standard" types of display and entry fields on the average data-entry screen. Can't we find some way of centralizing the behavior of things based on the class of display/input element? Wait, this is sounding familiar... if only there was a way to associate those behaviors with page elements through a simple decoration... sort of like CSS styles... hmmm...
YES! that's it exactly. Welcome to the future, associate your behavior using css selectors using this simple framework.
Another interesting bit is the
Scriptaculous scripts for autocomplete, drag-and-drop of individual elements, and tons of animations (which I hate).
Of course, dealing with all of these cool client-side toys means that we need a much better testing experience. I've been looking into the latest coolness, a
FIT driven testing tool called
Selenium. The coolest part is that the test scripts are simply HTML tables of actions and values, anyone can read (and write) them.
Some other AJAX sites:
Ajaxian has some interesting insights into
JavaScript's implications for screen readers and automated testing.
Completely off-topic:
Pseudo HTML element that combines a radio button group with a select box for quick picks of common options.
Internet Explorer vs. Mozilla from a JavaScript coder's perspective. Things to watch out for when crossing browsers.
[Edit: 9:37 AM 4-Aug-2005 - thanks John]
The JavaScript
language specification is an interesting read. The
errata is there to proved that everyone makes mistakes.
No comments:
Post a Comment