You often need to know overall UI state to determine visibility, and you would end up with anonymous model classes of some sorts, so my educated guess is there is not much expected benefit, only caveats. One would expect a model to work and end up doing twice the work eventually using an anonymous class or overriding onConfigure.
** Martin ma 10. toukok. 2021 klo 17.29 s...@stantastic.nl kirjoitti: > So I finally took the plunge and joined the mailing list. > > I have been using Wicket for well over a year now and am very happy to > have stumbled across it. There's just one question that I never really > found an answer to. I have searched the users list a couple of times and > found that some people are trying to use the 'setVisible' and > 'setEnabled' methods with a Model-argument. They want do this in order > to dynamically change visibility or access to a component. This idea has > also crossed my mind a couple of times. > > The thing is... Wicket doesn't appear to work that way. > > When I look at the answers, I see two approaches. One is overriding > 'isVisible', the other is to configure visibility from the 'onConfigure' > method in the parent component. I tend to use the later. > > Because I always like to understand how things work, I would like to ask > about the reasoning behind this. Why can't 'setVisible' and 'setEnabled' > be controlled using IModel<Boolean> arguments? Is there a technical > limitation here? Or is it just a quirk? > > Thanks. > > Stan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
