You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Eyal Golan <eg...@gmail.com> on 2008/06/16 11:06:31 UTC
isVisible vs. setVisible
This is a "Best Practice" question.
Suppose I have a component and I want to set its visibility according to
certain parameters.
Suppose I can do it by overriding the isVisible but I can also use the
setVisible after creating the constructor.
Is there a preferable way?
Does it depend on the parameters I check?
thanks
--
Eyal Golan
egolan74@gmail.com
Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74
Re: isVisible vs. setVisible
Posted by Timo Rantalaiho <Ti...@ri.fi>.
On Mon, 16 Jun 2008, Eyal Golan wrote:
> This is a "Best Practice" question.
O-oh :)
http://www.satisfice.com/blog/archives/27
> Suppose I have a component and I want to set its visibility according to
> certain parameters.
> Suppose I can do it by overriding the isVisible but I can also use the
> setVisible after creating the constructor.
>
> Is there a preferable way?
As you can gather from the answers, it really depends,
though you should be well of by starting with the
consideration of overriding isVisible().
Our current project has a lot of components that disappear
and reappear and we have tried a lot of different ways of
visibility control. Many cases we can handle cleanly by
overriding isVisible(), but sometimes it gets so
complicated or has so many dependencies to other components
that it isn't practicable. Then we have gone with setting
the visibility explicitly case by case. We have extensive
unit tests anyway so things keep more or less under control,
although having stale state is a real danger.
A typical corner case where using the setter seems to make
sense to me is when you make a panel visible by pressing a
button (e.g. to create a new domain object) but the same
panel is then made invisble by a lot of different actions
which take the focus out of the panel.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Jonathan Locke <jo...@gmail.com>.
well, i think we simply live with a choice among evils. setters (and
getters) are not good (in fact, mutable state in general is problematic) and
other things are also bad, but java is not perfect and sometimes a non-ideal
technique is needed to get something done.
Eelco Hillenius wrote:
>
>> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
>
> Personally, I think that article is a bit far fetched. For a whole
> bunch of reasons, immutability should often be preferred, but at the
> same time Wicket is an example of a framework where mutability plays a
> big role (or we would have been fine providing a declarative
> programming model).
>
> The best sentence from that article to me is 'My point is that you
> should not program blindly.' :-)
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/isVisible-vs.-setVisible-tp17860615p17879044.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Eelco Hillenius <ee...@gmail.com>.
> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Personally, I think that article is a bit far fetched. For a whole
bunch of reasons, immutability should often be preferred, but at the
same time Wicket is an example of a framework where mutability plays a
big role (or we would have been fine providing a declarative
programming model).
The best sentence from that article to me is 'My point is that you
should not program blindly.' :-)
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Matthijs Wensveen <m....@func.nl>.
Nice!
Johan Compagner wrote:
> Igor already has plans to fix/change that
>
> something like isVisible and setVisible both final
> and then you can override visible() that we check for you in the isVisible()
> method (but first also we check our own flag)
> so both setVisible() and your overridden visible() are working fine. (and we
> can test other stuff like isVisibleInHierarchy and so on.
>
> johan
>
> On Mon, Jun 16, 2008 at 11:52 PM, Matthijs Wensveen <m....@func.nl>
> wrote:
>
>
>> Of course I have a few things to learn, and I hope I never stop learning.
>> The article you provide is interesting.
>>
>> My opinion is that for domain entity objects, getters and setters are
>> certainly not evil. For classes that are more service-like, getters and
>> setters could be useful but should be considered well. In case you choose
>> not to have a getter and a setter one should be extra careful when choosing
>> method names. I usually expect a setVisible method when there is also an
>> isVisible method. Immutable classes, or classes with read-only properties
>> can choose to only provide a getter for some properties. But if a method
>> like isVisible is intended to be overridden something like public boolean
>> visible() might be better. But I guess this is also a matter of style and
>> taste.
>>
>> As for Component.set/isVisible, I like that I can do both, even if it gives
>> me the possibility of ambiguous code like new Component() {isVisible()
>> {return true;};}.setVisible(false) or something like that (it is actually
>> not ambiguous at all of course, but you do have to read extra careful). So
>> whatever reason you (core devs) originally had for providing a setter, I am
>> thankful for that.
>>
>> Matthijs
>>
>>
>> Jonathan Locke wrote:
>>
>>
>>> i think you may have a few things to learn and it is not exactly
>>> controversial to prefer immutability or encapsulation... setters break
>>> encapsulation and i think it is safe to say decades of experience with
>>> object systems is on my side, including industry luminaries like:
>>>
>>> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
>>>
>>>
>>> Matthijs Wensveen-2 wrote:
>>>
>>>
>>>
>>>> Jonathan Locke wrote:
>>>>
>>>>
>>>>
>>>>> true.
>>>>> in the isVisible impl you could lazy-init cache a transient Boolean
>>>>> until
>>>>> end request where you set it null.
>>>>> setters are evil.
>>>>>
>>>>>
>>>>>
>>>> ..but it's good to have choice. *And* setVisible is not a normal setter,
>>>> because it returns the component, which makes it easy to add an initially
>>>> invisible component like: add(new Label("profanity",
>>>> "!$!@#").setVisible(false));
>>>>
>>>> Also, with is/setVisible you van use the component with a propertymodel
>>>> to have some other component toggle the visibility of another component.
>>>> This way you have the best of both worlds.
>>>>
>>>> A little off-topic: It scares me a little when core developer make bold
>>>> statements like: "setters are evil" and "I wouldn't mind final was the
>>>> default in java". Maybe I'm just being paranoid here...
>>>>
>>>> Matthijs
>>>>
>>>>
>>>>
>>>>
>>>>> egolan74 wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Yes but ...
>>>>>> isVisible may be triggered several times, while setVisible should only
>>>>>> be
>>>>>> called once (say if I do it only once after creating the component).
>>>>>> Usually I prefer the state driven way, but what if the logic has a lot
>>>>>> of
>>>>>> overhead?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jonathan Locke wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> isVisible is generally better imo because it is state driven. if you
>>>>>>> push instead of pull, the state can get stale.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Matthijs Wensveen
>>>> Func. Internet Integration
>>>> W http://www.func.nl
>>>> T +31 20 4230000
>>>> F +31 20 4223500
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Igor Vaynberg <ig...@gmail.com>.
yep. the problem right now is that we have:
set/isVisible - used by user to control visibility
set/isVisibleAllowed - used by the framework to enforce visibility
independent of user's choice
isRenderAllowed - used by authorization strategies
the true visibility of the component is actually the conjunction of
all three. this is really annoying because any time you want to really
make sure your component is visible you have to test all three and it
is not quiet obvious to the uninitiated.
imho you should be able to simply say component.isvisible() and use
that value because that is the most obvious method call. but this is a
big api break, so maybe in 1.5.
-igor
On Tue, Jun 17, 2008 at 12:15 AM, Johan Compagner <jc...@gmail.com> wrote:
> Igor already has plans to fix/change that
>
> something like isVisible and setVisible both final
> and then you can override visible() that we check for you in the isVisible()
> method (but first also we check our own flag)
> so both setVisible() and your overridden visible() are working fine. (and we
> can test other stuff like isVisibleInHierarchy and so on.
>
> johan
>
> On Mon, Jun 16, 2008 at 11:52 PM, Matthijs Wensveen <m....@func.nl>
> wrote:
>
>> Of course I have a few things to learn, and I hope I never stop learning.
>> The article you provide is interesting.
>>
>> My opinion is that for domain entity objects, getters and setters are
>> certainly not evil. For classes that are more service-like, getters and
>> setters could be useful but should be considered well. In case you choose
>> not to have a getter and a setter one should be extra careful when choosing
>> method names. I usually expect a setVisible method when there is also an
>> isVisible method. Immutable classes, or classes with read-only properties
>> can choose to only provide a getter for some properties. But if a method
>> like isVisible is intended to be overridden something like public boolean
>> visible() might be better. But I guess this is also a matter of style and
>> taste.
>>
>> As for Component.set/isVisible, I like that I can do both, even if it gives
>> me the possibility of ambiguous code like new Component() {isVisible()
>> {return true;};}.setVisible(false) or something like that (it is actually
>> not ambiguous at all of course, but you do have to read extra careful). So
>> whatever reason you (core devs) originally had for providing a setter, I am
>> thankful for that.
>>
>> Matthijs
>>
>>
>> Jonathan Locke wrote:
>>
>>> i think you may have a few things to learn and it is not exactly
>>> controversial to prefer immutability or encapsulation... setters break
>>> encapsulation and i think it is safe to say decades of experience with
>>> object systems is on my side, including industry luminaries like:
>>>
>>> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
>>>
>>>
>>> Matthijs Wensveen-2 wrote:
>>>
>>>
>>>> Jonathan Locke wrote:
>>>>
>>>>
>>>>> true.
>>>>> in the isVisible impl you could lazy-init cache a transient Boolean
>>>>> until
>>>>> end request where you set it null.
>>>>> setters are evil.
>>>>>
>>>>>
>>>> ..but it's good to have choice. *And* setVisible is not a normal setter,
>>>> because it returns the component, which makes it easy to add an initially
>>>> invisible component like: add(new Label("profanity",
>>>> "!$!@#").setVisible(false));
>>>>
>>>> Also, with is/setVisible you van use the component with a propertymodel
>>>> to have some other component toggle the visibility of another component.
>>>> This way you have the best of both worlds.
>>>>
>>>> A little off-topic: It scares me a little when core developer make bold
>>>> statements like: "setters are evil" and "I wouldn't mind final was the
>>>> default in java". Maybe I'm just being paranoid here...
>>>>
>>>> Matthijs
>>>>
>>>>
>>>>
>>>>> egolan74 wrote:
>>>>>
>>>>>
>>>>>> Yes but ...
>>>>>> isVisible may be triggered several times, while setVisible should only
>>>>>> be
>>>>>> called once (say if I do it only once after creating the component).
>>>>>> Usually I prefer the state driven way, but what if the logic has a lot
>>>>>> of
>>>>>> overhead?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jonathan Locke wrote:
>>>>>>
>>>>>>
>>>>>>> isVisible is generally better imo because it is state driven. if you
>>>>>>> push instead of pull, the state can get stale.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> --
>>>> Matthijs Wensveen
>>>> Func. Internet Integration
>>>> W http://www.func.nl
>>>> T +31 20 4230000
>>>> F +31 20 4223500
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Johan Compagner <jc...@gmail.com>.
Igor already has plans to fix/change that
something like isVisible and setVisible both final
and then you can override visible() that we check for you in the isVisible()
method (but first also we check our own flag)
so both setVisible() and your overridden visible() are working fine. (and we
can test other stuff like isVisibleInHierarchy and so on.
johan
On Mon, Jun 16, 2008 at 11:52 PM, Matthijs Wensveen <m....@func.nl>
wrote:
> Of course I have a few things to learn, and I hope I never stop learning.
> The article you provide is interesting.
>
> My opinion is that for domain entity objects, getters and setters are
> certainly not evil. For classes that are more service-like, getters and
> setters could be useful but should be considered well. In case you choose
> not to have a getter and a setter one should be extra careful when choosing
> method names. I usually expect a setVisible method when there is also an
> isVisible method. Immutable classes, or classes with read-only properties
> can choose to only provide a getter for some properties. But if a method
> like isVisible is intended to be overridden something like public boolean
> visible() might be better. But I guess this is also a matter of style and
> taste.
>
> As for Component.set/isVisible, I like that I can do both, even if it gives
> me the possibility of ambiguous code like new Component() {isVisible()
> {return true;};}.setVisible(false) or something like that (it is actually
> not ambiguous at all of course, but you do have to read extra careful). So
> whatever reason you (core devs) originally had for providing a setter, I am
> thankful for that.
>
> Matthijs
>
>
> Jonathan Locke wrote:
>
>> i think you may have a few things to learn and it is not exactly
>> controversial to prefer immutability or encapsulation... setters break
>> encapsulation and i think it is safe to say decades of experience with
>> object systems is on my side, including industry luminaries like:
>>
>> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
>>
>>
>> Matthijs Wensveen-2 wrote:
>>
>>
>>> Jonathan Locke wrote:
>>>
>>>
>>>> true.
>>>> in the isVisible impl you could lazy-init cache a transient Boolean
>>>> until
>>>> end request where you set it null.
>>>> setters are evil.
>>>>
>>>>
>>> ..but it's good to have choice. *And* setVisible is not a normal setter,
>>> because it returns the component, which makes it easy to add an initially
>>> invisible component like: add(new Label("profanity",
>>> "!$!@#").setVisible(false));
>>>
>>> Also, with is/setVisible you van use the component with a propertymodel
>>> to have some other component toggle the visibility of another component.
>>> This way you have the best of both worlds.
>>>
>>> A little off-topic: It scares me a little when core developer make bold
>>> statements like: "setters are evil" and "I wouldn't mind final was the
>>> default in java". Maybe I'm just being paranoid here...
>>>
>>> Matthijs
>>>
>>>
>>>
>>>> egolan74 wrote:
>>>>
>>>>
>>>>> Yes but ...
>>>>> isVisible may be triggered several times, while setVisible should only
>>>>> be
>>>>> called once (say if I do it only once after creating the component).
>>>>> Usually I prefer the state driven way, but what if the logic has a lot
>>>>> of
>>>>> overhead?
>>>>>
>>>>>
>>>>>
>>>>> Jonathan Locke wrote:
>>>>>
>>>>>
>>>>>> isVisible is generally better imo because it is state driven. if you
>>>>>> push instead of pull, the state can get stale.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> Matthijs Wensveen
>>> Func. Internet Integration
>>> W http://www.func.nl
>>> T +31 20 4230000
>>> F +31 20 4223500
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: isVisible vs. setVisible
Posted by Matthijs Wensveen <m....@func.nl>.
Never underestimate the power of the Dark Side! :)
Jonathan Locke wrote:
> i imagine setVisible came from me. just because setters are evil and you
> should avoid them when you can does not mean you should not use them when
> you need them.
>
>
> Matthijs Wensveen-2 wrote:
>
>> Of course I have a few things to learn, and I hope I never stop
>> learning. The article you provide is interesting.
>>
>> My opinion is that for domain entity objects, getters and setters are
>> certainly not evil. For classes that are more service-like, getters and
>> setters could be useful but should be considered well. In case you
>> choose not to have a getter and a setter one should be extra careful
>> when choosing method names. I usually expect a setVisible method when
>> there is also an isVisible method. Immutable classes, or classes with
>> read-only properties can choose to only provide a getter for some
>> properties. But if a method like isVisible is intended to be overridden
>> something like public boolean visible() might be better. But I guess
>> this is also a matter of style and taste.
>>
>> As for Component.set/isVisible, I like that I can do both, even if it
>> gives me the possibility of ambiguous code like new Component()
>> {isVisible() {return true;};}.setVisible(false) or something like that
>> (it is actually not ambiguous at all of course, but you do have to read
>> extra careful). So whatever reason you (core devs) originally had for
>> providing a setter, I am thankful for that.
>>
>> Matthijs
>>
>> Jonathan Locke wrote:
>>
>>> i think you may have a few things to learn and it is not exactly
>>> controversial to prefer immutability or encapsulation... setters break
>>> encapsulation and i think it is safe to say decades of experience with
>>> object systems is on my side, including industry luminaries like:
>>>
>>> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
>>>
>>>
>>> Matthijs Wensveen-2 wrote:
>>>
>>>
>>>> Jonathan Locke wrote:
>>>>
>>>>
>>>>> true.
>>>>>
>>>>> in the isVisible impl you could lazy-init cache a transient Boolean
>>>>> until
>>>>> end request where you set it null.
>>>>>
>>>>> setters are evil.
>>>>>
>>>>>
>>>>>
>>>> ..but it's good to have choice. *And* setVisible is not a normal setter,
>>>> because it returns the component, which makes it easy to add an
>>>> initially invisible component like: add(new Label("profanity",
>>>> "!$!@#").setVisible(false));
>>>>
>>>> Also, with is/setVisible you van use the component with a propertymodel
>>>> to have some other component toggle the visibility of another component.
>>>> This way you have the best of both worlds.
>>>>
>>>> A little off-topic: It scares me a little when core developer make bold
>>>> statements like: "setters are evil" and "I wouldn't mind final was the
>>>> default in java". Maybe I'm just being paranoid here...
>>>>
>>>> Matthijs
>>>>
>>>>
>>>>
>>>>> egolan74 wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Yes but ...
>>>>>> isVisible may be triggered several times, while setVisible should only
>>>>>> be
>>>>>> called once (say if I do it only once after creating the component).
>>>>>> Usually I prefer the state driven way, but what if the logic has a lot
>>>>>> of
>>>>>> overhead?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jonathan Locke wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> isVisible is generally better imo because it is state driven. if you
>>>>>>> push instead of pull, the state can get stale.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Matthijs Wensveen
>>>> Func. Internet Integration
>>>> W http://www.func.nl
>>>> T +31 20 4230000
>>>> F +31 20 4223500
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>>
>
>
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Jonathan Locke <jo...@gmail.com>.
i imagine setVisible came from me. just because setters are evil and you
should avoid them when you can does not mean you should not use them when
you need them.
Matthijs Wensveen-2 wrote:
>
> Of course I have a few things to learn, and I hope I never stop
> learning. The article you provide is interesting.
>
> My opinion is that for domain entity objects, getters and setters are
> certainly not evil. For classes that are more service-like, getters and
> setters could be useful but should be considered well. In case you
> choose not to have a getter and a setter one should be extra careful
> when choosing method names. I usually expect a setVisible method when
> there is also an isVisible method. Immutable classes, or classes with
> read-only properties can choose to only provide a getter for some
> properties. But if a method like isVisible is intended to be overridden
> something like public boolean visible() might be better. But I guess
> this is also a matter of style and taste.
>
> As for Component.set/isVisible, I like that I can do both, even if it
> gives me the possibility of ambiguous code like new Component()
> {isVisible() {return true;};}.setVisible(false) or something like that
> (it is actually not ambiguous at all of course, but you do have to read
> extra careful). So whatever reason you (core devs) originally had for
> providing a setter, I am thankful for that.
>
> Matthijs
>
> Jonathan Locke wrote:
>> i think you may have a few things to learn and it is not exactly
>> controversial to prefer immutability or encapsulation... setters break
>> encapsulation and i think it is safe to say decades of experience with
>> object systems is on my side, including industry luminaries like:
>>
>> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
>>
>>
>> Matthijs Wensveen-2 wrote:
>>
>>> Jonathan Locke wrote:
>>>
>>>> true.
>>>>
>>>> in the isVisible impl you could lazy-init cache a transient Boolean
>>>> until
>>>> end request where you set it null.
>>>>
>>>> setters are evil.
>>>>
>>>>
>>> ..but it's good to have choice. *And* setVisible is not a normal setter,
>>> because it returns the component, which makes it easy to add an
>>> initially invisible component like: add(new Label("profanity",
>>> "!$!@#").setVisible(false));
>>>
>>> Also, with is/setVisible you van use the component with a propertymodel
>>> to have some other component toggle the visibility of another component.
>>> This way you have the best of both worlds.
>>>
>>> A little off-topic: It scares me a little when core developer make bold
>>> statements like: "setters are evil" and "I wouldn't mind final was the
>>> default in java". Maybe I'm just being paranoid here...
>>>
>>> Matthijs
>>>
>>>
>>>> egolan74 wrote:
>>>>
>>>>
>>>>> Yes but ...
>>>>> isVisible may be triggered several times, while setVisible should only
>>>>> be
>>>>> called once (say if I do it only once after creating the component).
>>>>> Usually I prefer the state driven way, but what if the logic has a lot
>>>>> of
>>>>> overhead?
>>>>>
>>>>>
>>>>>
>>>>> Jonathan Locke wrote:
>>>>>
>>>>>
>>>>>> isVisible is generally better imo because it is state driven. if you
>>>>>> push instead of pull, the state can get stale.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> Matthijs Wensveen
>>> Func. Internet Integration
>>> W http://www.func.nl
>>> T +31 20 4230000
>>> F +31 20 4223500
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/isVisible-vs.-setVisible-tp17860615p17879066.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Matthijs Wensveen <m....@func.nl>.
Of course I have a few things to learn, and I hope I never stop
learning. The article you provide is interesting.
My opinion is that for domain entity objects, getters and setters are
certainly not evil. For classes that are more service-like, getters and
setters could be useful but should be considered well. In case you
choose not to have a getter and a setter one should be extra careful
when choosing method names. I usually expect a setVisible method when
there is also an isVisible method. Immutable classes, or classes with
read-only properties can choose to only provide a getter for some
properties. But if a method like isVisible is intended to be overridden
something like public boolean visible() might be better. But I guess
this is also a matter of style and taste.
As for Component.set/isVisible, I like that I can do both, even if it
gives me the possibility of ambiguous code like new Component()
{isVisible() {return true;};}.setVisible(false) or something like that
(it is actually not ambiguous at all of course, but you do have to read
extra careful). So whatever reason you (core devs) originally had for
providing a setter, I am thankful for that.
Matthijs
Jonathan Locke wrote:
> i think you may have a few things to learn and it is not exactly
> controversial to prefer immutability or encapsulation... setters break
> encapsulation and i think it is safe to say decades of experience with
> object systems is on my side, including industry luminaries like:
>
> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
>
>
> Matthijs Wensveen-2 wrote:
>
>> Jonathan Locke wrote:
>>
>>> true.
>>>
>>> in the isVisible impl you could lazy-init cache a transient Boolean until
>>> end request where you set it null.
>>>
>>> setters are evil.
>>>
>>>
>> ..but it's good to have choice. *And* setVisible is not a normal setter,
>> because it returns the component, which makes it easy to add an
>> initially invisible component like: add(new Label("profanity",
>> "!$!@#").setVisible(false));
>>
>> Also, with is/setVisible you van use the component with a propertymodel
>> to have some other component toggle the visibility of another component.
>> This way you have the best of both worlds.
>>
>> A little off-topic: It scares me a little when core developer make bold
>> statements like: "setters are evil" and "I wouldn't mind final was the
>> default in java". Maybe I'm just being paranoid here...
>>
>> Matthijs
>>
>>
>>> egolan74 wrote:
>>>
>>>
>>>> Yes but ...
>>>> isVisible may be triggered several times, while setVisible should only
>>>> be
>>>> called once (say if I do it only once after creating the component).
>>>> Usually I prefer the state driven way, but what if the logic has a lot
>>>> of
>>>> overhead?
>>>>
>>>>
>>>>
>>>> Jonathan Locke wrote:
>>>>
>>>>
>>>>> isVisible is generally better imo because it is state driven. if you
>>>>> push instead of pull, the state can get stale.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>> --
>> Matthijs Wensveen
>> Func. Internet Integration
>> W http://www.func.nl
>> T +31 20 4230000
>> F +31 20 4223500
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Jonathan Locke <jo...@gmail.com>.
i think you may have a few things to learn and it is not exactly
controversial to prefer immutability or encapsulation... setters break
encapsulation and i think it is safe to say decades of experience with
object systems is on my side, including industry luminaries like:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Matthijs Wensveen-2 wrote:
>
> Jonathan Locke wrote:
>> true.
>>
>> in the isVisible impl you could lazy-init cache a transient Boolean until
>> end request where you set it null.
>>
>> setters are evil.
>>
>
> ..but it's good to have choice. *And* setVisible is not a normal setter,
> because it returns the component, which makes it easy to add an
> initially invisible component like: add(new Label("profanity",
> "!$!@#").setVisible(false));
>
> Also, with is/setVisible you van use the component with a propertymodel
> to have some other component toggle the visibility of another component.
> This way you have the best of both worlds.
>
> A little off-topic: It scares me a little when core developer make bold
> statements like: "setters are evil" and "I wouldn't mind final was the
> default in java". Maybe I'm just being paranoid here...
>
> Matthijs
>
>>
>> egolan74 wrote:
>>
>>> Yes but ...
>>> isVisible may be triggered several times, while setVisible should only
>>> be
>>> called once (say if I do it only once after creating the component).
>>> Usually I prefer the state driven way, but what if the logic has a lot
>>> of
>>> overhead?
>>>
>>>
>>>
>>> Jonathan Locke wrote:
>>>
>>>> isVisible is generally better imo because it is state driven. if you
>>>> push instead of pull, the state can get stale.
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
> --
> Matthijs Wensveen
> Func. Internet Integration
> W http://www.func.nl
> T +31 20 4230000
> F +31 20 4223500
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/isVisible-vs.-setVisible-tp17860615p17866358.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Martijn Dashorst <ma...@gmail.com>.
On Mon, Jun 16, 2008 at 4:15 PM, Matthijs Wensveen <m....@func.nl> wrote:
> I disagree that you expose internal state. It's hardly internal when there
> is a public setter.
You are contradicting yourself: the sole purpose of a public setter is
to expose internal state. Therefore setters are evil. In the very
least it allows for confusing semantics when overrides are allowed. A
setter is nice for a data object, but that is it.
IMO setting the any property outside the owning object breaks the
encapsulation of the object, but I'm pragmatic enough to consider
setting visible to false when I feel like it :)
Setters push people into an interaction driven design, where testing
is made considerably difficult, because the internal state is made
public. I'd love to create objects where I modify the state through
actions on the objects, but frameworks such as hibernate and others
'force' me into providing getters and setters. It also takes somewhat
longer to get the object model right when trying to not use
setters/getters.
Martijn
> But I agree that it is often very useful to override the
> getter (isser for booleans?) when there is a hard dependency between the
> component visibility and some other state. As I said: it's good to have
> choice.
>>
>> Martijn
>>
>>
>
>
> --
> Matthijs Wensveen
> Func. Internet Integration
> W http://www.func.nl
> T +31 20 4230000
> F +31 20 4223500
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Antoine Angenieux <aa...@clinigrid.com>.
That's why I almost always override isVisible like
@Override boolean isVisible() {
return super.isVisible() && myVisibilityConstraints;
}
Thus I can go for both approches (push and / or pull state).
Maybe this could be added to the Javadoc of isVisible ?
Just my 2 cents,
Antoine.
Matthijs Wensveen wrote:
> Martijn Dashorst wrote:
>> On Mon, Jun 16, 2008 at 3:48 PM, Matthijs Wensveen
>> <m....@func.nl> wrote:
>>
>>> A little off-topic: It scares me a little when core developer make bold
>>> statements like: "setters are evil" and "I wouldn't mind final was the
>>> default in java". Maybe I'm just being paranoid here...
>>>
>>
>> Why? Are we not allowed an opinion?
>
> Why off-course! Am I not allowed to be scared? ;P
>
>> And from an OO point of view, I
>> can see how setters break encapsulation: they expose the internal
>> state of an object. In the case of setVisible this is exacerbated
>> because the semantics of the following are vague:
>>
>> Label l = new Label("l", "foo") {
>> @Override boolean isVisible() { return false; }
>> };
>> l.setVisible(true);
>> add(l);
>>
>> So either you'd want final to be the default, or you'd consider
>> setters evil. :-D
>>
>
> Hehe. Maybe in that case you should override setVisible as well to throw
> an UnsupportedOperationException?
>
> I disagree that you expose internal state. It's hardly internal when
> there is a public setter. But I agree that it is often very useful to
> override the getter (isser for booleans?) when there is a hard
> dependency between the component visibility and some other state. As I
> said: it's good to have choice.
>> Martijn
>>
>>
>
>
--
Antoine Angénieux
Associé
Clinigrid
5, avenue Mozart
75016 Paris, France
+336 60 21 09 18
aangenieux@clinigrid.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Matthijs Wensveen <m....@func.nl>.
Martijn Dashorst wrote:
> On Mon, Jun 16, 2008 at 3:48 PM, Matthijs Wensveen <m....@func.nl> wrote:
>
>> A little off-topic: It scares me a little when core developer make bold
>> statements like: "setters are evil" and "I wouldn't mind final was the
>> default in java". Maybe I'm just being paranoid here...
>>
>
> Why? Are we not allowed an opinion?
Why off-course! Am I not allowed to be scared? ;P
> And from an OO point of view, I
> can see how setters break encapsulation: they expose the internal
> state of an object. In the case of setVisible this is exacerbated
> because the semantics of the following are vague:
>
> Label l = new Label("l", "foo") {
> @Override boolean isVisible() { return false; }
> };
> l.setVisible(true);
> add(l);
>
> So either you'd want final to be the default, or you'd consider
> setters evil. :-D
>
Hehe. Maybe in that case you should override setVisible as well to throw
an UnsupportedOperationException?
I disagree that you expose internal state. It's hardly internal when
there is a public setter. But I agree that it is often very useful to
override the getter (isser for booleans?) when there is a hard
dependency between the component visibility and some other state. As I
said: it's good to have choice.
> Martijn
>
>
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Martijn Dashorst <ma...@gmail.com>.
On Mon, Jun 16, 2008 at 3:48 PM, Matthijs Wensveen <m....@func.nl> wrote:
> A little off-topic: It scares me a little when core developer make bold
> statements like: "setters are evil" and "I wouldn't mind final was the
> default in java". Maybe I'm just being paranoid here...
Why? Are we not allowed an opinion? And from an OO point of view, I
can see how setters break encapsulation: they expose the internal
state of an object. In the case of setVisible this is exacerbated
because the semantics of the following are vague:
Label l = new Label("l", "foo") {
@Override boolean isVisible() { return false; }
};
l.setVisible(true);
add(l);
So either you'd want final to be the default, or you'd consider
setters evil. :-D
Martijn
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Matthijs Wensveen <m....@func.nl>.
Jonathan Locke wrote:
> true.
>
> in the isVisible impl you could lazy-init cache a transient Boolean until
> end request where you set it null.
>
> setters are evil.
>
..but it's good to have choice. *And* setVisible is not a normal setter,
because it returns the component, which makes it easy to add an
initially invisible component like: add(new Label("profanity",
"!$!@#").setVisible(false));
Also, with is/setVisible you van use the component with a propertymodel
to have some other component toggle the visibility of another component.
This way you have the best of both worlds.
A little off-topic: It scares me a little when core developer make bold
statements like: "setters are evil" and "I wouldn't mind final was the
default in java". Maybe I'm just being paranoid here...
Matthijs
>
> egolan74 wrote:
>
>> Yes but ...
>> isVisible may be triggered several times, while setVisible should only be
>> called once (say if I do it only once after creating the component).
>> Usually I prefer the state driven way, but what if the logic has a lot of
>> overhead?
>>
>>
>>
>> Jonathan Locke wrote:
>>
>>> isVisible is generally better imo because it is state driven. if you
>>> push instead of pull, the state can get stale.
>>>
>>>
>>>
>>
>
>
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Jonathan Locke <jo...@gmail.com>.
true.
in the isVisible impl you could lazy-init cache a transient Boolean until
end request where you set it null.
setters are evil.
egolan74 wrote:
>
> Yes but ...
> isVisible may be triggered several times, while setVisible should only be
> called once (say if I do it only once after creating the component).
> Usually I prefer the state driven way, but what if the logic has a lot of
> overhead?
>
>
>
> Jonathan Locke wrote:
>>
>>
>> isVisible is generally better imo because it is state driven. if you
>> push instead of pull, the state can get stale.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/isVisible-vs.-setVisible-tp17860615p17861099.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by egolan74 <eg...@gmail.com>.
Yes but ...
isVisible may be triggered several times, while setVisible should only be
called once (say if I do it only once after creating the component).
Usually I prefer the state driven way, but what if the logic has a lot of
overhead?
Jonathan Locke wrote:
>
>
> isVisible is generally better imo because it is state driven. if you push
> instead of pull, the state can get stale.
>
>
-----
Eyal Golan
egolan74@gmail.com
Visit: http://jvdrums.sourceforge.net/ http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74
http://www.linkedin.com/in/egolan74
--
View this message in context: http://www.nabble.com/isVisible-vs.-setVisible-tp17860615p17860930.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: isVisible vs. setVisible
Posted by Jonathan Locke <jo...@gmail.com>.
isVisible is generally better imo because it is state driven. if you push
instead of pull, the state can get stale.
Eyal Golan wrote:
>
> This is a "Best Practice" question.
> Suppose I have a component and I want to set its visibility according to
> certain parameters.
> Suppose I can do it by overriding the isVisible but I can also use the
> setVisible after creating the constructor.
>
> Is there a preferable way?
> Does it depend on the parameters I check?
>
> thanks
>
> --
> Eyal Golan
> egolan74@gmail.com
>
> Visit: http://jvdrums.sourceforge.net/
> LinkedIn: http://www.linkedin.com/in/egolan74
>
>
--
View this message in context: http://www.nabble.com/isVisible-vs.-setVisible-tp17860615p17860647.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org