[Seaside] ValueHolder use?

[Avi Bryant]

I've seen a few places in my Seaside code recently that benefit from
widespread use of ValueHolders - that is, rather than passing in objects
directly to components, passing in ValueHolders (or StateHolders)
containing them.

The cases I'm especially aware of are those where one component is making
a selection from a list of objects, and another (or many other) components
must update based on that selection.

For example, consider the Explorer tool.  This has a tree of items
down the left, and several tabs showing details of those items on the
right.  This means that any time someone selects an item in the tree, each
of the tab panels has to update which item they are detailing.

Right now, the tree notifies its parent of the change, and the parent
rebuilds the tab panel in response.  This works, but seems unnecesarrily
complex, and could be much simplified if all of the components involved -
tree, inspector, pretty printer, etc - were expecting a ValueHolder
instead of a direct object; the tree would simply change the contents of
the holder, and everything would update properly.

The problem is that it seems like you can't take this approach by half
measures - if any one of the tabs didn't accept a ValueHolder, then the
parent would still need to be notified of the update (so that it could
notify the errant tab in turn), and you would end up with two
inconsistent simple systems instead of one complex one.

Does anyone with more experience with this pattern (and with UI events in
general) want to comment?  It seems like, in general, VW makes heavy use
of ValueHolders for UI, whereas Squeak makes more use of #changed events;
does anyone know why?

Would it make sense to begin sending #value or #contents to all model
objects in some types of components, as a matter of policy?

Avi