Hi,
>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.
+1 !!
Regards,
Jakob
2011/8/3 Leonardo Uribe <lu4242_at_gmail.com>:
> 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
>>>>>
>>>>>
>>>
>>
>>
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at