Maybe something like: http://www.javaworld.com/javaworld/jw-11-2001/jw-1109-subscriber.html?page=4
No big extra jars... Would be nice if buttons could just subscribe to some standard set of messages (e.g. change of focus) Wouter Huijnink wrote: > > >> 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] > > > -- View this message in context: http://www.nabble.com/Inter-component-events--tf4508127.html#a12879006 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
