More On Stateless Components

I've been looking at the SWT API a little bit, while I'm still foggy on some areas, I don't see that it's easy to simply refer to other components or modify the tree on the fly. If we look at a component tree, and then use the filter/visitor pattern, we could keep lifecycles/state of components more grainular. As the process or visitor cascades through the component model, it can be lazy instantiated either creating new, or restoring from some other scope.

// parent component
public List columns = new ArrayList();

public void handleEvent(Event e, Tree t) {
   // eval children
   t.handleEvent(e);
   for (UIColumn c : columns) {
      c.handleEvent(e);
   }
}

// child column
public void handleEvent(Event e, Tree t) {
    ColumnParent cp = t.findParent(ColumnParent.class);
    cp.columns.add(this);
}

It would be up to the Tree to determine whatever state to instantiate components from. Notice that the parent nor the child 'have' to keep reference since everything would be event scope. In terms of thing like iterative scopes, you could still only have one row of children instantiated, but because we primarily communicate via events and the components are thread safe, we can do the same kind of things we're doing in JSF with invokeOnComponent(...).

Also, there's an issue of XML UIs vs. Desktop UIs in that there's some magical build phase that occurs, so when events do start ariving, do you handle your configuration/build behavior differently? Should it constitute a separate build phase, or expect that everything is request scope, and use constructor injection, like SWT to 'nail' peformance? Facelets works the same way with constructor injection-- no one's complained about that API decision.