Jason Lee wrote:
> 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...
JS issues asside, the spec requires the default renderers to check these
attributes and bypass decoding if they are true.
If a user needs custom behavior, I'd say they should have their own
renderer.
>
> -----
> 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/>
>
>