No, the job of facelets manily stops when the components start rendering
:) FAceLets is a view handler, it doesn't interfer with generated outptu
from component. The rendering job of facelet is limited to non jsf parts
of the template.
En l'instant précis du 08/01/08 10:22, R. Müller s'exprimait en ces termes:
hi,
thanks for your replies. you're right - modifying the tomahawk sources
would be the fastest (in terms of rendering-perfomance) and cleanest
way, but i don't like 'custom' libraries for future compatibility.
it has to be done by the project, if it is common position.
so as a workaround, i followed your 2nd suggestion to write a filter.
propably much slower, but it works for now and is independent from the
libraries.
btw: is there a way to do this with facelets? does facelets build a
internal dom-tree of the final web-page ? if so, it would be easy to
check the script-parts for CDATA-section and if not found to add this.
regards
ronald
David Delbecq schrieb:
Yes, for tomahawk parts at least. Most tomahawk component makes call
to AddRessource, using methods like 'insertScript(....)', you could
overrride those methods and recompile your tomahawk. As for myfaces,
most javascript rendering routines are in a few helper classes
(you'll have to dig your self). Same rule applie: change the code,
recompile.
is there an easy way to put these parts into CDATA-sections to get
well-formed xml-pages ?
Your could write a filter that convert
<script (.*)>(.*)</script>
to
<script $1><[CDATA[$2]]></script>
Or, as mentionned, patch the myfaces/tomhawk code?
--
http://www.devlog.be (a belgian developer's logs)
