Hi James,
so you want to configure a component inside a (possibly deeply) nested
hierarchy from the outside?
Searching up the component tree for an implementation of an interface
seems like a good idea.
Problem with that solution is that this interface might grow bigger and
bigger as your requirements increase:
- is an address required?
- is the age field visible?
- what are the available choices for a dropdown?
I have used a very generic solution once, where properties of the
application domain can be constrained dynamically, e.g. something like:
Mypage extends WebPage implements IConstraintsHolder {
IConstraints getConstraints() {
constraints.put(model, "address", new RequiredBehavior());
constraints.put(model, "age", new InvisibleBehavior());
return constraints;
}
}
Now any component can pull its corresponding constraint from any
constraints holder up in the hierarchy. With an IInitializationListener
you can make this transparent.
Have fun
Sven
Am 20.04.2018 um 14:25 schrieb James Carman:
I have a scenario where a certain type of component should typically be
invisible, but in certain scenarios, it neeeds to become visible. That
visibility can be changed by anybody in its ancestry and the closest one to
the component should decide. Anyway, do we have established patterns for
this? Do I make the guys who want to control this visibility implement
some interface and search for them up the hierarchy? Is there a different
way?
Thanks,
James
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
