I had the same (at least it sounds similar) problem. My pages use a role-based authorization strategy. Sometimes the role is based upon the data on the page. A good example of this is Responsible Individual (RI); if you are not an RI, you have read-only access, but as soon as you are added to the RI List, you get read-write access to certain fields (maybe not all fields). In an effort to avoid page flashing, we use AJAX to refresh the components whose access are based upon the RI field.
At first the solution was specific to this scenario, then I realized that I could have any number of fields on the page that worked in concert with each other to either RENDER or ENABLE other fields based upon roles. In the end, I created an abstract methodology based on the concept of of Listeners. So, a field registers itself with another component as a listener, then the source component has the responsibility of telling the target components what to do and when to do it (in this case, repaint targets when source is updated). The rough idea: I use the Component MetaData on the source to store a List of target Component references. The whole design is based upon MetaDataRoleAuthorizationStrategy. Now, I know what you're thinking: What about the case where the source component hasn't been instantiated yet, but I want to register a target against it? Well, I use the Page (actually an object on the Page) and a custom Panel (that all other panels extend from) as mediators. A Component can actually register with another Component via an actual reference to the source Component or by "name". In the latter case, the source Component would have to register themselves with the Page/Panel in a Component registry. This helped with the problem of fragility because I didn't need to know the full path to a Component from the targets position which meant I could change the hierarchy without having to go back and adjust all these register() methods. That covers the basics of building the web of source/targets. Using the knowledge is up to the developer. For my immediate needs, whenever I repaint the source (which is usually due to an AJAX update of the model), I repaint anyone registered to me. I even created behaviors that extend AjaxFormComponentUpdatingBehavior to help make this even more transparent. I just reread this post and it seems a little abstract. If anyone is actually interested in this, I will do my best to elaborate. I also welcome criticism of this approach because I would hate to get into full production mode and find some stupid loophole that takes me "back to the drawing board". Chuck James McLaughlin-3 wrote: > > +1. It can be tedious sometimes figuring out how to update > components that are on the other side of the tree from the onClick. > > best, > jim > > On 5/30/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: >> >> >> 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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wicket-user >> > > ------------------------------------------------------------------------- > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-user > > -- View this message in context: http://www.nabble.com/Best-Practices-for-accessing-repainting-sibling-cousin-components--tf3841514.html#a10892376 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 [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
