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*
