Re: [libvirt] Generating our docs/search.php with xsltproc
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/