if the component itself controls its own visibility the best way is to
override onConfigure() and call setVisible() inside

if an outside component controls another's visibility the best way is
to override the controlling component's onconfigure() and call
controlled.setVisible()

if you have a simple state toggle, like "when i click this link i want
this component's visibility to change" then calling
component.setVisible() is fine

if you have a cross-cutting concern (auth strategy, configurelistener,
beforerenderlistener, etc) overriding component's visibility then call
component.setVisibilityAllowed(). Wicket ands this bit with the
visible bit to determine final visibility; this way the cross-cutting
concern wont dirty component's visibility attribute.

if all of these fail, as a last resort override component.isvisible()
but be warned that this has a few pitfalls:
* it is called multiple times per request, potentially tens of times,
so keep the implementation computationally light
* this value should remain stable across the render/respond boundary.
meaning if isvisible() returns true when rendering a button, but when
the button is clicked returns false you will get an error

-igor

On Fri, Nov 11, 2011 at 1:14 PM, Adam Gray <[email protected]> wrote:
> Recently some co-workers and I started questioning what is the (most)
> correct method for determining component visibility.  In the past we've
> gone from calling setVisible() to overriding isVisible() and now are
> finding some people pointed to using setVisibilityAllowed() in
> onBeforeRender while override callOnBeforeRenderIfNotVisible() to return
> true.  Clearly, there are some pitfalls/gotchas to each method, but we're
> trying to develop a clean and consistent codebase (or rather, trying to
> make a dirty and inconsistent codebase less so).  What is the intended,
> preferred, or rules-of-thumb for how to accomplish this?  Is some
> combination of these methods the inevitable result, or is there a
> consistent method to this?
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to