You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "sean schofield (JIRA)" <in...@incubator.apache.org> on 2005/02/16 15:26:46 UTC
[jira] Created: (MYFACES-108) UIInput should not store submitted value in the state
UIInput should not store submitted value in the state
-----------------------------------------------------
Key: MYFACES-108
URL: http://issues.apache.org/jira/browse/MYFACES-108
Project: MyFaces
Type: Improvement
Versions: 1.0.7 beta, 1.0.8 beta
Reporter: sean schofield
Priority: Trivial
Submitted value really shouldn't be stored in the state. At a minimum it is confusing and results in extra bandwith with client-side state saving. Heath points out that in most cases the value being "stored" will probably be null. That being said, if the code is totally unecessary we ought to consider removing it. I will leave this issue open for a while to make sure nobody has any issues with fixing it. This will affect a lot of components so I want to be sure this is the right thing to do. I will provide a patch eventually.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (MYFACES-108) UIInput should not store submitted value in the state
Posted by Jon Travis <jt...@p00p.org>.
Likely the problem I'm having is something else. I've
posted on the user list with some more specific details.
-- Jon
On Mar 28, 2005, at 6:54 PM, Adam Winer wrote:
> submittedValue should be stored in saved state.
>
> An example where it actually matters: put an <h:inputText> inside of a
> container that toggles its contents on and off during Apply Request
> Values (<af:showDetail immediate="true"> is an example). Type a value
> into the inputText, and immediately toggle that container shut. When
> you re-expand the container, if you don't save submittedValue, the
> field will be blank.
>
> Optimizing the case where it is null (in general, optimizing state
> saving to deal with the common scenario of lots of not-set properties)
> would be a fine thing, but you shouldn't simply not store it.
>
> The RI, FWIW, does not save submittedValue, which should be a bug (and
> is quite likely my fault!), but ADF Faces does in our input components
> for exactly this reason.
>
> -- Adam Winer
>
>
> On Tue, 29 Mar 2005 03:14:18 +0200 (CEST), Jon Travis (JIRA)
> <in...@incubator.apache.org> wrote:
>> [
>> http://issues.apache.org/jira/browse/MYFACES-108?
>> page=comments#action_61690 ]
>>
>> Jon Travis commented on MYFACES-108:
>> ------------------------------------
>>
>> I am having an issue in the current release (1.0.9 ... head?)
>>
>> Basically text inputs are coming back from POSTs as "" instead
>> of 'null' (I don't change any values). When the renderutils check
>> to see if the object is null, it fails (and thus, always renders ""
>> instead
>> of grabbing the value from the model bean)
>>
>>> UIInput should not store submitted value in the state
>>> -----------------------------------------------------
>>>
>>> Key: MYFACES-108
>>> URL: http://issues.apache.org/jira/browse/MYFACES-108
>>> Project: MyFaces
>>> Type: Improvement
>>> Versions: 1.0.7 beta, 1.0.8 beta
>>> Reporter: sean schofield
>>> Priority: Trivial
>>
>>>
>>> Submitted value really shouldn't be stored in the state. At a
>>> minimum it is confusing and results in extra bandwith with
>>> client-side state saving. Heath points out that in most cases the
>>> value being "stored" will probably be null. That being said, if the
>>> code is totally unecessary we ought to consider removing it. I will
>>> leave this issue open for a while to make sure nobody has any issues
>>> with fixing it. This will affect a lot of components so I want to
>>> be sure this is the right thing to do. I will provide a patch
>>> eventually.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the
>> administrators:
>> http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> If you want more information on JIRA, or have a bug to report see:
>> http://www.atlassian.com/software/jira
>>
>>
>
>
Re: [jira] Commented: (MYFACES-108) UIInput should not store submitted value in the state
Posted by Adam Winer <aw...@gmail.com>.
submittedValue should be stored in saved state.
An example where it actually matters: put an <h:inputText> inside of a
container that toggles its contents on and off during Apply Request
Values (<af:showDetail immediate="true"> is an example). Type a value
into the inputText, and immediately toggle that container shut. When
you re-expand the container, if you don't save submittedValue, the
field will be blank.
Optimizing the case where it is null (in general, optimizing state
saving to deal with the common scenario of lots of not-set properties)
would be a fine thing, but you shouldn't simply not store it.
The RI, FWIW, does not save submittedValue, which should be a bug (and
is quite likely my fault!), but ADF Faces does in our input components
for exactly this reason.
-- Adam Winer
On Tue, 29 Mar 2005 03:14:18 +0200 (CEST), Jon Travis (JIRA)
<in...@incubator.apache.org> wrote:
> [ http://issues.apache.org/jira/browse/MYFACES-108?page=comments#action_61690 ]
>
> Jon Travis commented on MYFACES-108:
> ------------------------------------
>
> I am having an issue in the current release (1.0.9 ... head?)
>
> Basically text inputs are coming back from POSTs as "" instead
> of 'null' (I don't change any values). When the renderutils check
> to see if the object is null, it fails (and thus, always renders "" instead
> of grabbing the value from the model bean)
>
> > UIInput should not store submitted value in the state
> > -----------------------------------------------------
> >
> > Key: MYFACES-108
> > URL: http://issues.apache.org/jira/browse/MYFACES-108
> > Project: MyFaces
> > Type: Improvement
> > Versions: 1.0.7 beta, 1.0.8 beta
> > Reporter: sean schofield
> > Priority: Trivial
>
> >
> > Submitted value really shouldn't be stored in the state. At a minimum it is confusing and results in extra bandwith with client-side state saving. Heath points out that in most cases the value being "stored" will probably be null. That being said, if the code is totally unecessary we ought to consider removing it. I will leave this issue open for a while to make sure nobody has any issues with fixing it. This will affect a lot of components so I want to be sure this is the right thing to do. I will provide a patch eventually.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
>
Re: [jira] Commented: (MYFACES-108) UIInput should not store submitted value in the state
Posted by Heath Borders <he...@gmail.com>.
That's a good point. You've convinced me! :-)
On Tue, 22 Feb 2005 16:15:49 +0100 (CET), Manfred Geiler (JIRA)
<in...@incubator.apache.org> wrote:
> [ http://issues.apache.org/jira/browse/MYFACES-108?page=comments#action_59590 ]
>
> Manfred Geiler commented on MYFACES-108:
> ----------------------------------------
>
> Yes, true if you have a classical "one form page". Then the submitted (invalid) value is also always part of the normal request parameters and the component could get it from there.
> But:
> Imagine a more complex page with two forms side by side. Now the user enters something in form 1 and submits it. The entered value is invalid, so the model bean is not updated yet. The submitted value gets redisplayed (somehow). Next the user does something in form 2 and submits it. Now the submitted value in form 1 will disappear, because the model does not know anything of this value and the component in form 1 would not have saved state information about the submitted value.
> You might say "why should someone have two forms on one page?". Well, with complex page designs (tiles) you cannot always have just one form. Imagine the following practical user interface example:
> One tile displays an input wizard where the user should enter some information. Another tile displays a help tile aside (perhaps a help component with index and search feature). User enters a bad value in the input form. Page is redisplayed. User uses the help component to find the reason why the entered value is not allowed. He uses the search feature of the help component, so he submits a form other than the input form. If we would not save state, all entered values would disappear now. Not very user friendly. ;-)
>
>
> > UIInput should not store submitted value in the state
> > -----------------------------------------------------
> >
> > Key: MYFACES-108
> > URL: http://issues.apache.org/jira/browse/MYFACES-108
> > Project: MyFaces
> > Type: Improvement
> > Versions: 1.0.7 beta, 1.0.8 beta
> > Reporter: sean schofield
> > Priority: Trivial
>
> >
> > Submitted value really shouldn't be stored in the state. At a minimum it is confusing and results in extra bandwith with client-side state saving. Heath points out that in most cases the value being "stored" will probably be null. That being said, if the code is totally unecessary we ought to consider removing it. I will leave this issue open for a while to make sure nobody has any issues with fixing it. This will affect a lot of components so I want to be sure this is the right thing to do. I will provide a patch eventually.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: [jira] Commented: (MYFACES-108) UIInput should not store submitted value in the state
Posted by Heath Borders <he...@gmail.com>.
I agree. I think we can rely on the client to submit all the form
values every time. Thus, the submitted value in the state is just
going to be constantly overwritten.
On Mon, 21 Feb 2005 18:07:52 +0100 (CET), sean schofield (JIRA)
<in...@incubator.apache.org> wrote:
> [ http://issues.apache.org/jira/browse/MYFACES-108?page=comments#action_59518 ]
>
> sean schofield commented on MYFACES-108:
> ----------------------------------------
>
> I would disagree that submitted value must be stored in the state. I am relatively new to Faces though so I could be mistaken.
>
> I agree with you that if there is a validation error, then the incorrect value needs to be redisplayed. I don't understand, however, why the submitted value needs to be stored in the state to accomplish this. The state is really only needed for the Restore View phase. The rendering code that displays the submitted value instead of the actual value can get the submitted value from the component itself. After this is done there is no need to store this bogus value in the state. It has already been sent to the user and the user can either resubmit the same bogus value or try a new one.
>
> If you check UIInput in the RI they are not saving the submitted value to state either. If we are relying on the submitted value to be stored in the state, that is probably not a good idea.
>
> > UIInput should not store submitted value in the state
> > -----------------------------------------------------
> >
> > Key: MYFACES-108
> > URL: http://issues.apache.org/jira/browse/MYFACES-108
> > Project: MyFaces
> > Type: Improvement
> > Versions: 1.0.7 beta, 1.0.8 beta
> > Reporter: sean schofield
> > Priority: Trivial
>
> >
> > Submitted value really shouldn't be stored in the state. At a minimum it is confusing and results in extra bandwith with client-side state saving. Heath points out that in most cases the value being "stored" will probably be null. That being said, if the code is totally unecessary we ought to consider removing it. I will leave this issue open for a while to make sure nobody has any issues with fixing it. This will affect a lot of components so I want to be sure this is the right thing to do. I will provide a patch eventually.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
>
--
-Heath Borders-Wing
hborders@mail.win.org
[jira] Commented: (MYFACES-108) UIInput should not store submitted value in the state
Posted by "Alessandro Polverini (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-108?page=comments#action_59797 ]
Alessandro Polverini commented on MYFACES-108:
----------------------------------------------
Also, if I'm not mistaken, saving values in the state is necessary for correct handling of tabs (x:panelTabbedPane) ?
> UIInput should not store submitted value in the state
> -----------------------------------------------------
>
> Key: MYFACES-108
> URL: http://issues.apache.org/jira/browse/MYFACES-108
> Project: MyFaces
> Type: Improvement
> Versions: 1.0.7 beta, 1.0.8 beta
> Reporter: sean schofield
> Priority: Trivial
>
> Submitted value really shouldn't be stored in the state. At a minimum it is confusing and results in extra bandwith with client-side state saving. Heath points out that in most cases the value being "stored" will probably be null. That being said, if the code is totally unecessary we ought to consider removing it. I will leave this issue open for a while to make sure nobody has any issues with fixing it. This will affect a lot of components so I want to be sure this is the right thing to do. I will provide a patch eventually.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-108) UIInput should not store submitted value in the state
Posted by "Manfred Geiler (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-108?page=comments#action_59590 ]
Manfred Geiler commented on MYFACES-108:
----------------------------------------
Yes, true if you have a classical "one form page". Then the submitted (invalid) value is also always part of the normal request parameters and the component could get it from there.
But:
Imagine a more complex page with two forms side by side. Now the user enters something in form 1 and submits it. The entered value is invalid, so the model bean is not updated yet. The submitted value gets redisplayed (somehow). Next the user does something in form 2 and submits it. Now the submitted value in form 1 will disappear, because the model does not know anything of this value and the component in form 1 would not have saved state information about the submitted value.
You might say "why should someone have two forms on one page?". Well, with complex page designs (tiles) you cannot always have just one form. Imagine the following practical user interface example:
One tile displays an input wizard where the user should enter some information. Another tile displays a help tile aside (perhaps a help component with index and search feature). User enters a bad value in the input form. Page is redisplayed. User uses the help component to find the reason why the entered value is not allowed. He uses the search feature of the help component, so he submits a form other than the input form. If we would not save state, all entered values would disappear now. Not very user friendly. ;-)
> UIInput should not store submitted value in the state
> -----------------------------------------------------
>
> Key: MYFACES-108
> URL: http://issues.apache.org/jira/browse/MYFACES-108
> Project: MyFaces
> Type: Improvement
> Versions: 1.0.7 beta, 1.0.8 beta
> Reporter: sean schofield
> Priority: Trivial
>
> Submitted value really shouldn't be stored in the state. At a minimum it is confusing and results in extra bandwith with client-side state saving. Heath points out that in most cases the value being "stored" will probably be null. That being said, if the code is totally unecessary we ought to consider removing it. I will leave this issue open for a while to make sure nobody has any issues with fixing it. This will affect a lot of components so I want to be sure this is the right thing to do. I will provide a patch eventually.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-108) UIInput should not store submitted value in the state
Posted by "Manfred Geiler (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-108?page=comments#action_59492 ]
Manfred Geiler commented on MYFACES-108:
----------------------------------------
Submitted value MUST be saved in state.
Whenever a component has a non-valid value the submitted value must be saved in state to be restored for redisplaying. Otherwise the value would be lost, because the bound model bean does not know anything of the new value yet.
> UIInput should not store submitted value in the state
> -----------------------------------------------------
>
> Key: MYFACES-108
> URL: http://issues.apache.org/jira/browse/MYFACES-108
> Project: MyFaces
> Type: Improvement
> Versions: 1.0.7 beta, 1.0.8 beta
> Reporter: sean schofield
> Priority: Trivial
>
> Submitted value really shouldn't be stored in the state. At a minimum it is confusing and results in extra bandwith with client-side state saving. Heath points out that in most cases the value being "stored" will probably be null. That being said, if the code is totally unecessary we ought to consider removing it. I will leave this issue open for a while to make sure nobody has any issues with fixing it. This will affect a lot of components so I want to be sure this is the right thing to do. I will provide a patch eventually.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-108) UIInput should not store submitted value in the state
Posted by "sean schofield (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-108?page=comments#action_59518 ]
sean schofield commented on MYFACES-108:
----------------------------------------
I would disagree that submitted value must be stored in the state. I am relatively new to Faces though so I could be mistaken.
I agree with you that if there is a validation error, then the incorrect value needs to be redisplayed. I don't understand, however, why the submitted value needs to be stored in the state to accomplish this. The state is really only needed for the Restore View phase. The rendering code that displays the submitted value instead of the actual value can get the submitted value from the component itself. After this is done there is no need to store this bogus value in the state. It has already been sent to the user and the user can either resubmit the same bogus value or try a new one.
If you check UIInput in the RI they are not saving the submitted value to state either. If we are relying on the submitted value to be stored in the state, that is probably not a good idea.
> UIInput should not store submitted value in the state
> -----------------------------------------------------
>
> Key: MYFACES-108
> URL: http://issues.apache.org/jira/browse/MYFACES-108
> Project: MyFaces
> Type: Improvement
> Versions: 1.0.7 beta, 1.0.8 beta
> Reporter: sean schofield
> Priority: Trivial
>
> Submitted value really shouldn't be stored in the state. At a minimum it is confusing and results in extra bandwith with client-side state saving. Heath points out that in most cases the value being "stored" will probably be null. That being said, if the code is totally unecessary we ought to consider removing it. I will leave this issue open for a while to make sure nobody has any issues with fixing it. This will affect a lot of components so I want to be sure this is the right thing to do. I will provide a patch eventually.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-108) UIInput should not store submitted value in the state
Posted by "Jon Travis (JIRA)" <in...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-108?page=comments#action_61690 ]
Jon Travis commented on MYFACES-108:
------------------------------------
I am having an issue in the current release (1.0.9 ... head?)
Basically text inputs are coming back from POSTs as "" instead
of 'null' (I don't change any values). When the renderutils check
to see if the object is null, it fails (and thus, always renders "" instead
of grabbing the value from the model bean)
> UIInput should not store submitted value in the state
> -----------------------------------------------------
>
> Key: MYFACES-108
> URL: http://issues.apache.org/jira/browse/MYFACES-108
> Project: MyFaces
> Type: Improvement
> Versions: 1.0.7 beta, 1.0.8 beta
> Reporter: sean schofield
> Priority: Trivial
>
> Submitted value really shouldn't be stored in the state. At a minimum it is confusing and results in extra bandwith with client-side state saving. Heath points out that in most cases the value being "stored" will probably be null. That being said, if the code is totally unecessary we ought to consider removing it. I will leave this issue open for a while to make sure nobody has any issues with fixing it. This will affect a lot of components so I want to be sure this is the right thing to do. I will provide a patch eventually.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira