On Wed, Aug 01, 2012 at 06:19:46PM +0200, Martin Kletzander wrote: > Hi everyone. Re, > TL;DR is there a way to keep PHP code untouched in XSL transformed XML? I guess that you need a dose of "disable-output-escaping" http://www.w3.org/TR/xslt#disable-output-escaping so basically you import the PHP in text node untouched one way or anover (double escape of input or XInclude of text part [1]) and then output those fragments with <xsl:text disable-output-escaping="yes"> your PHP code ... </xsl:text> > For a while now, I'm trying to make our 'search.php' file generated like > all the '*.html' files (with all the fancy stuff like up-to-date menu, > headers and so on). > > The problem I've been facing looks like an easy and doable thing /at > first/, but every normal approach I tried didn't work. I'm most probably > doing something wrong. I haven't used XSLT that much and this is very > badly google-able topic as lots of people are using XSL transformation > *inside* PHP and mangling the search results in their benefit. > I tried: > - using CDATA > - transforming the code with various elements > - turning off output escaping > - putting the code into another element > - various combinations of previous things > - and few others Nice try, you looked in nearly all directions ;-) > Now it looks like the only option is to put the code part into another > file and inject it after the transformation, which is ugly, because it > means lots of modification (and unnecessary lines of code) for one file > (even though it would be applicable for all /possible/ future scripts). > > I know this is not the best place to ask this question, but since we > have the web page generator using XSLT *and* it is for libvirt's > benefit, someone on the list might help me. One solution might be to XInclude [1] as text the php in the XML data, and use HTML serialization of the XSLT output [2], but that still looks error prone. To be honnest i would not bother too much about making the output generated by XSLT directly, concatenation at the shell/python/perl would be just as good IMHO as long as we don't need to fix it too often :-) Daniel [1] http://www.w3.org/TR/xinclude/ [2] http://www.w3.org/TR/xslt#output -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list