On Sun, Feb 13, 2011 at 11:46 AM, Martin Makundi <
[email protected]> 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 businesslogic.isvisible();
> }
>
>
> So if 2) is allowed and recommended, then isvisible is really only
> businesslogic test instead of real visibilty check.
>
Yeah, but that's in the component itself - which means that the business
logic check IS the visibility determining factor. Wicket will call
isVisible, and it won't appear because of your business logic. You just
disabled people from calling setVisible(false) and also hiding it.
But, I'm asking more about WicketTester and related components that aren't
visible because something in the hierarchy above them is not visible - in
this case an enclosure. 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 invisible.
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
