You can use a behavior to set whether a component is visible or enabled
based on a model.
The wicketstuff-minis project has two behaviors that do just this:
https://javadoc.io/doc/org.wicketstuff/wicketstuff-minis/latest/org/wicketstuff/minis/behavior/EnabledModelBehavior.html
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
Perhaps this is true, but now with lambda models, might it not be more useful
to do this?
Jon
> On May 10, 2021, at 7:36 AM, Martin Terra
> wrote:
>
> 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
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
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
