Hi Simon,
I cannot get this patch to apply cleanly unfortunately. And it's
difficult to review the patch file directly as it has a lot of
whtespace-only changes.
Sorry for that, I'll see if I can clean it up before committing, not
sure about it.
There are now two phases to rendering for JSP: buildView then encodeAll.
As long as no component changes the tree during the encodeAll pass then
it seems to me that it is possible to just compute the serialized view
state at the start of the encodeAll phase [1] and write it out directly
when it is needed.
Do you talk about client-side-state-saving?
This patch is just about server-side-state-saving and with this, during
the encodeAll pase just an "ID" gets rendered, no state should have been
built until then.
The state is build after encodeAll (at least with Facelets, will work
with JSP too but I think there is a bug I realized when there was no
time to fix it).
This means, even a modified tree structure will be correctly saved.
There might be a couple of flaws in my reasoning though: can backing bean code
invoked during render alter the tree state (eg insert data into the attributes
map of a component).
Yep, is still possible, not sure how many people will use stuff like
this. But we do - includeFacelets - you know :-)
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.
Ciao,
Mario
