Here is a thread where I posted a quickstart with our solution: http://www.nabble.com/Best-Practices-for-accessing-repainting-sibling-cousin-components--tf3841514.html#a10895313. This is with Wicket 1.3.0
The basic idea is that a component registers itself as a listener to another component and the list of registered lisenters is stored in the component's metadata. Chuck Sam Hough wrote: > > 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#a12899373 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
