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