BTW, one thing that we do in the Trinidad component set
is use ValueBinding/ValueExpression.isReadOnly() in addition
to a "readonly" attribute. This way, if there's no
public setter, it's automatically read-only. (This
feature is why I asked for ValueBinding.isReadOnly()
back in JSF 1.0...)
-- Adam
Jesse Alexander (KSFD 121) wrote:
> will have to check it out...
> I just hope it will also cure the "need a public setter on a
> readonly-attribute"...
>
> will try to check
> Alexander
>
> -----Original Message-----
> From: Jason Lee [mailto:lee_at_iecokc.com]
> Sent: Thursday, February 01, 2007 5:49 PM
> To: dev_at_javaserverfaces.dev.java.net
> Subject: RE: Re: Util.componentIsDisabledOrReadonly(UIComponent
> component) Question
>
> Isn't the behavior now to block updating components marked readonly or
> disabled?
>
> -----
> Jason Lee, SCJP
> Programmer/Analyst
> http://www.iec-okc.com
>
>
>> -----Original Message-----
>> From: Adam Winer [mailto:adam.winer_at_oracle.com]
>> Sent: Wednesday, January 31, 2007 4:48 PM
>> To: dev_at_javaserverfaces.dev.java.net
>> Subject: Re: Util.componentIsDisabledOrReadonly(UIComponent
>> component) Question
>>
>> The original intent was definitely that readonly would block
>> submission, and that's how it worked in JSF 1.1.
>>
>> I agree with Jesse that there is a potential security hole if
>> the behavior remains as is. Developers use "readonly"
>> to mean "this field is not allowed to be edited by this
>> user", and allowing readonly fields to be updated opens up a hole.
>>
>> I agree that one might have a UI with a readonly field that
>> gets updated by JS, but:
>> - You could use <h:inputHidden> along the side
>> of the readonly field if necessary
>> - This is the *basic* HTML renderkit, and should
>> do the basics safely
>>
>> -- Adam
>>
>>
>>
>> Jason Lee said the following on 1/31/07 2:27 PM PT:
>>> Well, with the current behavior, the RI is forcing a
>> certain behavior
>>> on the author's application that the author may not want. Maybe
>>> there's a page that shows some data in a readonly textarea.
>> The user
>>> clicks on a link and a window pops up with a super fancy
>> editor. The
>>> user makes some changes and clicks OK, then JavaScript takes the
>>> values from Super Fancy Editor and updates the values on
>> the original
>>> page. While that may seem a bit contrived, I wouldn't be too
>>> surprised to see an app that behaves that way, which is a
>> reasonable expectation, I think...
>>>
>>> -----
>>> Jason Lee, SCJP
>>> Programmer/Analyst
>>> http://www.iec-okc.com <http://www.iec-okc.com/>
>>>
>>>
>>>
>> --------------------------------------------------------------
>> ----------
>>> *From:* Jesse Alexander (KSFD 121)
>>> [mailto:alexander.jesse_at_credit-suisse.com]
>>> *Sent:* Wednesday, January 31, 2007 4:14 PM
>>> *To:* dev_at_javaserverfaces.dev.java.net
>>> *Subject:* RE: Util.componentIsDisabledOrReadonly(UIComponent
>>> component) Question
>>>
>>> Why should I allow JS to change a value that I have
>> marked as readonly?
>>> I consider this to be a security hole...
>>>
>>> but then... JS is not really a good thing to use
>>>
>>> regards
>>> Alexander
>>>
>>>
>> --------------------------------------------------------------
>> ----------
>>> *From:* Jason Lee [mailto:lee_at_iecokc.com]
>>> *Sent:* Wednesday, January 31, 2007 10:56 PM
>>> *To:* dev_at_javaserverfaces.dev.java.net
>>> *Cc:* esnunes_at_dev.java.net
>>> *Subject:*
>> Util.componentIsDisabledOrReadonly(UIComponent component)
>>> Question
>>>
>>> A user reported on IRC that he's getting an
>> error/message about not
>>> having a setter for a textarea that is marked readonly. We were
>>> able to track down the issue to the method
>>> Util.componentIsDisabledOrReadonly(UIComponent
>> component). The code
>>> currently looks like this:
>>>
>>> public static boolean
>> componentIsDisabledOrReadonly(UIComponent
>>> component) {
>>>
>>> boolean disabledOrReadonly =
>>>
>>>
>> Boolean.valueOf(String.valueOf(component.getAttributes().get("
>> disabled")));
>>> if (disabledOrReadonly) {
>>> return true;
>>> }
>>> disabledOrReadonly =
>>>
>>>
>> Boolean.valueOf(String.valueOf(component.getAttributes().get("
>> disabled")));
>>> return disabledOrReadonly;
>>>
>>> }
>>>
>>> The most obvious problem is that the disabled attribute
>> is checked
>>> twice, and the readonly attribute is never checked.
>> Changing the
>>> second check to look at "readonly" is trivial. In
>> fact, unless my
>>> from-the-hip coding is off, one could say
>>>
>>> return
>>>
>> Boolean.valueOf(String.valueOf(component.getAttributes().get("
>> disabled")))
>>> ||
>>>
>>>
>> Boolean.valueOf(String.valueOf(component.getAttributes().get("readonly
>>> ")));
>>>
>>> A question arose during the discussion, though: Why is
>> this done at
>>> all. I told the questioner that performance was likely
>> the reason,
>>> but, as we discussed further, I began to see that this
>> behavior may
>>> actually break an app. Just becase a field is marked
>> readonly or
>>> disabled doesn't mean the value has not changed, as
>> JavaScript can
>>> easily change that value. That raise the question, though, of
>>> whether or not readonly or disable form elements are
>> submitted back
>>> to server on form submission. I've not tested to see that (the
>>> thought just occurred to me as I was typing :).
>>>
>>> So, do we retain this behavior with the fix noted
>> above, or should
>>> this behavior be removed?
>>>
>>> -----
>>> Jason Lee, SCJP
>>> Programmer/Analyst
>>> http://www.iec-okc.com <http://www.iec-okc.com/>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>