afair this is already explained in the javadoc of onconfigure

label { onconfigure() { link.onconfigure(); setvisible(link.isvisible()); }}

-igor

On Mon, Dec 6, 2010 at 7:35 AM, Jeremy Thomerson
<jer...@wickettraining.com> wrote:
> Igor,
>
>  I agree that there are places that using onConfigure / setVisible may be
> better than overriding isVisible.  However, I often have the following type
> of scenario, and wonder how you would suggest doing it without overriding
> isVisible:
>
> Situation: one component depends on the visibility of another (sibling)
> component for its visibility.  if using onConfigure / setVisible, wouldn't
> there be an order-of-operations problem?
>
> Example:
> final Link next = new Link("next") {
> onConfigure() { setVisible(someCalculatedState); }
> }
>
> Label nextLabel = new Label("nextLabel") {
> onConfigure() { setVisible(next.isVisible()); }
> }
>
> I could do that before by overriding isVisible (rather than onConfigure) for
> both.  Then, when nextLabel#isVisible called next#isVisible to calculate its
> state, it was guaranteed that next would return the proper info.  But now,
> you could have the following situation:
>
> Render 1:
> both are visible
>
> Render 2:
> something has changed and now "someCalculatedState" will be false
> nextLabel is configured first and sets visible to true since next has not
> yet reconfigured based on the new state
> next is configured, and sets visibility to false based on the new state
>
> I suppose the best way to accomplish this with the onConfigure/setVisible
> method is to do onConfigure() { setVisible(calculateSomeState()); }.... the
> problem is that it makes it more difficult to create generic components this
> way (a label that takes another component as constructor arg and uses that
> component to determine its visibility).
>
> Thoughts?
>
> --
> Jeremy Thomerson
> http://wickettraining.com
> *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
>

Reply via email to