Hi
I have attached a patch for myfaces (2.0.x) here:
https://issues.apache.org/jira/browse/MYFACES-3257
Note the algorithm in some point call processSaveState(), to save a
"branch" and then return VisitResult.REJECT. Additionally, UIViewRoot
is saved at last, because some information is saved there that will be
used later to restore the tree. In practice, this could cause a
slightly different behavior between MyFaces and Mojarra, because both
algorithms do the same in a different way.
It could be good to know:
1. If the patch proposed comply with the proposed clarification.
2. If the patch should be applied on 2.0.x or since 2.1.x.
3. The use case that requires this change in detail. At this point, I
don't really know why you need it, but I suppose this is required
because trinidad state saving has some special code here. Without that
information, I can't see if there could be problems with MyFaces state
saving style.
regards,
Leonardo Uribe
2011/8/2 Blake Sullivan <blake.sullivan_at_oracle.com>:
> Ted,
>
> Good point about the state management trying to handle the hardest
> case. I'd actually say that the case it is trying to handle is even
> rarer than that--if we assume javascript is available, we can write the
> state at the end and use javascript to make things right.
>
> -- Blake Sullivan
>
> On 8/2/11 9:18 AM, Ted Goddard wrote:
>> With the standardization of state saving internals, we should also standardize
>> on how the ViewState key is handled -- specifically to simplify it for server-side
>> state saving and Ajax.
>>
>> At the moment, the implementation assumes the more difficult case of client-side
>> state saving even in the server-side case. With client-side saving, the ViewState
>> must be written after rendering is complete, whereas with server-side state saving
>> the key can be generated and written at any time.
>>
>> In the server-side state saving case, it should be possible for getViewState() to
>> be called multiple times, return the same value each time (for a given view) and
>> have no side effects when called (actual state saving would take place using the
>> ViewState key after rendering).
>>
>> This would allow the same ViewState key to easily be written to multiple forms,
>> and would eliminate the buffering complexity of replacing the ViewState key with
>> it's actual value in the response.
>>
>> Regards,
>> Ted.
>>
>>
>>
>> On 2011-08-01, at 9:15 PM, Leonardo Uribe wrote:
>>
>>> Hi
>>>
>>> 2011/8/1 Andy Schwartz<andy.schwartz_at_oracle.com>:
>>>> Gang -
>>>>
>>>> Back in January I called out inconsistencies between how MyFaces and Mojarra
>>>> perform partial state save/restore traversals:
>>>>
>>>> http://lists.jboss.org/pipermail/jsr-314-open-mirror/2011-January/003203.html
>>>>
>>>> Short summary: Mojarra uses tree visiting. MyFaces does not. We should
>>>> standardize/be consistent.
>>>>
>>>> I also questioned whether tree visiting was necessary for this case:
>>>>
>>>>
>>>>> Is tree visiting even the right tool for the job?
>>>>>
>>>>> Should we perhaps avoid this complexity altogether by sticking with a
>>>>> facets + children traversal (eg. as currently implemented by MyFaces)
>>>>> for partial state saving/restoring?
>>>>>
>>>>> Or are there cases where component implementations do in fact need
>>>>> control over the way that this traversal is performed, in which case an
>>>>> internal iteration solution (like tree visiting) is necessary?
>>>>
>>>> Since then, I have found two cases in Trinidad where we want to hook into
>>>> the partial state saving traversal: both UIXComponentBase and UIXCollection
>>>> override processSaveState() to add some Trinidad-specific processing.
>>>>
>>>> I am now thinking that the tree visit approach is the right way to go, as
>>>> this gives components that currently override
>>>> processSaveState/processRestoreState a place to hook into the partial state
>>>> save/restore traversals. Mojarra already does this, so we're talking a
>>>> (small) spec change + MyFaces implementation change.
>>>>
>>>> Does this sound reasonable?
>>> Yes. I can do the necessary changes on MyFaces side. Until this moment
>>> there was no reason why change the code (see previous discussion), but
>>> if there is some use cases where do this is useful, it is no problem.
>>> After all we already have SKIP_ITERATION hint and
>>> javax.faces.IS_SAVING_STATE (In 2.1.x branch).
>>>
>>> I think we should implement javax.faces.IS_SAVING_STATE FacesContext
>>> attribute in 2.0.x to make it work correctly, is it correct?
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>> Andy
>>>>
>>>>
>>
>
>