Actually the main thing is, that the JSF2 spec already has an eval
section in the PPR response, I am not sure how the EG has planned to
utilize that part,
my assumption is that they also will add a special response writer part
which tries to isolate the scripting parts if used properly, after all
there already is a PPR response writer specified, but I might be wrong.
I have not checked the latest mojarra sources in this regard.
I dont think they plan to offload that task to the component authors
which then have to check if they are in a ppr cycle and deal with
this themselves, it probably is not even possible since, a response
javax.faces.ViewState simply calls encodeAll on the entire component
tree while being in an update stage on the response writer, with an
update defined, so a component cannot really open an eval call while
being already in update, unless the response writer deals with it by
deferring it!
As for breaking things, definitely not, since the javascripts are just
shifted away from the innerHTML to the eval stage of the ppr processing
(hence the dom gets cleanly updated before the scripts are triggered,
which is the cleaner way to do things in javascript anyway), however I
am not sure if
the Facelets which are now an integral part of the JSF API utilize the
start and end tag mechanisms of the response writer or if they simply
write everything out! In the second case the mechanism wont be triggered!
I have to admit I have yet to look into the JSF2 facelet code so I
thought it might be quicker to ask around here than digging into the
semantics of the facelet parser.
Werner
Cagatay Civici schrieb:
The general way to handle scripts in incoming response is to evaluate
them in client side for sure, many js libs do this for example.
But I was also thinking about a cleaner way to do this and make sure
scripts are transported seperately from the html itself. This will lead
to a cleaner js for sure and better performance on client side.
So I'm +1 on Werner's idea, hope it doesn't cause any compatibility
issues comparing to the common way of sending and handling js.
On Fri, May 8, 2009 at 5:01 PM, Werner Punz <werner.p...@gmail.com
<mailto:werner.p...@gmail.com>> wrote:
Anyway XHR also is fine with me if it works out, my plan is to
isolate that part within a utils method in our Javascripts anway,
so that we fetch it my question was more along the lines of
has anybody already started non committed work in this area
and is there any objections to add this functionality to
the PartialResponseWriter in our own ResponseWriterImpl?
Werner
Werner Punz schrieb:
Yes but then I have to fetch the script via xhr...
which means more code on the javascript side of things!
Werner
Matthias Wessendorf schrieb:
isn't it better to do this in IE:
window.execScript(theActualScriptContent);
and in FF and other this:
window.eval(theActualScriptContent);
-Matthias
---------- Forwarded message ----------
From: Werner Punz <werner.p...@gmail.com
<mailto:werner.p...@gmail.com>>
Date: Fri, May 8, 2009 at 4:54 PM
Subject: Re: MyFaces 2.0 PartialResponseWriter + EVALs
To: dev@myfaces.apache.org <mailto:dev@myfaces.apache.org>
Werner Punz schrieb:
Hello everyone:
I checked what has been done on the Partial Response
Writer for the Rendering. It is very basic, so I would
propose following enhancement.
Since we need separate eval blocks for javascripts, we
implement a PartialResponseWriterImpl which fetches the
scripts
from components and later allows those scripts to be
pushed into the eval part of the partial response.
There is a reason for that.
Although we have embedded javascript parsing in our
javascripts I would see that as optional feature for
badly behaving component sets.
The normal way for a component writer still is:
a) startElement("tagName", component)
b) writeAttribute...
write
c) endElement
The way Trinidad and others did it was simply to check
for scripts at startElement and push them into a
separate eval datastructure later to be processed (in
our case after the update part of the p
PartialResponse a separate eval stage has to be added)
I would start to work on this issue if it is ok with
anyone...
The entire functionality should be put into our
PartialResponseWriterImpl not into the API, and will be
hooked into
processPartial of PartialViewContextImpl
I am not sure how to deal with script src="..." on the
protocol and javascript level.
Werner
Ok here is my idea regarding sript src="....
I would transform that on the server side to a small
javascript ala
var scriptTag = document.createElement("script");
scriptTag.src="<src>"; document.body.append(scriptTag);
since the eval is executed after the rendering is done, this
should be
even safe on IE6!
That also would still mean that the update CDATA block is just
javascript only without any preprocessing which then can be
pushed
straight into the eval function!
Werner
