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
>>
>>