Ganesh schrieb:
Hi,
So here is my proposal and I am working on it already.
Scan for script startElement tags and postpone the rendering of those
until the endUpdate or endInsert is issued!
Scan for script src and add some dynamic loading code to it (already
finished in the javascripts)
and postpone it as well!
-1 for script scanning on the server side. You will get into serious
troubles with this.
uff I think you got me wrong here....
what I propose to do is following
writer.startElement("script"
writer.writeAttribute("src","bla.js"
should expand into
<eval><![CDATA[
var script = myfaces.utils.loadScript("bla.js");
eval(script);
]]>
</eval>
nothing fancy with script scanning!
I formulated it the wrong way basically!
1. You don't know whether the HTML part contains <!-- (or some other
kind of comment) before the tag that includes the startElement or the
script src.
that is a corner case we cannot really cover on writer level, the
component author has to take care of it!)
The normal case on the component side simply is <!-- means that you dont
write it out at all but leave it out.
I am not talking about page designer level here, but about
component writer level.
The only question is how facelets handles this case, but I assume
faclets simply skips comments and passes it through with out.write!
Dont get me wrong, but I have yet to see component code where the author
is issuing a <!-- instead of just setting an if which does not render
anything!
2. This does cost performance in the server and all the corner cases can
be handled on the Javascript side (and already are, as you mentioned in
the beginning)
Actually the funny thing is this does not cost any performance at all
since it is done mostly with linear runtime complexity on the codeside
(the evals are concatenated into a stringbuilder and after the end of
the insert or update issued as eval section), embedded script
parsing has a serious impact on the client side for some browsers (IE I
am talking about you), which is the reason why I want to cover this on
the server side if possible!
3. By default browsers should do an auto eval when xhr replaces scripts.
IE doesn't, but this can be handled on the Javascript side. We shouldn't
fix IE bugs in the ResponseWriterImpl. Doing it on the Javascript side
only costs performance for browsers that don't support auto eval, the
"good guys" will have a performance benefit.
4. RI doesn't do this kind of stuff. It may even break TCK compatibility.
If it does we have to investigate why and to the worse simply turn it
off, since it is just an extension class to our existing Impl class this
is a non issue, but since it does not alter the standard behavior I
rather doubt it!
eval within an active update or insert also causes the same delay
behavior!
if non update or insert is issued before then simply render script src
as eval!
Well the corner case is this...
If you are outside of an insert or update cycle the problem is
following: What do you do with a simple issued script tag, you have to
open an <eval> section in this case
I am not sure what to do with simple issued html elements in this case!
I have to test that but I assume the RI either throws an exception or
renders buggy output in this case!
(This case can happen only if you try to render the ppr cycle from begin
to end yourself, otherwise, some parts of the framework have to issue
the update automatically)
Werner
