Improving this would make incrementally flushing content to the client
pretty easy. I would really like to see this supported.
-Ken
On 08/02/2011 02:22 PM, Blake Sullivan wrote:
> 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
>>>>
>>>>