Clarification on defining component visibility

2011-11-11 Thread Adam Gray
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?


Re: Clarification on defining component visibility

2011-11-11 Thread Adam Gray
And, as usual, twitter ends up being faster.  Thanks Igor. 8)

Answer: none of the above (below?).  Call override onConfigure() and call 
setVisible() from there.

On Nov 11, 2011, at 4:14 PM, Adam Gray 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: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Clarification on defining component visibility

2011-11-11 Thread vineet semwal
setvisible(boolean) inside onconfigure()

On Sat, Nov 12, 2011 at 2:44 AM, Adam Gray adam.j.g...@gmail.com 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?




-- 
thank you,

regards,
Vineet Semwal

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Clarification on defining component visibility

2011-11-11 Thread Igor Vaynberg
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 adam.j.g...@gmail.com 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: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org