Re: Why aren't setEnabled and setVisible model based?
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 https://javadoc.io/doc/org.wicketstuff/wicketstuff-minis/latest/org/wicketstuff/minis/behavior/VisibleModelBehavior.html The behaviors both take a boolean model in their constructor. In the Behavior#onConfigure method, they use the model value to set whether the component is enabled or visible. Thanks Andrew On Tue, May 11, 2021 at 3:34 AM Martijn Dashorst wrote: > 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 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 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 >
Re: Why aren't setEnabled and setVisible model based?
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 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 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
Re: Why aren't setEnabled and setVisible model based?
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 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 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 >> >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Why aren't setEnabled and setVisible model based?
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 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 > >
Why aren't setEnabled and setVisible model based?
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 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
