The primary reason for not using IModel's as control mechanisms for visibility and enabling of components is memory usage. Wicket applications can have millions of Component instances at any given time in runtime memory, and adding 2 references plus the overhead of the IModel objects would be quite heavy.
This is also why we didn't opt for lambda's as a basic construct when we migrated Wicket to Java 8. Martijn On Mon, May 10, 2021 at 4:29 PM <s...@stantastic.nl> wrote: > 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 > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
