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
