Re: [xsl] Troubles with libxslt in PHP again: CDATA in <script>

Subject: Re: [xsl] Troubles with libxslt in PHP again: CDATA in <script>
From: "Martynas Jusevicius" <martynas.jusevicius@xxxxxxxxx>
Date: Sat, 13 Oct 2007 15:42:41 +0200
Hi,

my comments below :)

On 10/13/07, Abel Braaksma <abel.online@xxxxxxxxx> wrote:
> Hi Martynus,
>
> See my comments below
>
>
>
> Martynas Jusevicius wrote:
> > Hi Abel,
> >
> > well, on my machine I'm using PHP 5.2.2 which is giving me problems,
> > but my hosting uses 5.2.5 which seems to behave yet again differently.
> >
>
> That's PHP. I am interested in XSLT: what processor version do you use?
> Please follow the list guidelines and use the info you get in any
> subsequent posts so we can more easily help you:
> http://www.mulberrytech.com/xsl/xsl-list/processor-version.xsl (from:
> http://www.mulberrytech.com/xsl/xsl-list/#posting)

I'm using whatever php_xsl.dll extension in PHP 5.2.2 gives. I was
sure it's libxslt, and this is what processor-version stylesheet says,
not much else though:

XSL version: 1.0
Vendor: libxslt
Vendor URL: http://xmlsoft.org/XSLT/
Product name: [Undefined]
Product version: [Undefined]
Is schema-aware: [Undefined]
Supports serialization: [Undefined]
Supports backwards compatibility: [Undefined]

So I think the only way to find out is to check PHP's change logs.
The last mention of libxslt was in in 5.1.2:
"Updated to libxml2-2.6.22 and libxslt-1.1.15 in the win32 bundle. (Rob)"
http://lt.php.net/ChangeLog-5.php#5.1.2

>
> > My template contained JavaScript based on Google Maps API's "Hello world":
> > http://www.google.com/maps/api_signup?url=http%3A%2F%2Flocalhost
> >
>
> That link doesn't work for me, it points to the google signup page.

Strange, works for me. Try to sign up with a dummy host name such as
localhost at
http://www.google.com/apis/maps/signup.html
and you'll get the sample script.

>
> > So it looked like this:
> >
> > <xsl:template name="map-js">
> >
> > //<![CDATA[
> >
> > var children = []]><xsl:call-template name="js-children-array"/><![CDATA[];
> > map.setCenter(locationLatLng, ]]><xsl:value-of select="$zoom-level"/><![CDATA[);
> >
> > </xsl:template>
> >
> (sample truncated)
>
> Ah, that's an interesting piece of XSLT! Thanks, that makes it easier to
> find a remedy. But first of all: I ran your code (after removing the
> pieces that gave a compile time error) and guess what: no sign of
> <![CDATA[ in the output *at all*! So my guess is still that your
> serializer has some funny tidbits, or for the oddest reason, your ISP's
> HTTP daemon adds them...

Maybe I wasn't clear on this, but I get these problems on my localhost
machine with PHP 5.2.2. The //<xsl:comment> does the trick on it, but
not when I upload to the hosting running PHP 5.2.5.
But still I think that proves that ISP is not the source of the problem.

>
> But rest assured, you can easily resolve it: just remove all the CDATA
> opening and closing tags. They have no business there. The only reason
> you should use them is for easier writing of &lt; and &amp;. Any other
> symbol can be left as is, including > and &apos; and &quot; (in all but
> a few situations).

I know that well, but I think it is convenient to have all my JS
script code in CDATA since it is by no means finished. And when I'll
add new code, I don't want to think whether there were characters that
should be escaped or not. If it's all in CDATA, it will be escaped
anyway.

> To make this work, simply change the single "<" with &lt; or reverse the
> statement to read "children.length >= i". This will output these as &lt;
> or &gt;. And IIRC, modern browsers have no trouble with xml entities
> inside javascript when you set the doctype to XHTML.

That's what I mean, eventually there will sure be more loops etc. than
in this snippet, and more < > characters as well :)

But I'll tell you what -- it doesn't matter here. I just checked, and
even if I remove all the CDATAs from that template and escape the <
manually into &lt;, in the output I get everything wrapped in CDATA
anyway! And < not escaped in it.

>
> > (I hope I didn't introduce errors by cutting out not so important stuff).
> > And what I get as output is:
> >
> > <script type="text/javascript"><![CDATA[
> >    //
> >    var children = [new Location("Denmark", 55.329144, 23.950195)];
> >    //
> > ]]></script>
> >
> >
> > For now I switched to "html" output method as David suggested and all
> > is working fine.
> (sample output truncated)
>
> Of course, if this works fine and you are content with the HTML (and you
> don't intend to parse it back as XML) then there's no worry about
> resolving this issue. Still I am wondering why you manage to get such a
> strange output, I hope you can update with information on your processor
> *and* please run your code from the commandline to be sure PHP or your
> ISP isn't messing things up, the output from the commandline will proof
> *very* interesting. I've send you the details of a download site for
> xsltproc in my previous mail.
>

Sure I would like to produce XHTML instead, but it doesn't appear to
me that we have come to a solution for doing that.

I'll run on commandline when I'll find some time. But still it is not
so clear on what version of libxslt to run.

As far as I remember the Content-Type metas issue, I ran my
stylesheets on standalone libxslt as well but got the same results as
with PHP XSL.

Martynas

Current Thread