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",
"[EMAIL PROTECTED]").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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
