XML/XSL with javascript dynamic content?

Forum Moderators: open

Message Too Old, No Replies

XML/XSL with javascript dynamic content?

Is it possible?

NooK

3:35 pm on Nov 1, 2007 (gmt 0)

I am currently designing a website which will contain different order forms and I have been doing a lot of reading and it seems xml/xsl is a nice idea to try and specify the forms.

My problem is that the forms will need to contain a lot of dynamic content (Such as parts of the form being hidden or shown depending on which options the user chooses and so on) so I was wondering if it is possible to tackle this with php and XML/XSL? Is there anyway easy way to use javascript on an XML generated webpage.

One example is that the form will consist of different pages with next and previous button to go through every page (Until the user reaches the last one and submits).

Best Regards

NooK

cmarshall

3:51 pm on Nov 1, 2007 (gmt 0)

You have a number of choices:
1) You use XSLT to transform the pages on the server, then send rendered forms to the browser (Very compatible, but can be pokey).
2) You send XML and XSLT to the browser to be transformed locally (Requires modern browser, but quicker).
3) You use PHP's XML Parser [us3.php.net] to render without XSLT.
4) You write your own XSLT to transform to JSON objects and send that to the client (either directly or through AJAX) -I do this, and can show you examples.
5) You use the JSON Stylesheet [bramstein.nl] to transform the XML to JSON for use by the client. (Warning: I notice that it is XSLT 2, which is not supported by PHP, and I have my doubts as to how easily it will work. This is probably best coupled with #2 above). Here is another library that might help [code.google.com].

You can always insert JavaScript into XSLT with CDATA sections (I do this as well).

I hope this helps.

httpwebwitch

7:05 pm on Nov 5, 2007 (gmt 0)

I always suggest you do your XSLT transformation on the server. It's just so much better than relying on a client to do it. Many "browsers" (phones, blackberries, weird old browsers, etc) can't or won't do client-side XSLT.

The only time I recommend client-side XSLT is when you're giving the user XML as a web service (eg. an API, RSS feed, et al), and you want to pretty it up when someone looks at it in a browser that supports client-side XSL. A lot of RSS feeds are rendered nicely this way. But it's unfriendly to send XML to someone when HTML is more appropriate, relying on their browser to turn it into a readable, useable interface.

Imagine if you're one of those poor suckers who tries to fill out your form using a hand-held device, WebTV in their hotel room, or something similar. They'll see a readout of confounding XML, not the dynamic interface you intended.

Design your forms as though they're regular XHTML. Use Javascript to do your fancy effects - hiding and showing parts of the form. Be aware that some % of your users will not have Javascript enabled, and won't "get" your show+hide effects... will you care? Put your JS in an external file and call it in the <head>. Then use XSLT to create a faithful rendering of that HTML form, of course using the data in your XML source to customize the fields or whatever.

Rendering HTML with server-side XSLT is pretty similar to rendering it with PHP or ASP or what have you - your end goal is to have some nice valid (x)HTML sent to the client. The method you use to render that HTML is a personal choice.

Rule of thumb (admittedly a thumb which I sometimes break):
* If the data you're rendering is transported as record columns in a table or array, build your HTML using for-loops and variables and typical programming methods. Forcing things through an XML->XSLT layer adds often unnecessary overhead.
* If the data you're rendering is transported as XML, toss it through an XSLT transformation and rejoice in its elegance.