Ancestor controller patterns?

[James Carman <ja...@carmanconsulting.com>]

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

Re: Ancestor controller patterns?

[Martin Grigorov <mg...@apache.org>]

Component#isVisible() uses internally Component#isVisibleInHierarchy(), so
it should just work.
Or maybe I didn't understand you.

On Fri, Apr 20, 2018 at 3:25 PM, James Carman <ja...@carmanconsulting.com>
wrote:

> 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
>

Re: Ancestor controller patterns?

[Sven Meier <sv...@meiers.net>]

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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org