Hi!
I'm talking about both cases.
Ah, ok , I see.
Is it necessary to support this kind of thing by backing beans in *rendering*
phase? (obviously, it is quite reasonable in invokeApplication etc). I think
not. In this case, state writing would become a whole lot simpler.
It is possible so I think it needs to be supported, though, i slowly
move to the side which states that this should not be the common style.
In what situation *does* this need to be supported?
Shouldn't a facelets dynamic-include tag instead modify the tree during
the buildView, rather than the encodeAll? That then solves the problem;
the tree then is not modified during encodeAll so state can be computed
at the start.
The orchestra dynaForm should do the same, I think
dynaForm is already modified to modify the tree during build tree. I
think it might be possible to change the dynamic-include too.
Still we should support the "modify-tree-on-render-response" use case,
but we might be able to make this configureable. something like
org.apache.myfaces.SAVE_STATE_BEFORE_ENCODE=true|false where for
backward compatibility we use "false" as default. Yep ... should
definitely be possible. Cool then ... :-)
Ciao,
Mario
