[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: CLAX - Client-side functionality
Hello Here is my take on a client side XSLT engine. There are couple things missing though: a) checking the environment dependencies like for instance a particular interpreter version. b) pipeline processing c) non HTML output like for instance SVG (this last thing works in IE but not in Firefox) d) other stuff you guys have in mind. The following link works in both IE 6.x and Firefox 1.5.0.3 may work with other version but I didn't checked yet. The code will be open source and freely available soon (I still need to decide on the licence) Here is the link: http://webtop.netfolder.com/framework/window/src/window.php?validate=no&xslt =..%2f..%2ftreeView%2fsrc%2fpdml-simplified.xsl&xml=..%2f..%2ftreeView%2fdem o%2ftoc.xml Actually, the xml document and the xslt have to be on the same domain. A small php redirector would do the job to fool the browser platform to think it's in the same domain. Note: don't get fooled by the window.php thing. It has nothing to do with PHP and the engine can be renamed as well window.web as lomg as your server handle this MIME type. I was simply lazy to set the MIME type on my server and reused an existing one. Any MIME type, file extension would work as long as it is not .htm/.html and anything the browser platforms think could contain parameters. What's happening behind the curtain of the previous link: a) the URL is parsed on the client side just after window.xxx is loaded in the browser platform. b) parameters are extracted and passed to an interpreter handling different function based on the parameters. For instance, it loads an XML document and convert it into a DOM if the xml parameter is present. Idem for XSLT. In the last case the "validate" parameter indicates to the engine to not validate the parameter list. Some parameters like "xml", "xslt", "validate" are reserved words. Other keywords than the reserved ones can be used as parameter names. Here is an example where the default style is overloaded with another one. Because the "css" keyword is not a reserved one it is simply passed to the XSLT template for processing. Here is the other link: http://webtop.netfolder.com/framework/window/src/window.php?validate=no&xslt =..%2f..%2ftreeView%2fsrc%2fpdml-simplified.xsl&xml=..%2f..%2ftreeView%2fdem o%2ftoc.xml&css=..%2f..%2ftreeView/src/folder.css Now an alternative way to see the hierarchical collection with a widget flatting it into a single layer drop box http://webtop.netfolder.com/framework/window/src/window.php?validate=no&xslt =..%2f..%2fdropSelector%2fsrc%2fdropSelector.xsl&xml=..%2f..%2ftreeView%2fde mo%2ftoc.xml The key thing here is to treat the browser as a platform like we would do with other platforms like Java or .net. To get something more sophisticated than just HTML interpretation, we need more sophisticated tools. Luckily, the browser platforms are more versatile than most people think it is (with the exception of the AJAX movement who treat the browser as a run-time sandbox able to interpret declarative (HTML) and non imperative languages (javascript) - the sandbox includes the capacity to expand its functionalities and hence add new interpreters through the plug-in mechanism - as an example, to load an SVG interpreter). Now, what about including an RDF description to indicate to the engine the required capabilities? If present the engine can check the requirements and possibly offers a way to download what is missing or redirect to another downgraded information context. What do you think? Any suggestion on the content of the RDF description or any other suggestion? Cheers Didier PH Martin
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|