I see that it is not such an obvious win here as with fat client but how
about another of my use cases:
* Large page with small parts being updated by Ajax
* Two components sitting long way apart in the tree (context sensitive
button that responds to items in rest of the page)

So having an almost declaritive style "this button is enabled = fn(x)" only
works if I know when to re-render that button.
I seem to be leaving OO behind by having lots of procedural "when x happens
update a, b and c" rather than a subscribing to events from another
component.

Using some sort of event model seems to me to improve OO -> encapsulation ->
reuse. For large trees of components with only tiny parts that need sending
to the client it also seems more efficient

we have a similar use case, where a tabbed panel displays items in different workflow states. To simplify:
Tab 1: lists all new items
Tab 2: lists all reviewed items
Tab 3: lists all closed items

For each list item, an ItemPanel is displayed, containing a button that will put the item in the next workflow state. We wanted to reuse this panel in all tabs. In order to be able to properly update models without hard coding page hierarchy into the ItemPanel, we defined an interface ItemStateChangeHandler, that provides the hook onItemStateChange(newState).

All tabs implement this interface, and each ItemPanel is created with a reference to the ItemStateChangeHandler that is to be notified when it's about to change state. So when the 'nextState' button is clicked, the handler is notified and will be able to do stuff in the business layer (i.e. persist new state), adjust the list view's model and update the relevant components.

Kind of home brew though, so we're very curious as to how others would implement a case like this.

Kind regards,
Wouter

--
Wouter Huijnink
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to