You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Gargi Iyer <Ga...@dcf.state.fl.us> on 2007/08/30 19:20:33 UTC
disable, readonly bug
I noticed that while using disable or readonly attributes of <t:inputText>
or <h:inputText>, when the disable attribute changes from true to false and
then value of the input text field is changed, the change does not take
effect. When the disable attribute switches to true again, the old value is
redisplayed and not the changed value.
The setter methods of the property bound to the inputText are not being
called.
This case arises only when the disabled attribute = true at page load time.
I saw an entire application using value change listeners to call the field
setter methods manually. I think this totally ruins the fun in using JSF.
Has anybody else noticed this behaviour? and does anyone have a solution
for this?
Thanks
Gargi
850-414-5852
CONFIDENTIALITY NOTICE: This message and any attachments are for the sole
use of the intended recipient(s) and may contain confidential and
privileged information that is exempt from public disclosure. Any
unauthorized review, use, disclosure, or distribution is prohibited. If
you have received this message in error please contact the sender (by phone
or reply electronic mail) and then destroy all copies of the original
message.
Re: disable, readonly bug
Posted by Gargi Iyer <Ga...@dcf.state.fl.us>.
Thanks for the hint, David
My problem was I was usign a request scoped bean to store the flag for
disable attribute. I used <t:saveState> on the flag and it works.
Gargi
850-414-5852
David Delbecq
<delbd+jakarta@om
a.be> To
MyFaces Discussion
08/30/2007 01:44 <us...@myfaces.apache.org>
PM cc
Subject
Please respond to Re: disable, readonly bug
"MyFaces
Discussion"
<users@myfaces.ap
ache.org>
Hi,
Your problem, i think is that you submit a value to the field and , in
same resquest, try to change the disabled attribute of field.
For a specific field's value to go from submit to backing bean, the
disabled attribute msut be false at all steps of lifecycle:
apply-request value (to store the submitted value)
validation (all form is being validated)
update model (disabled field do not update model)
At each step, the EL-expression of your "disabled" field is evaluated.
i think (difficult to say without sample of your jsf form) that your
bean property handling the disabled state changes at the wrong time.
example, you enter a value in non-disabled field, un check the "activate
box" and submit. The box has been configured, probably, with
immediate=true, this mean the field goes to disabled state before it's
apply-request value gets called.
Another possibility could be you store this state (disabled) in a
request scoped bean which default to true. Then, until you reach update
model, the field is considered disabled.
Those are just supposition, need jsf sample to confirm.
Gargi Iyer a écrit :
>
>
> I noticed that while using disable or readonly attributes of
<t:inputText>
> or <h:inputText>, when the disable attribute changes from true to false
and
> then value of the input text field is changed, the change does not take
> effect. When the disable attribute switches to true again, the old value
is
> redisplayed and not the changed value.
>
> The setter methods of the property bound to the inputText are not being
> called.
>
> This case arises only when the disabled attribute = true at page load
time.
>
> I saw an entire application using value change listeners to call the
field
> setter methods manually. I think this totally ruins the fun in using
JSF.
> Has anybody else noticed this behaviour? and does anyone have a solution
> for this?
>
> Thanks
>
> Gargi
> 850-414-5852
> CONFIDENTIALITY NOTICE: This message and any attachments are for the
sole
> use of the intended recipient(s) and may contain confidential and
> privileged information that is exempt from public disclosure. Any
> unauthorized review, use, disclosure, or distribution is prohibited. If
> you have received this message in error please contact the sender (by
phone
> or reply electronic mail) and then destroy all copies of the original
> message.
>
Re: disable, readonly bug
Posted by David Delbecq <de...@oma.be>.
Hi,
Your problem, i think is that you submit a value to the field and , in
same resquest, try to change the disabled attribute of field.
For a specific field's value to go from submit to backing bean, the
disabled attribute msut be false at all steps of lifecycle:
apply-request value (to store the submitted value)
validation (all form is being validated)
update model (disabled field do not update model)
At each step, the EL-expression of your "disabled" field is evaluated.
i think (difficult to say without sample of your jsf form) that your
bean property handling the disabled state changes at the wrong time.
example, you enter a value in non-disabled field, un check the "activate
box" and submit. The box has been configured, probably, with
immediate=true, this mean the field goes to disabled state before it's
apply-request value gets called.
Another possibility could be you store this state (disabled) in a
request scoped bean which default to true. Then, until you reach update
model, the field is considered disabled.
Those are just supposition, need jsf sample to confirm.
Gargi Iyer a écrit :
>
>
> I noticed that while using disable or readonly attributes of <t:inputText>
> or <h:inputText>, when the disable attribute changes from true to false and
> then value of the input text field is changed, the change does not take
> effect. When the disable attribute switches to true again, the old value is
> redisplayed and not the changed value.
>
> The setter methods of the property bound to the inputText are not being
> called.
>
> This case arises only when the disabled attribute = true at page load time.
>
> I saw an entire application using value change listeners to call the field
> setter methods manually. I think this totally ruins the fun in using JSF.
> Has anybody else noticed this behaviour? and does anyone have a solution
> for this?
>
> Thanks
>
> Gargi
> 850-414-5852
> CONFIDENTIALITY NOTICE: This message and any attachments are for the sole
> use of the intended recipient(s) and may contain confidential and
> privileged information that is exempt from public disclosure. Any
> unauthorized review, use, disclosure, or distribution is prohibited. If
> you have received this message in error please contact the sender (by phone
> or reply electronic mail) and then destroy all copies of the original
> message.
>
Re: disable, readonly bug
Posted by Mike Kienenberger <mk...@gmail.com>.
html disabled attribute means don't send the input field value back to
the server when the form is submitted. If you want to be able to
change the field value, don't set the field disabled. (or at least
use javascript to un-disable it before you submit the form)
On 8/30/07, Gargi Iyer <Ga...@dcf.state.fl.us> wrote:
>
>
>
>
> I noticed that while using disable or readonly attributes of <t:inputText>
> or <h:inputText>, when the disable attribute changes from true to false and
> then value of the input text field is changed, the change does not take
> effect. When the disable attribute switches to true again, the old value is
> redisplayed and not the changed value.
>
> The setter methods of the property bound to the inputText are not being
> called.
>
> This case arises only when the disabled attribute = true at page load time.
>
> I saw an entire application using value change listeners to call the field
> setter methods manually. I think this totally ruins the fun in using JSF.
> Has anybody else noticed this behaviour? and does anyone have a solution
> for this?
>
> Thanks
>
> Gargi
> 850-414-5852
> CONFIDENTIALITY NOTICE: This message and any attachments are for the sole
> use of the intended recipient(s) and may contain confidential and
> privileged information that is exempt from public disclosure. Any
> unauthorized review, use, disclosure, or distribution is prohibited. If
> you have received this message in error please contact the sender (by phone
> or reply electronic mail) and then destroy all copies of the original
> message.
>
>