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