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/05/08 16:44:31 UTC
MyFaces 2.0 PartialResponseWriter + EVALs
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
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Werner Punz <we...@gmail.com>.
Ok before anyone is starting to write one.
I have a script splitting response writer in state
which triggers also on src attributes and
the connected javascripts load the scripts via xhr and do a global eval.
I have not comitted it yet, because I want to compare my code
with Trinidad just to check if I have overlooked something in this area.
I will commit it around next week to be reused in the partial processing
area, so that we have a proper script splitting!
Werner
Werner Punz schrieb:
> Ok I added a dynamically loading loadScript function to our javascript
> _Utils class/function.
> The code basically resolves the script src handling
> aspect by loading the script
> via synchronous xhr and doing a global eval on the script!
>
> This way we dont have dom manipulations just to do the script src part
> on the client side, and to my knowledge the speed drop is neglectable!
> (Most javascript libraries do dynamic loading that way)
>
> The next step is to find out if the RI has added the start and endTag
> functionality the way Trinidad and others do!
> An if yes we have to implement it (I have started on this already) if
> no, I am going to file a bugreport!
>
>
> Werner
>
>
> Werner Punz schrieb:
>> Hia Ganesh, I have to check the latest codebase,
>> the version i have which is a few weeks old, did not have
>> anything integrated...
>>
>> The main problem I see not doing it is, that usually
>> the response writer already is in update stage when the components
>> encode method is called which means
>> every out goes into update so component authors cannot even
>> trigger the eval part properly!
>>
>> If you want to utilize the eval part properly you have to integrate
>> this automatically one way or the other.
>> I will check the latest codebase this week and if they do not have it
>> integrated I will file a bug report for Mojarra, they might probably
>> have overlooked this aspect on the implementors side (definitely not
>> on the spec side hence the eval cycle).
>>
>> I probably would not know it either on the first look,
>> if I hadn´t worked on those aspects
>> of Trinidad within the boundaries of a project where we tried
>> to integrate PPR!
>>
>>
>> Werner
>>
>>
>> Ganesh schrieb:
>>> Hi Werner,
>>>
>>> Actually, I'm not quite sure which of the cases [1] to [4] (see
>>> below) you are referring to. Did you check the behaviour of Mojarra
>>> on this? In which case does it return <eval>? I'd say our
>>> PartialResponseWriter should work along the same basic line. My
>>> personal guess is they return <eval> either in case [1] or [3]. I'll
>>> try and find some time to set up a test on this during the next week.
>>>
>>> Best Regards,
>>> Ganesh
>>>
>>> Werner Punz schrieb:
>>>> I have to evaluate that because generally the insertBefore did not
>>>> trigger on all non IE browsers in the embedded case (Safari for
>>>> instance failed as well, while Opera was working) so I had to embed
>>>> our browser check code...
>>>> Anyway the safe bet probably is to load the script synchronously via
>>>> xhr and eval it manually in that case!
>>>> The unsafe bet is to have the browser doing this automatically.
>>>> Either way is fine with me since both methods are just a few lines
>>>> of code.
>>>> My personal question was more along the lines if there are any
>>>> obstacles
>>>> to add the eval behavior as described to the PartialResponseWriter,
>>>> and how does facelets trigger the response writer in this regard.
>>>>
>>>> (Facelets theorectically allows to use scripts just as plain html
>>>> thus we cannot use the startElement("script" approach in this case
>>>> unless facelets can map single tags into startElement calls)
>>>>
>>>> Werner
>>>>> Hi,
>>>>>
>>>>> There are four kinds of script constructs I can image
>>>>> may becoming pulled in through an ajax request:
>>>>>
>>>>> [1] component does startElement("script", component) ...
>>>>> endElement("script")
>>>>> [2] XHTML markup contains <script
>>>>> type="text/javascript"> ...</script> (or component writes this
>>>>> directly to the stream)
>>>>> [3] markup contains <h:outputSrcipt>
>>>>> [4] markup contains <script src=...>
>>>>>
>>>>> IMHO only [1] qualifies to be included in the <eval>
>>>>> section of
>>>>> the AJAX response by the PartialResponseWriter.
>>>>> Execution on the
>>>>> Javascript side can happen with
>>>>> window.execScript(theActualScriptContent) like Matthias
>>>>> proposed.
>>>>> Matthias, can you explain the advantages of this?
>>>>>
>>>>> [2] should be recognized by our embedded Javascript
>>>>> runScripts
>>>>> function which in fact also does window.execScript.
>>>>> Werner, I
>>>>> think we agree on this. Everything else would cause parsing
>>>>> of the
>>>>> XHTML markup.
>>>>>
>>>>> For [3] Werners document.createElement("script")
>>>>> approach can be
>>>>> suitable though I'm not sure how you want to send this down
>>>>> to the
>>>>> browser. Are you planning to run on the <extension> tag
>>>>> in the
>>>>> ajax XMLSchema?
>>>>>
>>>>> Werner, your example for
>>>>> document.createElement("script") was
>>>>> based on case [4]. But how do you want to do this? Are you
>>>>> planning to parse all the markup for script tags with src
>>>>> attributes? Maybe here an extension to our embedded
>>>>> Javascript
>>>>> runScripts function could make sense? This could also
>>>>> solve [3]!
>>>>>
>>>>> Best regards,
>>>>> Ganesh
>>>
>>
>>
>
>
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Werner Punz <we...@gmail.com>.
Ok I added a dynamically loading loadScript function to our javascript
_Utils class/function.
The code basically resolves the script src handling
aspect by loading the script
via synchronous xhr and doing a global eval on the script!
This way we dont have dom manipulations just to do the script src part
on the client side, and to my knowledge the speed drop is neglectable!
(Most javascript libraries do dynamic loading that way)
The next step is to find out if the RI has added the start and endTag
functionality the way Trinidad and others do!
An if yes we have to implement it (I have started on this already) if
no, I am going to file a bugreport!
Werner
Werner Punz schrieb:
> Hia Ganesh, I have to check the latest codebase,
> the version i have which is a few weeks old, did not have
> anything integrated...
>
> The main problem I see not doing it is, that usually
> the response writer already is in update stage when the components
> encode method is called which means
> every out goes into update so component authors cannot even
> trigger the eval part properly!
>
> If you want to utilize the eval part properly you have to integrate
> this automatically one way or the other.
> I will check the latest codebase this week and if they do not have it
> integrated I will file a bug report for Mojarra, they might probably
> have overlooked this aspect on the implementors side (definitely not on
> the spec side hence the eval cycle).
>
> I probably would not know it either on the first look,
> if I hadn´t worked on those aspects
> of Trinidad within the boundaries of a project where we tried
> to integrate PPR!
>
>
> Werner
>
>
> Ganesh schrieb:
>> Hi Werner,
>>
>> Actually, I'm not quite sure which of the cases [1] to [4] (see below)
>> you are referring to. Did you check the behaviour of Mojarra on this?
>> In which case does it return <eval>? I'd say our PartialResponseWriter
>> should work along the same basic line. My personal guess is they
>> return <eval> either in case [1] or [3]. I'll try and find some time
>> to set up a test on this during the next week.
>>
>> Best Regards,
>> Ganesh
>>
>> Werner Punz schrieb:
>>> I have to evaluate that because generally the insertBefore did not
>>> trigger on all non IE browsers in the embedded case (Safari for
>>> instance failed as well, while Opera was working) so I had to embed
>>> our browser check code...
>>> Anyway the safe bet probably is to load the script synchronously via
>>> xhr and eval it manually in that case!
>>> The unsafe bet is to have the browser doing this automatically.
>>> Either way is fine with me since both methods are just a few lines of
>>> code.
>>> My personal question was more along the lines if there are any obstacles
>>> to add the eval behavior as described to the PartialResponseWriter,
>>> and how does facelets trigger the response writer in this regard.
>>>
>>> (Facelets theorectically allows to use scripts just as plain html
>>> thus we cannot use the startElement("script" approach in this case
>>> unless facelets can map single tags into startElement calls)
>>>
>>> Werner
>>>> Hi,
>>>>
>>>> There are four kinds of script constructs I can image may
>>>> becoming pulled in through an ajax request:
>>>>
>>>> [1] component does startElement("script", component) ...
>>>> endElement("script")
>>>> [2] XHTML markup contains <script type="text/javascript">
>>>> ...</script> (or component writes this directly to the stream)
>>>> [3] markup contains <h:outputSrcipt>
>>>> [4] markup contains <script src=...>
>>>>
>>>> IMHO only [1] qualifies to be included in the <eval>
>>>> section of
>>>> the AJAX response by the PartialResponseWriter. Execution
>>>> on the
>>>> Javascript side can happen with
>>>> window.execScript(theActualScriptContent) like Matthias
>>>> proposed.
>>>> Matthias, can you explain the advantages of this?
>>>>
>>>> [2] should be recognized by our embedded Javascript
>>>> runScripts
>>>> function which in fact also does window.execScript.
>>>> Werner, I
>>>> think we agree on this. Everything else would cause parsing
>>>> of the
>>>> XHTML markup.
>>>>
>>>> For [3] Werners document.createElement("script") approach
>>>> can be
>>>> suitable though I'm not sure how you want to send this down
>>>> to the
>>>> browser. Are you planning to run on the <extension> tag
>>>> in the
>>>> ajax XMLSchema?
>>>>
>>>> Werner, your example for document.createElement("script")
>>>> was
>>>> based on case [4]. But how do you want to do this? Are you
>>>> planning to parse all the markup for script tags with src
>>>> attributes? Maybe here an extension to our embedded
>>>> Javascript
>>>> runScripts function could make sense? This could also
>>>> solve [3]!
>>>>
>>>> Best regards,
>>>> Ganesh
>>
>
>
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Werner Punz <we...@gmail.com>.
Hia Ganesh, I have to check the latest codebase,
the version i have which is a few weeks old, did not have
anything integrated...
The main problem I see not doing it is, that usually
the response writer already is in update stage when the components
encode method is called which means
every out goes into update so component authors cannot even
trigger the eval part properly!
If you want to utilize the eval part properly you have to integrate
this automatically one way or the other.
I will check the latest codebase this week and if they do not have it
integrated I will file a bug report for Mojarra, they might probably
have overlooked this aspect on the implementors side (definitely not on
the spec side hence the eval cycle).
I probably would not know it either on the first look,
if I hadn´t worked on those aspects
of Trinidad within the boundaries of a project where we tried
to integrate PPR!
Werner
Ganesh schrieb:
> Hi Werner,
>
> Actually, I'm not quite sure which of the cases [1] to [4] (see below)
> you are referring to. Did you check the behaviour of Mojarra on this? In
> which case does it return <eval>? I'd say our PartialResponseWriter
> should work along the same basic line. My personal guess is they return
> <eval> either in case [1] or [3]. I'll try and find some time to set up
> a test on this during the next week.
>
> Best Regards,
> Ganesh
>
> Werner Punz schrieb:
>> I have to evaluate that because generally the insertBefore did not
>> trigger on all non IE browsers in the embedded case (Safari for
>> instance failed as well, while Opera was working) so I had to embed
>> our browser check code...
>> Anyway the safe bet probably is to load the script synchronously via
>> xhr and eval it manually in that case!
>> The unsafe bet is to have the browser doing this automatically.
>> Either way is fine with me since both methods are just a few lines of
>> code.
>> My personal question was more along the lines if there are any obstacles
>> to add the eval behavior as described to the PartialResponseWriter,
>> and how does facelets trigger the response writer in this regard.
>>
>> (Facelets theorectically allows to use scripts just as plain html
>> thus we cannot use the startElement("script" approach in this case
>> unless facelets can map single tags into startElement calls)
>>
>> Werner
>>> Hi,
>>>
>>> There are four kinds of script constructs I can image may
>>> becoming pulled in through an ajax request:
>>>
>>> [1] component does startElement("script", component) ...
>>> endElement("script")
>>> [2] XHTML markup contains <script type="text/javascript">
>>> ...</script> (or component writes this directly to the stream)
>>> [3] markup contains <h:outputSrcipt>
>>> [4] markup contains <script src=...>
>>>
>>> IMHO only [1] qualifies to be included in the <eval>
>>> section of
>>> the AJAX response by the PartialResponseWriter. Execution
>>> on the
>>> Javascript side can happen with
>>> window.execScript(theActualScriptContent) like Matthias
>>> proposed.
>>> Matthias, can you explain the advantages of this?
>>>
>>> [2] should be recognized by our embedded Javascript
>>> runScripts
>>> function which in fact also does window.execScript. Werner, I
>>> think we agree on this. Everything else would cause parsing
>>> of the
>>> XHTML markup.
>>>
>>> For [3] Werners document.createElement("script") approach
>>> can be
>>> suitable though I'm not sure how you want to send this down
>>> to the
>>> browser. Are you planning to run on the <extension> tag in
>>> the
>>> ajax XMLSchema?
>>>
>>> Werner, your example for document.createElement("script") was
>>> based on case [4]. But how do you want to do this? Are you
>>> planning to parse all the markup for script tags with src
>>> attributes? Maybe here an extension to our embedded
>>> Javascript
>>> runScripts function could make sense? This could also
>>> solve [3]!
>>>
>>> Best regards,
>>> Ganesh
>
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Ganesh <ga...@j4fry.org>.
Hi Werner,
Actually, I'm not quite sure which of the cases [1] to [4] (see below)
you are referring to. Did you check the behaviour of Mojarra on this? In
which case does it return <eval>? I'd say our PartialResponseWriter
should work along the same basic line. My personal guess is they return
<eval> either in case [1] or [3]. I'll try and find some time to set up
a test on this during the next week.
Best Regards,
Ganesh
Werner Punz schrieb:
> I have to evaluate that because generally the insertBefore did not
> trigger on all non IE browsers in the embedded case (Safari for
> instance failed as well, while Opera was working) so I had to embed
> our browser check code...
> Anyway the safe bet probably is to load the script synchronously via
> xhr and eval it manually in that case!
> The unsafe bet is to have the browser doing this automatically.
> Either way is fine with me since both methods are just a few lines of
> code.
> My personal question was more along the lines if there are any obstacles
> to add the eval behavior as described to the PartialResponseWriter,
> and how does facelets trigger the response writer in this regard.
>
> (Facelets theorectically allows to use scripts just as plain html
> thus we cannot use the startElement("script" approach in this case
> unless facelets can map single tags into startElement calls)
>
> Werner
>> Hi,
>>
>> There are four kinds of script constructs I can image may
>> becoming pulled in through an ajax request:
>>
>> [1] component does startElement("script", component) ...
>> endElement("script")
>> [2] XHTML markup contains <script type="text/javascript">
>> ...</script> (or component writes this directly to the stream)
>> [3] markup contains <h:outputSrcipt>
>> [4] markup contains <script src=...>
>>
>> IMHO only [1] qualifies to be included in the <eval>
>> section of
>> the AJAX response by the PartialResponseWriter. Execution
>> on the
>> Javascript side can happen with
>> window.execScript(theActualScriptContent) like Matthias
>> proposed.
>> Matthias, can you explain the advantages of this?
>>
>> [2] should be recognized by our embedded Javascript
>> runScripts
>> function which in fact also does window.execScript. Werner, I
>> think we agree on this. Everything else would cause parsing
>> of the
>> XHTML markup.
>>
>> For [3] Werners document.createElement("script") approach
>> can be
>> suitable though I'm not sure how you want to send this down
>> to the
>> browser. Are you planning to run on the <extension> tag in
>> the
>> ajax XMLSchema?
>>
>> Werner, your example for document.createElement("script") was
>> based on case [4]. But how do you want to do this? Are you
>> planning to parse all the markup for script tags with src
>> attributes? Maybe here an extension to our embedded
>> Javascript
>> runScripts function could make sense? This could also
>> solve [3]!
>>
>> Best regards,
>> Ganesh
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Werner Punz <we...@gmail.com>.
I have to evaluate that because generally the insertBefore did not
trigger on all non IE browsers in the embedded case (Safari for instance
failed as well, while Opera was working) so I had to embed our browser
check code...
Anyway the safe bet probably is to load the script synchronously via xhr
and eval it manually in that case!
The unsafe bet is to have the browser doing this automatically.
Either way is fine with me since both methods are just a few lines of code.
My personal question was more along the lines if there are any obstacles
to add the eval behavior as described to the PartialResponseWriter, and
how does facelets trigger the response writer in this regard.
(Facelets theorectically allows to use scripts just as plain html
thus we cannot use the startElement("script" approach in this case
unless facelets can map single tags into startElement calls)
Werner
Alexander Bell schrieb:
> Hi,
>
> I've tried the example. It works +1
> So we can use document.createElement("script") for [3] and [4]
>
> regards alex
>
>
> 2009/5/8 Ganesh <ganesh@j4fry.org <ma...@j4fry.org>>
>
> It does work (even cross-browser). Try this:
>
> *<html>
> <body>
> <input type="submit" value="test" id="test">
> <script>//<!--
>
> var scriptTag = document.createElement("script");
> scriptTag.src="test.js";
> var item = document.getElementById('test');
> item.parentNode.insertBefore(scriptTag, item);
> //-->
> </script>
> </body>
> </html>
>
> with test.js having one line:
> alert('test');
>
> It's the DOM action that triggers the script execution.
>
> Best regards,
> Ganesh
> *
> Alexander Bell schrieb:
>
> Hi,
>
> I don't understand the solution for [3].
> I've got for instance the following tag on my page: <script
> type="text/javascript" src="http://my.source.com/myscript.js" />.
> So we have to execute all the script code inside that file. Does
> this work with document.createElement("script")?
> Because this only create a DOM element but I'm not sure that the
> script-code is executed (especially in IE 5-6).
>
> regards alex
>
> 2009/5/8 Ganesh <ganesh@j4fry.org <ma...@j4fry.org>
> <mailto:ganesh@j4fry.org <ma...@j4fry.org>>>
>
>
> Hi,
>
> There are four kinds of script constructs I can image may
> becoming
> pulled in through an ajax request:
>
> [1] component does startElement("script", component) ...
> endElement("script")
> [2] XHTML markup contains <script type="text/javascript"> ...
> </script> (or component writes this directly to the stream)
> [3] markup contains <h:outputSrcipt>
> [4] markup contains <script src=...>
>
> IMHO only [1] qualifies to be included in the <eval> section of
> the AJAX response by the PartialResponseWriter. Execution on the
> Javascript side can happen with
> window.execScript(theActualScriptContent) like Matthias proposed.
> Matthias, can you explain the advantages of this?
>
> [2] should be recognized by our embedded Javascript runScripts
> function which in fact also does window.execScript. Werner, I
> think we agree on this. Everything else would cause parsing
> of the
> XHTML markup.
>
> For [3] Werners document.createElement("script") approach can be
> suitable though I'm not sure how you want to send this down
> to the
> browser. Are you planning to run on the <extension> tag in the
> ajax XMLSchema?
>
> Werner, your example for document.createElement("script") was
> based on case [4]. But how do you want to do this? Are you
> planning to parse all the markup for script tags with src
> attributes? Maybe here an extension to our embedded Javascript
> runScripts function could make sense? This could also solve [3]!
>
> Best regards,
> Ganesh
>
> 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
> <ma...@gmail.com>
> <mailto:werner.punz@gmail.com
> <ma...@gmail.com>>>
> Date: Fri, May 8, 2009 at 4:54 PM
> Subject: Re: MyFaces 2.0 PartialResponseWriter + EVALs
> To: dev@myfaces.apache.org
> <ma...@myfaces.apache.org> <mailto:dev@myfaces.apache.org
> <ma...@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
>
>
>
>
>
>
>
>
> --
> Mit freundlichen Grüßen / Kind regards
> Alexander Bell
>
> J4Fry OpenSource Community
> Internet: http://www.j4fry.org
> E-Mail: Alexander.Bell@j4fry.org
> <ma...@j4fry.org>
> <mailto:Alexander.Bell@j4fry.org <ma...@j4fry.org>>
>
> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>
>
>
>
> --
> Mit freundlichen Grüßen / Kind regards
> Alexander Bell
>
> J4Fry OpenSource Community
> Internet: http://www.j4fry.org
> E-Mail: Alexander.Bell@j4fry.org <ma...@j4fry.org>
> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Alexander Bell <Al...@j4fry.org>.
Hi,
I've tried the example. It works +1
So we can use document.createElement("script") for [3] and [4]
regards alex
2009/5/8 Ganesh <ga...@j4fry.org>
> It does work (even cross-browser). Try this:
>
> *<html>
> <body>
> <input type="submit" value="test" id="test">
> <script>//<!--
> var scriptTag = document.createElement("script");
> scriptTag.src="test.js";
> var item = document.getElementById('test');
> item.parentNode.insertBefore(scriptTag, item);
> //-->
> </script>
> </body>
> </html>
>
> with test.js having one line:
> alert('test');
>
> It's the DOM action that triggers the script execution.
>
> Best regards,
> Ganesh
> *
> Alexander Bell schrieb:
>
>> Hi,
>>
>> I don't understand the solution for [3].
>> I've got for instance the following tag on my page: <script
>> type="text/javascript" src="http://my.source.com/myscript.js" />.
>> So we have to execute all the script code inside that file. Does this work
>> with document.createElement("script")?
>> Because this only create a DOM element but I'm not sure that the
>> script-code is executed (especially in IE 5-6).
>>
>> regards alex
>>
>> 2009/5/8 Ganesh <ganesh@j4fry.org <ma...@j4fry.org>>
>>
>>
>> Hi,
>>
>> There are four kinds of script constructs I can image may becoming
>> pulled in through an ajax request:
>>
>> [1] component does startElement("script", component) ...
>> endElement("script")
>> [2] XHTML markup contains <script type="text/javascript"> ...
>> </script> (or component writes this directly to the stream)
>> [3] markup contains <h:outputSrcipt>
>> [4] markup contains <script src=...>
>>
>> IMHO only [1] qualifies to be included in the <eval> section of
>> the AJAX response by the PartialResponseWriter. Execution on the
>> Javascript side can happen with
>> window.execScript(theActualScriptContent) like Matthias proposed.
>> Matthias, can you explain the advantages of this?
>>
>> [2] should be recognized by our embedded Javascript runScripts
>> function which in fact also does window.execScript. Werner, I
>> think we agree on this. Everything else would cause parsing of the
>> XHTML markup.
>>
>> For [3] Werners document.createElement("script") approach can be
>> suitable though I'm not sure how you want to send this down to the
>> browser. Are you planning to run on the <extension> tag in the
>> ajax XMLSchema?
>>
>> Werner, your example for document.createElement("script") was
>> based on case [4]. But how do you want to do this? Are you
>> planning to parse all the markup for script tags with src
>> attributes? Maybe here an extension to our embedded Javascript
>> runScripts function could make sense? This could also solve [3]!
>>
>> Best regards,
>> Ganesh
>>
>> 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
>> <ma...@gmail.com>>
>> Date: Fri, May 8, 2009 at 4:54 PM
>> Subject: Re: MyFaces 2.0 PartialResponseWriter + EVALs
>> To: dev@myfaces.apache.org <ma...@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
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Mit freundlichen Grüßen / Kind regards
>> Alexander Bell
>>
>> J4Fry OpenSource Community
>> Internet: http://www.j4fry.org
>> E-Mail: Alexander.Bell@j4fry.org <ma...@j4fry.org>
>> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>>
>>
--
Mit freundlichen Grüßen / Kind regards
Alexander Bell
J4Fry OpenSource Community
Internet: http://www.j4fry.org
E-Mail: Alexander.Bell@j4fry.org
Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Ganesh <ga...@j4fry.org>.
It does work (even cross-browser). Try this:
*<html>
<body>
<input type="submit" value="test" id="test">
<script>//<!--
var scriptTag = document.createElement("script");
scriptTag.src="test.js";
var item = document.getElementById('test');
item.parentNode.insertBefore(scriptTag, item);
//-->
</script>
</body>
</html>
with test.js having one line:
alert('test');
It's the DOM action that triggers the script execution.
Best regards,
Ganesh
*
Alexander Bell schrieb:
> Hi,
>
> I don't understand the solution for [3].
> I've got for instance the following tag on my page: <script
> type="text/javascript" src="http://my.source.com/myscript.js" />.
> So we have to execute all the script code inside that file. Does this
> work with document.createElement("script")?
> Because this only create a DOM element but I'm not sure that the
> script-code is executed (especially in IE 5-6).
>
> regards alex
>
> 2009/5/8 Ganesh <ganesh@j4fry.org <ma...@j4fry.org>>
>
> Hi,
>
> There are four kinds of script constructs I can image may becoming
> pulled in through an ajax request:
>
> [1] component does startElement("script", component) ...
> endElement("script")
> [2] XHTML markup contains <script type="text/javascript"> ...
> </script> (or component writes this directly to the stream)
> [3] markup contains <h:outputSrcipt>
> [4] markup contains <script src=...>
>
> IMHO only [1] qualifies to be included in the <eval> section of
> the AJAX response by the PartialResponseWriter. Execution on the
> Javascript side can happen with
> window.execScript(theActualScriptContent) like Matthias proposed.
> Matthias, can you explain the advantages of this?
>
> [2] should be recognized by our embedded Javascript runScripts
> function which in fact also does window.execScript. Werner, I
> think we agree on this. Everything else would cause parsing of the
> XHTML markup.
>
> For [3] Werners document.createElement("script") approach can be
> suitable though I'm not sure how you want to send this down to the
> browser. Are you planning to run on the <extension> tag in the
> ajax XMLSchema?
>
> Werner, your example for document.createElement("script") was
> based on case [4]. But how do you want to do this? Are you
> planning to parse all the markup for script tags with src
> attributes? Maybe here an extension to our embedded Javascript
> runScripts function could make sense? This could also solve [3]!
>
> Best regards,
> Ganesh
>
> 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
> <ma...@gmail.com>>
> Date: Fri, May 8, 2009 at 4:54 PM
> Subject: Re: MyFaces 2.0 PartialResponseWriter + EVALs
> To: dev@myfaces.apache.org <ma...@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
>
>
>
>
>
>
>
>
> --
> Mit freundlichen Grüßen / Kind regards
> Alexander Bell
>
> J4Fry OpenSource Community
> Internet: http://www.j4fry.org
> E-Mail: Alexander.Bell@j4fry.org <ma...@j4fry.org>
> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Alexander Bell <Al...@j4fry.org>.
Hi,
I don't understand the solution for [3].
I've got for instance the following tag on my page: <script
type="text/javascript" src="http://my.source.com/myscript.js" />.
So we have to execute all the script code inside that file. Does this work
with document.createElement("script")?
Because this only create a DOM element but I'm not sure that the script-code
is executed (especially in IE 5-6).
regards alex
2009/5/8 Ganesh <ga...@j4fry.org>
> Hi,
>
> There are four kinds of script constructs I can image may becoming pulled
> in through an ajax request:
>
> [1] component does startElement("script", component) ...
> endElement("script")
> [2] XHTML markup contains <script type="text/javascript"> ... </script> (or
> component writes this directly to the stream)
> [3] markup contains <h:outputSrcipt>
> [4] markup contains <script src=...>
>
> IMHO only [1] qualifies to be included in the <eval> section of the AJAX
> response by the PartialResponseWriter. Execution on the Javascript side can
> happen with window.execScript(theActualScriptContent) like Matthias
> proposed. Matthias, can you explain the advantages of this?
>
> [2] should be recognized by our embedded Javascript runScripts function
> which in fact also does window.execScript. Werner, I think we agree on this.
> Everything else would cause parsing of the XHTML markup.
>
> For [3] Werners document.createElement("script") approach can be suitable
> though I'm not sure how you want to send this down to the browser. Are you
> planning to run on the <extension> tag in the ajax XMLSchema?
>
> Werner, your example for document.createElement("script") was based on case
> [4]. But how do you want to do this? Are you planning to parse all the
> markup for script tags with src attributes? Maybe here an extension to our
> embedded Javascript runScripts function could make sense? This could also
> solve [3]!
>
> Best regards,
> Ganesh
>
> 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 <we...@gmail.com>
>>> Date: Fri, May 8, 2009 at 4:54 PM
>>> Subject: Re: MyFaces 2.0 PartialResponseWriter + EVALs
>>> To: 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
>>>
>>>
>>>
>>>
>>>
>>
--
Mit freundlichen Grüßen / Kind regards
Alexander Bell
J4Fry OpenSource Community
Internet: http://www.j4fry.org
E-Mail: Alexander.Bell@j4fry.org
Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Ganesh <ga...@j4fry.org>.
Hi,
There are four kinds of script constructs I can image may becoming
pulled in through an ajax request:
[1] component does startElement("script", component) ...
endElement("script")
[2] XHTML markup contains <script type="text/javascript"> ... </script>
(or component writes this directly to the stream)
[3] markup contains <h:outputSrcipt>
[4] markup contains <script src=...>
IMHO only [1] qualifies to be included in the <eval> section of the AJAX
response by the PartialResponseWriter. Execution on the Javascript side
can happen with window.execScript(theActualScriptContent) like Matthias
proposed. Matthias, can you explain the advantages of this?
[2] should be recognized by our embedded Javascript runScripts function
which in fact also does window.execScript. Werner, I think we agree on
this. Everything else would cause parsing of the XHTML markup.
For [3] Werners document.createElement("script") approach can be
suitable though I'm not sure how you want to send this down to the
browser. Are you planning to run on the <extension> tag in the ajax
XMLSchema?
Werner, your example for document.createElement("script") was based on
case [4]. But how do you want to do this? Are you planning to parse all
the markup for script tags with src attributes? Maybe here an extension
to our embedded Javascript runScripts function could make sense? This
could also solve [3]!
Best regards,
Ganesh
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 <we...@gmail.com>
>> Date: Fri, May 8, 2009 at 4:54 PM
>> Subject: Re: MyFaces 2.0 PartialResponseWriter + EVALs
>> To: 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
>>
>>
>>
>>
>
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Werner Punz <we...@gmail.com>.
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
> <ma...@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
> <ma...@gmail.com>>
> Date: Fri, May 8, 2009 at 4:54 PM
> Subject: Re: MyFaces 2.0 PartialResponseWriter + EVALs
> To: dev@myfaces.apache.org <ma...@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
>
>
>
>
>
>
>
>
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Cagatay Civici <ca...@gmail.com>.
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 <we...@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 <we...@gmail.com>
>>> Date: Fri, May 8, 2009 at 4:54 PM
>>> Subject: Re: MyFaces 2.0 PartialResponseWriter + EVALs
>>> To: 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Werner Punz <we...@gmail.com>.
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 <we...@gmail.com>
>> Date: Fri, May 8, 2009 at 4:54 PM
>> Subject: Re: MyFaces 2.0 PartialResponseWriter + EVALs
>> To: 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
>>
>>
>>
>>
>
>
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Werner Punz <we...@gmail.com>.
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 <we...@gmail.com>
> Date: Fri, May 8, 2009 at 4:54 PM
> Subject: Re: MyFaces 2.0 PartialResponseWriter + EVALs
> To: 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
>
>
>
>
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Matthias Wessendorf <ma...@apache.org>.
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 <we...@gmail.com>
Date: Fri, May 8, 2009 at 4:54 PM
Subject: Re: MyFaces 2.0 PartialResponseWriter + EVALs
To: 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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Posted by Werner Punz <we...@gmail.com>.
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