Mats Norén-2 wrote: > > It would be great of you had some code to share, it makes it easier to > follow... :) >
Yeah, no kidding.. :) Here is a quickstart (minus the lib folder, see below for list of jars) that should illustrate what I am trying to accomplish, yes it's pretty stupid, but hopefully covers some of the normal usage scenarios... http://www.nabble.com/file/p10895313/quickstart-listener.zip quickstart-listener.zip One problem that I know that it suffers from is that Components that should act as "event source's" can't be named _easily_ within a repeater. You'll have to use an actual Component reference (instead of the name) in those cases. Chuck Here is the contents of my lib folder, this should be standard for a quickstart... commons-collections-3.2.jar commons-logging-1.0.4.jar jetty-6.1.1.jar jetty-management-6.1.1.jar jetty-util-6.1.1.jar log4j-1.2.13.jar mx4j-3.0.1.jar mx4j-tools-3.0.1.jar servlet-api-2.5-6.1.1.jar slf4j-api-1.3.1.jar slf4j-log4j12-1.3.1.jar wicket-1.3.0-incubating-SNAPSHOT.jar (latest version) wicket-extensions-1.3.0-incubating-SNAPSHOT.jar (latest version) Mats Norén-2 wrote: > > On 5/31/07, ChuckDeal <[EMAIL PROTECTED]> wrote: >> >> 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 >> >> Wicket-user@lists.sourceforge.net >> >> 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 >> > Wicket-user@lists.sourceforge.net >> > 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. > -- View this message in context: http://www.nabble.com/Best-Practices-for-accessing-repainting-sibling-cousin-components--tf3841514.html#a10895313 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
