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

From: Jason Lee <>
Date: Wed, 31 Jan 2007 16:27:32 -0600

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 <>


        From: Jesse Alexander (KSFD 121)
        Sent: Wednesday, January 31, 2007 4:14 PM
        Subject: RE: Util.componentIsDisabledOrReadonly(UIComponent
component) Question
        Why should I allow JS to change a value that I have marked as
        I consider this to be a security hole...
        but then... JS is not really a good thing to use


        From: Jason Lee []
        Sent: Wednesday, January 31, 2007 10:56 PM
        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 =
                if (disabledOrReadonly) {
                    return true;
                disabledOrReadonly =
                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
)) ||
        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 <>