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