[
https://issues.apache.org/jira/browse/MYFACES-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854926#action_12854926
]
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 request
> ------------------------------------------------------------------------------------------------
>
> Key: MYFACES-2645
> URL: https://issues.apache.org/jira/browse/MYFACES-2645
> 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:
> http://www.junlu.com/list/43/611590.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
