myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jakob Korherr (JIRA)" <>
Subject [jira] Commented: (MYFACES-2645) The view state is saved before encodeAll() is called on every UIViewParameter in an AJAX request
Date Thu, 08 Apr 2010 13:16:40 GMT


Jakob Korherr commented on MYFACES-2645:

Hi Leo,

To your examples: I tested it with render="@all" and also with execute="@all", but it didn't
work. And if you understand the background, you will know why it can't work that way.

To your question: Basically yes, but in the case of UIViewParameter it aims to store the value
in the state. You see, UIViewParameter takes the value of a URL parameter as input, but this
value is only available for the first (GET) request. Every following postback won't include
the value as a request parameter. Thus we need some way to keep the value from the first request
in the state and the spec tells us to use the submittedValue here. Using the submittedValue
to store the original value in the state has one advantage and one disadvantage. The advantage
is that in the following request we just have to ignore a null-value (don't invoke setSubmittedValue(null))
in decode() and we will get our old submittedValue from the state. The disadvantage, however,
is that we have to set the submittedValue before the state is generated, because after the
conversions and validations have happend, the submittedValue is set to null by the JSF-lifecycle.
To accomplish this, the spec tells us to invoke setSubmittedValue(getStringValue(...)) in
UIViewParameter.encodeAll() and furthermore to invoke encodeAll() on every UIViewParameter
in the view in UIViewRoot.encodeEnd(), which works perfectly for normal requests. For AJAX-requests,
however, the state is generated before UIViewRoot.encodeEnd() is invoked and so the changes
of the submittedValue of every UIViewParameter are lost. Thus I applied the code from UIViewRoot.encodeEnd()
to PartialViewContextImpl.processPartialRendering() before the state of an AJAX-request is
generated to have the changes of the submittedValue available in the AJAX-state.

So you see my committed code is absolutely correct and should not be reverted. I guess it
was just not thought about the correct handling of UIViewParameters in AJAX-requests when
this part of the spec and the javadoc were written.

However I wrote an email to jsr-314-open about this, because I think there is a better way
to solve the problem (see the patch), but we can't apply this code now, because it breaks
the spec.

> The view state is saved before encodeAll() is called on every UIViewParameter in an AJAX
> ------------------------------------------------------------------------------------------------
>                 Key: MYFACES-2645
>                 URL:
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-314
>    Affects Versions: 2.0.0-beta-3
>            Reporter: Jakob Korherr
>            Assignee: Jakob Korherr
>         Attachments: MYFACES-2645-spec-proposal.patch
> UIViewParameter calls setSubmittedValue() in encodeAll() to store the current value of
the view parameter in the state as the submitted value (this helps UIViewParameter to restore
its value on a postback). UIViewParameter.encodeAll() itself is called by UIViewRoot.encodeEnd()
for every UIViewParameter in the view.
> If the current request is an ajax-request, the view state is currently already generated
in UIViewRoot.encodeChildren() (before UIViewRoot.encodeEnd()). At this time the submitted
value for every UIViewParameter is null, because its encodeAll()-method was not called yet.
> Later, when UIViewRoot.encodeEnd() is called, UIViewParameter.encodeAll() is called and
it sets the submitted value correctly, but due to the fact that the state has already been
generated, these changes are dropped.
> This causes the value of every UIViewParameter to be set to null in the next request,
which will most likely end in validation problems with the required validator.
> The related thread to this issue from the mailing list can be found at:

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message