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
