Maybe another way to auto-ajax-update a component would be to have it do that whenever its model changes. There are a lot of caveats with model change notifications, but that seems to be a pretty clean idea if the rules for model changes were respected. Might make a good RFE for next Wicket version.
Jonathan Locke wrote: > > > It shouldn't be hard to write the method you're talking about. To find > all the components using the same model as a given component, just walk > the component hierarchy using visitChildren() and add any component which > returns true for sameInnermostModel(component). > > There is a more general case of this problem though where one area of a > web page may need to be updated because some completely unrelated area > changed. This I'm handling by hand right now, but I was asking a day or > two ago if there was a way to add a component to every ajax request (Eelco > answered that you can do this by implementing a request processor, I > think). It seems to be pretty common in an AJAX request to want a global > feedback component to update. Maybe we could have a poor-man's version of > this where if you override some boolean method, your component will get > auto-ajax-updated on every AJAX request. For many problems, this would be > convenient because it's easier to just update the thing every time than to > think about all the places it might need to be updated. > > > dukejansen wrote: >> >> I have some state which backs two panels, Panel A and Panel B, that may >> be included as part of other panels. Ultimately they are both on the same >> page, and their backing state is shared via the model class that backs >> both of them. Panel A has an Ajax event handler which modifies the >> backing model state, after which I want to force Panel A and Panel B to >> repaint. >> >> I've dealt with this in a few different ways so far, and they all bother >> me: >> >> 1. Walk up the containership tree and back down again until I find the >> panel with a known ID or which implements a specific marker interface, >> finding it that way. (Or do a full DFS of the tree to be thorough.) >> >> 2. Assume how my Panel is included and how the other Panel are included, >> and explicitly walk up and back down the containership tree. This is >> fragile because if I decide to rework panel containership, the method >> could fail. >> >> Is there some better way of doing this that I'm missing? A best practice >> for reaching out to siblings and cousins? >> >> Or something more fundamental to trigger refreshes of all componets >> backed by that model? Seems like a common use case. A component updates >> some state as part of ajax event, then wants to use ajax to repaint any >> other components backed by that state. >> >> Interested to hear how others have solved this problem. >> >> -Jason >> > > -- View this message in context: http://www.nabble.com/Best-Practices-for-accessing-repainting-sibling-cousin-components--tf3841514.html#a10883894 Sent from the Wicket - User mailing list archive at Nabble.com. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
