Hello everyone
There are some corner cases which are not covered by our current
implementation of the ppr response writer. (And neither by the RI as the
comments from Salem seem to show)
I will give an example
PPR Response
It usually starts with
startUpate on the ppr response writer
then the control tree is walked down and the controls are redrawn
and an endUpdate is offered
So what happens now is following
someone issues a startElement(script)
which means the script is embedded into the update code
while a separate eval cycle which would be possible is omitted!
We already have this covered in our javascript code by parsing the
scripts, but I want to make a switch to have this turned off if
performance is an issue. Nevertheless Javascript code should not be
pushed into the html part of the ppr response anyway.
So here is my proposal and I am working on it already.
Scan for script startElement tags and postpone the rendering of those
until the endUpdate or endInsert is issued!
Scan for script src and add some dynamic loading code to it (already
finished in the javascripts)
and postpone it as well!
eval within an active update or insert also causes the same delay behavior!
if non update or insert is issued before then simply render script src
as eval!
The advantage of all this is we can cover corner cases which can occur
while not breaking downward compatibility. As far as I have understood
the reported RI behavior, the component writers should be self aware of
being in a PPR cycle but I am not sure how to render scripts from the
component side without this behavior, I doubt this will work out without
the added delaying behavior and pushing the scripts into the eval stage!
In our solution (which does the same as Trinidad mostly, btw, but in the
jsf2 specific context) you dont have to care at all!
I have coded the needed ResponseWriterImpl extension class, but I am not
finished with debugging, but I assume we should add the delaying
behavior to cover those cases correctly!
