You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Bobby Rosenberger <br...@gmail.com> on 2005/12/07 19:07:40 UTC
disabled .vs readonly
Hello,
Can someone help me make a distinction between the disabled and readonly
tags? After some testing I've come to the conclusion that the only real
difference is that the 'readonly' attrib will disable an input field without
affecting its visual properties, whereas the 'disabled' attrib (a
pass-through attrib) WILL affect the visual props.
Interestingly, the 'readonly' attrib seems to have no affect on several of
the tags I tested with (ie. selectBooleanCheckbox, selectOneMenu, etc)
Any further clarification would be great. I'm trying to determine the
appropriate place to use these tags.
Thanks,
Bobby
AW: disabled .vs readonly
Posted by Matthias Kahlau <mk...@web.de>.
Hi!
I would like to give you a hint to the "displayValueOnly" attribute, which
exists for the selectOneRadio tag, for example. It might be an alternative
for the readonly attribute in some contexts.
Regards,
Matthias
-----Ursprungliche Nachricht-----
Von: users-return-13440-mkahlau=web.de@myfaces.apache.org
[mailto:users-return-13440-mkahlau=web.de@myfaces.apache.org]Im Auftrag von
Yee CN
Gesendet: Donnerstag, 8. Dezember 2005 03:56
An: 'MyFaces Discussion'
Betreff: RE: disabled .vs readonly
I believe that the real issue is that HTML check boxes and radio buttons
don't know about the 'readonly" attribute. So you can only set the
"disabled" attribute if you want to prevent user input. That will grey out
the check box, which I really hated. This is a different behavior from text
input, which can be both readonly and disabled.
I see that as a limitation of HTML, not JSF. I have been wishing we could
have a readonly checkbox in HTML for years!
Please correct me if I am wrong.
Regards,
Yee
----------------------------------------------------------------------------
--
From: Bobby Rosenberger [mailto:brosenberger@gmail.com]
Sent: Thursday, 8 December 2005 3:01 AM
To: MyFaces Discussion
Subject: Re: disabled .vs readonly
Comments below:
On 12/7/05, Andrew Robinson <an...@gmail.com> wrote:
Many thick client controls have the same properties. The usual
debate/answer that I find is this:
1) if the control should never be edited, mark it as read-only
2) if the control is temporarily disabled (i.e. you need to select a
radio button to enable the associated controls), then use disabled.
In general, a read-only controls is something to display data, not a
form control for submitting data. Since radio buttons and check boxes
are rarely ever used for display only, then it may make sense that
they do not support a read-only state.
Ah! But they do support it. According to the selectBooleanCheckbox
documentation (found at
http://java.sun.com/j2ee/javaserverfaces/1.1_01/docs/tlddocs/) the readonly
attrib is a:
" Flag indicating that this component will prohibit changes by the user.
The element may receive focus unless it has also been disabled."
I'm guessing this is a bug.
The statement above indicates that the "disabled" attrib will also prevent
focus on the component (in addition to modifying its visual props).
So maybe that's it... "readonly" allows focus and doesn't modify visual
properties, "disabled" does not allow focus and does change visual props...
Any further comments or clarifications are welcome.
My $0.02
-Andrew
Bobby
RE: disabled .vs readonly
Posted by Yee CN <ye...@streamyx.com>.
I believe that the real issue is that HTML check boxes and radio buttons
don't know about the 'readonly" attribute. So you can only set the
"disabled" attribute if you want to prevent user input. That will grey out
the check box, which I really hated. This is a different behavior from text
input, which can be both readonly and disabled.
I see that as a limitation of HTML, not JSF. I have been wishing we could
have a readonly checkbox in HTML for years!
Please correct me if I am wrong.
Regards,
Yee
_____
From: Bobby Rosenberger [mailto:brosenberger@gmail.com]
Sent: Thursday, 8 December 2005 3:01 AM
To: MyFaces Discussion
Subject: Re: disabled .vs readonly
Comments below:
On 12/7/05, Andrew Robinson <an...@gmail.com> wrote:
Many thick client controls have the same properties. The usual
debate/answer that I find is this:
1) if the control should never be edited, mark it as read-only
2) if the control is temporarily disabled (i.e. you need to select a
radio button to enable the associated controls), then use disabled.
In general, a read-only controls is something to display data, not a
form control for submitting data. Since radio buttons and check boxes
are rarely ever used for display only, then it may make sense that
they do not support a read-only state.
Ah! But they do support it. According to the selectBooleanCheckbox
documentation (found at
http://java.sun.com/j2ee/javaserverfaces/1.1_01/docs/tlddocs/) the readonly
attrib is a:
" Flag indicating that this component will prohibit changes by the user. The
element may receive focus unless it has also been disabled."
I'm guessing this is a bug.
The statement above indicates that the "disabled" attrib will also prevent
focus on the component (in addition to modifying its visual props).
So maybe that's it... "readonly" allows focus and doesn't modify visual
properties, "disabled" does not allow focus and does change visual props...
Any further comments or clarifications are welcome.
My $0.02
-Andrew
Bobby
Re: disabled .vs readonly
Posted by Bobby Rosenberger <br...@gmail.com>.
Comments below:
On 12/7/05, Andrew Robinson <an...@gmail.com> wrote:
>
> Many thick client controls have the same properties. The usual
> debate/answer that I find is this:
>
> 1) if the control should never be edited, mark it as read-only
2) if the control is temporarily disabled (i.e. you need to select a
> radio button to enable the associated controls), then use disabled.
>
> In general, a read-only controls is something to display data, not a
> form control for submitting data. Since radio buttons and check boxes
> are rarely ever used for display only, then it may make sense that
> they do not support a read-only state.
Ah! But they do support it. According to the selectBooleanCheckbox
documentation (found at
http://java.sun.com/j2ee/javaserverfaces/1.1_01/docs/tlddocs/) the readonly
attrib is a:
" Flag indicating that this component will prohibit changes by the user. The
element may receive focus unless it has also been disabled."
I'm guessing this is a bug.
The statement above indicates that the "disabled" attrib will also prevent
focus on the component (in addition to modifying its visual props).
So maybe that's it... "readonly" allows focus and doesn't modify visual
properties, "disabled" does not allow focus and does change visual props...
Any further comments or clarifications are welcome.
My $0.02
> -Andrew
Bobby
Re: disabled .vs readonly
Posted by Andrew Robinson <an...@gmail.com>.
Many thick client controls have the same properties. The usual
debate/answer that I find is this:
1) if the control should never be edited, mark it as read-only
2) if the control is temporarily disabled (i.e. you need to select a
radio button to enable the associated controls), then use disabled.
In general, a read-only controls is something to display data, not a
form control for submitting data. Since radio buttons and check boxes
are rarely ever used for display only, then it may make sense that
they do not support a read-only state.
My $0.02
-Andrew
On 12/7/05, Bobby Rosenberger <br...@gmail.com> wrote:
> Hello,
>
> Can someone help me make a distinction between the disabled and readonly
> tags? After some testing I've come to the conclusion that the only real
> difference is that the 'readonly' attrib will disable an input field without
> affecting its visual properties, whereas the 'disabled' attrib (a
> pass-through attrib) WILL affect the visual props.
>
> Interestingly, the 'readonly' attrib seems to have no affect on several of
> the tags I tested with (ie. selectBooleanCheckbox, selectOneMenu, etc)
>
> Any further clarification would be great. I'm trying to determine the
> appropriate place to use these tags.
>
> Thanks,
>
> Bobby
>
>