Last week I introduced an XML function for my database class. The reason for it is because of the beauty of XSL. Or should I say, the beauty of XSL after you can get it working. You see, the problem with learning new things is that you always run into problems. Stupid problems. Problems that can be fixed with one line of code, but take you 5 hours to find that one line. So I have decided that some of these problems deserve documentation.
XSL(T) works nicely because it can be done strictly on the server, or you can create a client/server mix using JavaScript. This is where the problems begin. Problem 1
If you decide to generate your XML on the server, and process the transformation on the client, you will be happy to know that IE and Firefox handle things differently. As always, more work for us. What happens is Firefox actually returns nodes, so that you can append your returned nodes as a child. On the other hand, IE returns a string, so you have to use innerHTML.
Problem 2
When you are generating your XML on the server, it seems fairly straightforward, as it should be. After going through the motions, I have found that PHP has a particular quirk. If you generate an XML file with PHP, and then process the transformation on the server with PHP, everything works fine. Do the same thing, and process with JavaScript in IE, and everything works fine. Naturally, the browsers don’t agree, and doing this in Firefox causes problems. It turns out you need to modify the header that the XML generating PHP page returns.
header('Content-type: text/xml');
Place that before you echo out your XML, and you should be set. Those are just two of the problems I’ve run into with XSL(T). You may run into similar problems when developing around XML, so you may find this useful.
I like this post :)
Rather than using innerHTML, you could use createTextNode(string) with the string that is returned from IE, and then append that as a child.
As for Firefox requiring the modified header, that is as it should be. My guess is that IE is looking at the data and figuring out what it likely is, even when the header information doesn’t match (it is being very liberal in what it accepts).
Firefox, on the other hand, is not so liberal. It sees a mismatch between what the server says it is sending (probably text/html since it is coming from a PHP file) and what it is receiving (XML) and throws an error.
Given these browser differences, and since JavaScript is never a given, it might make the most sense to do the transformation on the server side…
Hmm, why don’t you just use the PI to do the client-side transformation instead of using the JavaScript?
I meant the <?xml-stylesheet?> PI, actually.
Mark - I agree that Firefox is processing it correctly. However, when learning how to do something it is not evident that Firefox is processing it correctly, especially when all other options work. So even though the browser is doing it right, all of my frustration still gets pointed towards it :)
Also, the transformations have to be done on both the client and server for degradable Ajax.
Manuzhai - I’m only using XSL to change small areas of a page, without the page reloading. The initial page loads as normal php page, then when the user clicks certain things the content changes, and I’m pulling those changes in with JavaScript.
Problem 2, I had a similar issue with Flash - I had to specify header(‘Content-type: text/xml’); at the start of the PHP script of an RSS dump or the Flash ticker got all confused.
Silly strict/ fluffy mime-type handling difference between FF/ Flash and IE…
Server side XSLT processing always seems to work better for me, I find it more predictable and less of a strain on older clients.