You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Werner Punz <we...@gmail.com> on 2009/06/06 10:38:17 UTC
Myfaces 2.0 PPR ResponseWriter impl
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!
Re: Myfaces 2.0 PPR ResponseWriter impl
Posted by Werner Punz <we...@gmail.com>.
Ok I have sent a mail regarding all this to the jcr-314 comments list, I
hope this will trigger a discussion. Regarding our implementation, lets
leave it client side and improve a little bit upon it (which means add
script src= handling on the client, the javascript dynamic loading code
is already in place)! I think
Ganesh is right that a server side treatment would be faster but it
opens a can of worms which might break compatibility and causes too many
headaches!
We always can introduce server side script handling later on once we
know we have to do it, one way or the other (for any reason)
Werner
Werner Punz schrieb:
> Ok my personal guess is to move this discussion to the comments list for
> the jsf spec, I have not really found anything describing the correct
> behavior!
>
>
> Werner
>
>
>
> Werner Punz schrieb:
>> Pro elements, it is faster because you can ommit client side parsing!
>> Mojarra probably does nothing currently in this regard!
>> I am not sure how they are going to handle the embedded scripts case
>> within a ppr request, because with the standard apis you cannot directly
>> open an eval from a component!
>>
>> But I will leave the extension for now, and leave it to the client!
>> But we need to extend the client script parser to script src=
>> constructs, we do not cover that yet, we have the functionality in
>> place to load scripts dynamically but the parser is not fully there
>> yet as far as I have seen!
>>
>> However there is one thing we have to implement on the server side, if
>> an insert or update part is opened on the ppr response writer, and
>> someone issues an eval also, what do we do, I have to recheck the spec
>> if something is specified, but I think there was nothing!
>>
>> Either we can delay the eval until the insert or update is terminated
>> (what I would prefer, or we have to throw an exception!)
>>
>>
>> Anyway I personally think this entire area needs more refinement in
>> jsf 2.1!
>>
>>
>> Werner
>>
>>
>> Ganesh schrieb:
>>> Hi,
>>>
>>> Let me summarize the arguments against pushing scripts to the eval
>>> section:
>>>
>>> 1. scripts inside <!-- comments would suddenly become executed if
>>> facelets.SKIP_COMMENTS is false (which is the Facelets default)
>>> 2. omitting scripts within the markup may damage the layout
>>> 3. script order gets messed up if scripts rendered via startElement
>>> always come last
>>> 4. mojarra doesn't do it
>>>
>>> No pro arguments in sight, I guess ...
>>>
>>> Best regards,
>>> Ganesh
>>>
>>>
>>> Werner Punz schrieb:
>>>> Ganesh schrieb:
>>>>
>>>>>> Well the corner case is this...
>>>>>> If you are outside of an insert or update cycle the problem is
>>>>>> following: What do you do with a simple issued script tag, you
>>>>>> have to open an <eval> section in this case
>>>>> What do you want to express with >>outside of an insert or update
>>>>> cycle<< ?
>>>>>>
>>>> Following usecase:
>>>> Someone writes the ppr response directly instead of going through
>>>> the framework.
>>>> What do you do in case of startElement("script" then
>>>> do you write it out or do you push it into an automated eval section!
>>>>
>>>> My personal guess is, after a second thought, you dont do anything
>>>> special, you just should interfere with delayed evals in case an
>>>> insert or update is issued and not finished, but I am not 100% sure!
>>>>
>>>>
>>>
>>
>>
>
>
Re: Myfaces 2.0 PPR ResponseWriter impl
Posted by Werner Punz <we...@gmail.com>.
Ok my personal guess is to move this discussion to the comments list for
the jsf spec, I have not really found anything describing the correct
behavior!
Werner
Werner Punz schrieb:
> Pro elements, it is faster because you can ommit client side parsing!
> Mojarra probably does nothing currently in this regard!
> I am not sure how they are going to handle the embedded scripts case
> within a ppr request, because with the standard apis you cannot directly
> open an eval from a component!
>
> But I will leave the extension for now, and leave it to the client!
> But we need to extend the client script parser to script src=
> constructs, we do not cover that yet, we have the functionality in place
> to load scripts dynamically but the parser is not fully there yet as far
> as I have seen!
>
> However there is one thing we have to implement on the server side, if
> an insert or update part is opened on the ppr response writer, and
> someone issues an eval also, what do we do, I have to recheck the spec
> if something is specified, but I think there was nothing!
>
> Either we can delay the eval until the insert or update is terminated
> (what I would prefer, or we have to throw an exception!)
>
>
> Anyway I personally think this entire area needs more refinement in jsf
> 2.1!
>
>
> Werner
>
>
> Ganesh schrieb:
>> Hi,
>>
>> Let me summarize the arguments against pushing scripts to the eval
>> section:
>>
>> 1. scripts inside <!-- comments would suddenly become executed if
>> facelets.SKIP_COMMENTS is false (which is the Facelets default)
>> 2. omitting scripts within the markup may damage the layout
>> 3. script order gets messed up if scripts rendered via startElement
>> always come last
>> 4. mojarra doesn't do it
>>
>> No pro arguments in sight, I guess ...
>>
>> Best regards,
>> Ganesh
>>
>>
>> Werner Punz schrieb:
>>> Ganesh schrieb:
>>>
>>>>> Well the corner case is this...
>>>>> If you are outside of an insert or update cycle the problem is
>>>>> following: What do you do with a simple issued script tag, you have
>>>>> to open an <eval> section in this case
>>>> What do you want to express with >>outside of an insert or update
>>>> cycle<< ?
>>>>>
>>> Following usecase:
>>> Someone writes the ppr response directly instead of going through the
>>> framework.
>>> What do you do in case of startElement("script" then
>>> do you write it out or do you push it into an automated eval section!
>>>
>>> My personal guess is, after a second thought, you dont do anything
>>> special, you just should interfere with delayed evals in case an
>>> insert or update is issued and not finished, but I am not 100% sure!
>>>
>>>
>>
>
>
Re: Myfaces 2.0 PPR ResponseWriter impl
Posted by Werner Punz <we...@gmail.com>.
Pro elements, it is faster because you can ommit client side parsing!
Mojarra probably does nothing currently in this regard!
I am not sure how they are going to handle the embedded scripts case
within a ppr request, because with the standard apis you cannot directly
open an eval from a component!
But I will leave the extension for now, and leave it to the client!
But we need to extend the client script parser to script src=
constructs, we do not cover that yet, we have the functionality in place
to load scripts dynamically but the parser is not fully there yet as far
as I have seen!
However there is one thing we have to implement on the server side, if
an insert or update part is opened on the ppr response writer, and
someone issues an eval also, what do we do, I have to recheck the spec
if something is specified, but I think there was nothing!
Either we can delay the eval until the insert or update is terminated
(what I would prefer, or we have to throw an exception!)
Anyway I personally think this entire area needs more refinement in jsf 2.1!
Werner
Ganesh schrieb:
> Hi,
>
> Let me summarize the arguments against pushing scripts to the eval section:
>
> 1. scripts inside <!-- comments would suddenly become executed if
> facelets.SKIP_COMMENTS is false (which is the Facelets default)
> 2. omitting scripts within the markup may damage the layout
> 3. script order gets messed up if scripts rendered via startElement
> always come last
> 4. mojarra doesn't do it
>
> No pro arguments in sight, I guess ...
>
> Best regards,
> Ganesh
>
>
> Werner Punz schrieb:
>> Ganesh schrieb:
>>
>>>> Well the corner case is this...
>>>> If you are outside of an insert or update cycle the problem is
>>>> following: What do you do with a simple issued script tag, you have
>>>> to open an <eval> section in this case
>>> What do you want to express with >>outside of an insert or update
>>> cycle<< ?
>>>>
>> Following usecase:
>> Someone writes the ppr response directly instead of going through the
>> framework.
>> What do you do in case of startElement("script" then
>> do you write it out or do you push it into an automated eval section!
>>
>> My personal guess is, after a second thought, you dont do anything
>> special, you just should interfere with delayed evals in case an
>> insert or update is issued and not finished, but I am not 100% sure!
>>
>>
>
Re: Myfaces 2.0 PPR ResponseWriter impl
Posted by Ganesh <ga...@j4fry.org>.
Hi,
Let me summarize the arguments against pushing scripts to the eval section:
1. scripts inside <!-- comments would suddenly become executed if
facelets.SKIP_COMMENTS is false (which is the Facelets default)
2. omitting scripts within the markup may damage the layout
3. script order gets messed up if scripts rendered via startElement
always come last
4. mojarra doesn't do it
No pro arguments in sight, I guess ...
Best regards,
Ganesh
Werner Punz schrieb:
> Ganesh schrieb:
>
>>> Well the corner case is this...
>>> If you are outside of an insert or update cycle the problem is
>>> following: What do you do with a simple issued script tag, you have
>>> to open an <eval> section in this case
>> What do you want to express with >>outside of an insert or update
>> cycle<< ?
>>>
> Following usecase:
> Someone writes the ppr response directly instead of going through the
> framework.
> What do you do in case of startElement("script" then
> do you write it out or do you push it into an automated eval section!
>
> My personal guess is, after a second thought, you dont do anything
> special, you just should interfere with delayed evals in case an
> insert or update is issued and not finished, but I am not 100% sure!
>
>
Re: Myfaces 2.0 PPR ResponseWriter impl
Posted by Werner Punz <we...@gmail.com>.
Ganesh schrieb:
>> Well the corner case is this...
>> If you are outside of an insert or update cycle the problem is
>> following: What do you do with a simple issued script tag, you have to
>> open an <eval> section in this case
> What do you want to express with >>outside of an insert or update cycle<< ?
>>
Following usecase:
Someone writes the ppr response directly instead of going through the
framework.
What do you do in case of startElement("script" then
do you write it out or do you push it into an automated eval section!
My personal guess is, after a second thought, you dont do anything
special, you just should interfere with delayed evals in case an insert
or update is issued and not finished, but I am not 100% sure!
Re: Myfaces 2.0 PPR ResponseWriter impl
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
Not sure if this adds any value to this discussion, but
> > The only question is how facelets handles this case, but I assume
> > faclets simply skips comments and passes it through with out.write!
> I'm talking about <!-- on the page level, not on the component level.
> Facelets will treat <!-- as markup. Tags nested inside will still be
> evaluated. With the writeElement/writeAttribute solution this could end
> up in script being evaluated though nested inside <!-- -->.
You can configure this using "facelets.SKIP_COMMENTS=true" (what we did). Comments are comments then (and skipped)
Hopefully mojarra will provide a setting for this too, and, even better, have true as default.
Ciao,
Mario
Re: Myfaces 2.0 PPR ResponseWriter impl
Posted by Ganesh <ga...@j4fry.org>.
Hi,
>> -1 for script scanning on the server side. You will get into serious
>> troubles with this.
>>
> uff I think you got me wrong here....
> what I propose to do is following
> writer.startElement("script"
> writer.writeAttribute("src","bla.js"
>
> should expand into
>
> <eval><![CDATA[
> var script = myfaces.utils.loadScript("bla.js");
> eval(script);
> ]]>
> </eval>
Yes, you are right, I got you wrong. You were saying >>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<< so I thought you wanted to
preprocess all scripts on the server side. If it's only for
writeElement/writeAttribute arguments are fewer.
>
>> 1. You don't know whether the HTML part contains <!-- (or some other
>> kind of comment) before the tag that includes the startElement or the
>> script src.
> that is a corner case we cannot really cover on writer level, the
> component author has to take care of it!)
> The normal case on the component side simply is <!-- means that you
> dont write it out at all but leave it out.
> I am not talking about page designer level here, but about
> component writer level.
> The only question is how facelets handles this case, but I assume
> faclets simply skips comments and passes it through with out.write!
I'm talking about <!-- on the page level, not on the component level.
Facelets will treat <!-- as markup. Tags nested inside will still be
evaluated. With the writeElement/writeAttribute solution this could end
up in script being evaluated though nested inside <!-- -->.
>
>> 2. This does cost performance in the server and all the corner cases
>> can be handled on the Javascript side (and already are, as you
>> mentioned in the beginning)
>
> Actually the funny thing is this does not cost any performance at all
> since it is done mostly with linear runtime complexity on the codeside
> (the evals are concatenated into a stringbuilder and after the end of
> the insert or update issued as eval section), embedded script
> parsing has a serious impact on the client side for some browsers (IE
> I am talking about you), which is the reason why I want to cover this
> on the server side if possible!
>
Ok, I understand, there is no scanning, just another condition inside
writeElement/writeAttribute.
>
>> 3. By default browsers should do an auto eval when xhr replaces
>> scripts. IE doesn't, but this can be handled on the Javascript side.
>> We shouldn't fix IE bugs in the ResponseWriterImpl. Doing it on the
>> Javascript side only costs performance for browsers that don't
>> support auto eval, the "good guys" will have a performance benefit.
>> 4. RI doesn't do this kind of stuff. It may even break TCK
>> compatibility.
>>
> If it does we have to investigate why and to the worse simply turn it
> off, since it is just an extension class to our existing Impl class
> this is a non issue, but since it does not alter the standard behavior
> I rather doubt it!
>
You still modify the markup, this may even alter the page design.
>
> Well the corner case is this...
> If you are outside of an insert or update cycle the problem is
> following: What do you do with a simple issued script tag, you have to
> open an <eval> section in this case
What do you want to express with >>outside of an insert or update cycle<< ?
>
> I am not sure what to do with simple issued html elements in this case!
> I have to test that but I assume the RI either throws an exception or
> renders buggy output in this case!
> (This case can happen only if you try to render the ppr cycle from
> begin to end yourself, otherwise, some parts of the framework have to
> issue the update automatically)
Still unclear to me what you are referring to here.
Best regards,
Ganesh
Re: Myfaces 2.0 PPR ResponseWriter impl
Posted by Werner Punz <we...@gmail.com>.
Werner Punz schrieb:
> Dont get me wrong, but I have yet to see component code where the author
> is issuing a <!-- instead of just setting an if which does not render
> anything!
>
>
Ok even that we can cover, but the question is is the coverage of this
corner case needed?
As I said I have yet to see code which does this :-)
Werner
Re: Myfaces 2.0 PPR ResponseWriter impl
Posted by Werner Punz <we...@gmail.com>.
Ganesh schrieb:
> Hi,
>>
>> 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!
> -1 for script scanning on the server side. You will get into serious
> troubles with this.
>
uff I think you got me wrong here....
what I propose to do is following
writer.startElement("script"
writer.writeAttribute("src","bla.js"
should expand into
<eval><![CDATA[
var script = myfaces.utils.loadScript("bla.js");
eval(script);
]]>
</eval>
nothing fancy with script scanning!
I formulated it the wrong way basically!
> 1. You don't know whether the HTML part contains <!-- (or some other
> kind of comment) before the tag that includes the startElement or the
> script src.
that is a corner case we cannot really cover on writer level, the
component author has to take care of it!)
The normal case on the component side simply is <!-- means that you dont
write it out at all but leave it out.
I am not talking about page designer level here, but about
component writer level.
The only question is how facelets handles this case, but I assume
faclets simply skips comments and passes it through with out.write!
Dont get me wrong, but I have yet to see component code where the author
is issuing a <!-- instead of just setting an if which does not render
anything!
> 2. This does cost performance in the server and all the corner cases can
> be handled on the Javascript side (and already are, as you mentioned in
> the beginning)
Actually the funny thing is this does not cost any performance at all
since it is done mostly with linear runtime complexity on the codeside
(the evals are concatenated into a stringbuilder and after the end of
the insert or update issued as eval section), embedded script
parsing has a serious impact on the client side for some browsers (IE I
am talking about you), which is the reason why I want to cover this on
the server side if possible!
> 3. By default browsers should do an auto eval when xhr replaces scripts.
> IE doesn't, but this can be handled on the Javascript side. We shouldn't
> fix IE bugs in the ResponseWriterImpl. Doing it on the Javascript side
> only costs performance for browsers that don't support auto eval, the
> "good guys" will have a performance benefit.
> 4. RI doesn't do this kind of stuff. It may even break TCK compatibility.
>>
If it does we have to investigate why and to the worse simply turn it
off, since it is just an extension class to our existing Impl class this
is a non issue, but since it does not alter the standard behavior I
rather doubt it!
>> 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!
Well the corner case is this...
If you are outside of an insert or update cycle the problem is
following: What do you do with a simple issued script tag, you have to
open an <eval> section in this case
I am not sure what to do with simple issued html elements in this case!
I have to test that but I assume the RI either throws an exception or
renders buggy output in this case!
(This case can happen only if you try to render the ppr cycle from begin
to end yourself, otherwise, some parts of the framework have to issue
the update automatically)
Werner
Re: Myfaces 2.0 PPR ResponseWriter impl
Posted by Ganesh <ga...@j4fry.org>.
Hi,
>
> 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!
-1 for script scanning on the server side. You will get into serious
troubles with this.
1. You don't know whether the HTML part contains <!-- (or some other
kind of comment) before the tag that includes the startElement or the
script src.
2. This does cost performance in the server and all the corner cases can
be handled on the Javascript side (and already are, as you mentioned in
the beginning)
3. By default browsers should do an auto eval when xhr replaces scripts.
IE doesn't, but this can be handled on the Javascript side. We shouldn't
fix IE bugs in the ResponseWriterImpl. Doing it on the Javascript side
only costs performance for browsers that don't support auto eval, the
"good guys" will have a performance benefit.
4. RI doesn't do this kind of stuff. It may even break TCK compatibility.
>
> 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!
I don't understand the meaning of these two sentences.
Though I'm not a qualified voter I'm probably the one besides Werner who
is closest to the MyFaces AJAX code, so I thought I might have a vote on
this.
Best regards,
Ganesh