myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <werner.p...@gmail.com>
Subject Re: MyFaces 2.0 PartialResponseWriter + EVALs
Date Mon, 11 May 2009 07:46:26 GMT
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.punz@gmail.com 
> <mailto:werner.punz@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.punz@gmail.com
>             <mailto:werner.punz@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
> 
> 
> 
> 
> 
> 
> 
> 


Mime
View raw message