dev@javaserverfaces.java.net

RE: Re: Util.componentIsDisabledOrReadonly(UIComponent component) Question

From: Jason Lee <lee_at_iecokc.com>
Date: Wed, 31 Jan 2007 16:45:21 -0600

Sounds good to me. Fix committed.

-----
Jason Lee, SCJP
Programmer/Analyst
http://www.iec-okc.com
 

> -----Original Message-----
> From: Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM]
> Sent: Wednesday, January 31, 2007 4:42 PM
> To: dev_at_javaserverfaces.dev.java.net
> Subject: Re: Util.componentIsDisabledOrReadonly(UIComponent
> component) Question
>
> 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/>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>