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
relia
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 su
That looks like a lot of work actually. Johan, others, you think we
should build in better support for this in Wicket?
Eelco
On 6/5/07, dukejansen <[EMAIL PROTECTED]> wrote:
> I've gone ahead and implemented this, but instead of using the
> Component.saveInnermostModel method, I coded up my own.
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 compone
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 hope
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
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
+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
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
ver
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 o
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
11 matches
Mail list logo