seanb's Journal: JavaOne: Taking the hype out of hypertext UIs

The Google lesson: advanced UI concepts work best with clear, minimal applications. Combining the level of hackery that goes into Google maps with a substantially larger application would result in a steaming, unmanageable, mess.

Autogenerated UIs become ugly messes of code you never want to touch, that get in the way of cool algorithms. If you want to do somethign the code-generator didn't intend, you often have little recourse.

Model-View-Component is a good idea in theory, but people cut corners and mix MVC layers, putting everything in the View.

UI code grows out of hand. When project managers/salespeople/customers see soemthing they want to change about the product, they describe what they want to change in terms of the UI. These revisions are often implemented as quick hacks in the UI layer that break clean MVC separation. Changes in flow and layout often impact application layer.

One way to avoid (or at least minimize) this trend is to err on the other side during the initial design phase: build large, generic Controls. Use a solid data model. Keep the view logic as minimalistic as possible.

UI packages have screens, widgets, threads, and events.

HTML has response/request, forms on a per-page basis. Linear, coarse, synchronous flow.

HTTP heavy, stateless.

Classic UI: many paths, each screen only needs to know it's own data.
Web UI: each page needs to understand every path.

Each request contains WHERE to go and information about the screen that you just left.

Oject-oriented UI model more intuitive for design, management.

Model DOM objects as server-side Widgets with subclassable event listeners. Provide a way to plug these event listeners into the form handler.

His implementation has a Processing Thread for each user session, with which the event handlers are registered. Doesnlt allow parallel browsing of multiple screens, doesn't scale well. Works on embedded devices.