Occasionally Connected Components

In working with Seam and some of the ideas behind it, I quickly came to realize some of the faults of having stateful UIs. Take a h:dataTable for a second-- where it's great that we have a stateful dataTable component, but anything that's dynamic-- such as the data itself, must be retained in a stateful scope that matches the UI. So with something like JSF, you are getting half of the cake. It's taking care of managing all that state when really, you don't care-- you just care about your model and any state you do care about is represented in existing scopes-- such as the request or session or-- conversation.

When you write JSF components... anything you want that's dynamic must be handled as a special case-- see some of the 'getter' code in UIInput. What if the component was meant to be stateless in the first place-- the tree static-- everything hardwired and shared across all threads? Facelet TagHandlers are damn easy to write, and their stateless. They are so easy to write that people were wondering about using Facelets as a general templating language, but it's built on top of JSF-- and there's nothing wrong with that, it's a win-win situation for developers.

Fast forward a month later, and I started to look at what it meant to be part of a component tree-- a view, and where the dynamisism could lie in relation to rich UIs and AJAX or whatever. JSF's lifecycle is built around processing the whole tree, which doesn't leave much room for partial tree processing-- only render component 'A' in some table. It's hard, but there's the idea of a ProcessingContext that I brought up on Java.net which basically 'short circuits' tree processing into the selected branches and leaves. But upon more discussion, then there's the issue of state saving-- which brings us full circle about stateless component models.

I've shared the idea of ProcessingContexts with JSF, but I'm still worried about state management and model management, I want something that works for Yahoo.com or Google. My idea is to pursue some of these concepts into a new version of Facelets-- called Avatar, which will skim out all of the JSF statemanagement and offer a pure alternative to JSP/Velocity that can be used with Struts or WebWork, or just Servlets. I'm still working out all the details, but it will be fully declarative and offer partial tree processing as a first-class citizen in the API. AJAX will be a piece of cake-- invoke some Action and render component 'C' on this Avatar page.

I'm still working out how to handle updates, I might just give components two phases (like portlets) with a render and update phase. But then there's the question of validation, where you want to update, or at least validate everything before applying, but since there has to be opportunity for iterative scopes, it's not something that can easily be retained unless I determine that there's some kind of updateevent that can be queued or action events... hmmm... maybe this is the alternate answer to all of those lifecycles-- here, we provide two phases, but queue how many events you want for evaluation later. More to think about.