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