xsl-list
[Top] [All Lists]

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

2007-10-13 06:43:26
Hi,

my comments below :)

On 10/13/07, Abel Braaksma <abel(_dot_)online(_at_)xs4all(_dot_)nl> 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

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--