I just ran across this nuance this week If you have this:
wicket:enclosure child=comp1
div wicket:id=comp1/div
div wicket:id=comp2/div
/wicket:enclosure
Now, say comp1 is invisible, so the whole enclosure is invisible. Now, in
WicketTester, if you test assertInvisible(comp2), it will
This is a fundamental dilemma ;) Also on implementation side somebody
may implement:
1)
isvisible() {
return super.isvisible() businesslogic.isvisible();
}
or simply
2)
isvisible() {
return businesslogic.isvisible();
}
So if 2) is allowed and recommended, then isvisible is really only
Hi,
On Sun, Feb 13, 2011 at 6:18 PM, Jeremy Thomerson jer...@wickettraining.com
wrote:
I just ran across this nuance this week If you have this:
wicket:enclosure child=comp1
div wicket:id=comp1/div
div wicket:id=comp2/div
/wicket:enclosure
Now, say comp1 is invisible, so the
On Sun, Feb 13, 2011 at 11:46 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
This is a fundamental dilemma ;) Also on implementation side somebody
may implement:
1)
isvisible() {
return super.isvisible() businesslogic.isvisible();
}
or simply
2)
isvisible() {
return
I haven't looked at the exact implementation of
WicketTester, but I think we should change the logic to pass assertInvisible
if the component's isVisible method returns true, but some parent of the
component (an enclosure, etc) is not visible, since in all reality, the
component is then also
On Sun, Feb 13, 2011 at 1:32 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
I haven't looked at the exact implementation of
WicketTester, but I think we should change the logic to pass
assertInvisible
if the component's isVisible method returns true, but some parent of the
