Hi,
-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>
Yes, you are right, I got you wrong. You were saying >>We already have
this covered in our javascript code by parsing the scripts, but I want
to make a switch to have this turned off<< so I thought you wanted to
preprocess all scripts on the server side. If it's only for
writeElement/writeAttribute arguments are fewer.
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!
I'm talking about <!-- on the page level, not on the component level.
Facelets will treat <!-- as markup. Tags nested inside will still be
evaluated. With the writeElement/writeAttribute solution this could end
up in script being evaluated though nested inside <!-- -->.
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!
Ok, I understand, there is no scanning, just another condition inside
writeElement/writeAttribute.
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!
You still modify the markup, this may even alter the page design.
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
What do you want to express with >>outside of an insert or update cycle<< ?
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)
Still unclear to me what you are referring to here.
Best regards,
Ganesh
