Re: [Wicket-user] Best Practices for accessing/repainting sibling/cousin components?

2007-06-06 Thread dukejansen
I'm not sure the use case is common or consistent enough. Too often I have two panels with two separate model objects that are both backed by the same actual underlying object, so the code I wrote below will fail anyway. I actually think using a marker interface on Components might be more

Re: [Wicket-user] Best Practices for accessing/repainting sibling/cousin components?

2007-06-05 Thread dukejansen
I've gone ahead and implemented this, but instead of using the Component.saveInnermostModel method, I coded up my own. The implementation in Component only traverses IWrapModel implementations, not IChainedModel implementations. My implementation handles both. Note that this will only find

Re: [Wicket-user] Best Practices for accessing/repainting sibling/cousin components?

2007-06-05 Thread Matej Knopp
TBH I don't see this as a very common usecase. And it's not difficult to implement on your own (although the code isn't entirely trivial). -Matej On 6/5/07, Eelco Hillenius [EMAIL PROTECTED] wrote: That looks like a lot of work actually. Johan, others, you think we should build in better

Re: [Wicket-user] Best Practices for accessing/repainting sibling/cousin components?

2007-05-31 Thread ChuckDeal
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

Re: [Wicket-user] Best Practices for accessing/repainting sibling/cousin components?

2007-05-31 Thread Mats Norén
It would be great of you had some code to share, it makes it easier to follow... :) /Mats 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

Re: [Wicket-user] Best Practices for accessing/repainting sibling/cousin components?

2007-05-31 Thread ChuckDeal
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

[Wicket-user] Best Practices for accessing/repainting sibling/cousin components?

2007-05-30 Thread dukejansen
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

Re: [Wicket-user] Best Practices for accessing/repainting sibling/cousin components?

2007-05-30 Thread Jonathan Locke
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

Re: [Wicket-user] Best Practices for accessing/repainting sibling/cousin components?

2007-05-30 Thread Jonathan Locke
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

Re: [Wicket-user] Best Practices for accessing/repainting sibling/cousin components?

2007-05-30 Thread James McLaughlin
+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