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
