RE: [PHP4BETA] Can PHP do XML + XSL = HTML stuff ?

Hello Lucas, On 14-Mar-00 16:08:21, you wrote: >> As I have been saying doing XML-XSL processing to serve >> pages at online >> time is a waste of performance, especially when there are much more >> faster and objective methods. [...] >Sure, it wouldn't be a very fast solution, but there are lots of >advantages that many people still don't see: >Imagine, you want to develop a web-interface for a database, which is >used to store specific XML-documents. >Now: how to transform this into HTML (maybe later to PDF, LaTeX, >whatever). >This transformation is the only "intelligent" aspect of your whole >application: It's not very difficult to develop your own XML-format >for your documents, but it's quite useless without transformation. Maybe you didn't notice what I said, but if you generate XHTML (XML compliant HTML) you don't need to invent another document format and you don't need to transform it to serve as Web pages because it is already HTML. >For the moment, it would be easier and faster to let PHP-code (using >XML and DOM-XML) do this transformation. But then, the "intelligence" >of your application would be in the code - whenever you want to change >the layout (or add a new one), you'll have to edit the code. Not if you use templates as I suggested to you before. >Using XSLT, the intelligence would be stored in your XSL-scripts >(that's why it's hard to write them, but it's easier to read and edit >existing ones). This makes it much easier to change the layout of your >whole application without having to touch your PHP-code. In some >cases, this aspect of flexibility is more important than speed (btw: >CPUs are getting cheaper, programmers / designers are getting more >expansive...). >I've started developing such an application 6 months ago, but the >PHP-XSL-integration-part is still missing. So I'm very thankful for >this discussion. I can see you never tried any of that in practice or else you wouldn't be say what you are saying. You're point of view seems very theoretic. XML/XSL combination only seems nice when the document transformation you want to do are mere replacements of data by data. When you want to do more complex things like building table of contents and cross reference lists you are stuck. It's like try to do it all with Unix sed program instead of TeX or something that is based on code not data. Just give you an idea of the complexity of what you are suggesting, take for instance this extract of real world XML document. This was used to generate offline an HTML version available in the following address: http://phpclasses.UpperDesign.com/browse.html/package/1 The document was not generated with XSLT. It was generated with a programmatic engine that does complex things like those above that I mentioned. HTML output was handled by a module of the engine that takes a *separate* HTML template file. The <tableofcontents /> tag is handle by an document module that processes forward references to generate the table of contents entries. Last time I looked into XSL it didn't seem easy, if possible at all, to achieve this. Another aspect is the time and CPU that it consumed to generate this document. With PHP 3 it is very slow. To process a 40K XML document it took 90 seconds. With PHP 4 with Zend optimizer enabled it took 11 seconds. If I cached the XML documents it still takes 8 seconds in a Linux based 233MHz Pentium. Of course you could use some C based XSLT processor and faster CPUs. But one thing you can't away is of CPU usage. Keep in mind that if a machine is busy with one process sucking the CPU all the other processes crawl with it, which is much worse than if the machine was busy doing I/O (disk or network access). <?xml version="1.0"?> <document> <title>Forms class documentation</title> <author>Manuel Lemos</author> <authoraddress>mlemos@acm.org</authoraddress> <body> <list> <p><b>Version control:</b> <tt>@(#) $Id: forms.documentation,v 1.2 2000/03/04 20:57:06 mlemos Exp $</tt></p> <heading>Contents</heading> <tableofcontents /> </list> <sectionbreak /> </body> </document> Another thing, be very careful when you use the argument that CPUs are getting cheaper to push the flexibility versus speed issues especially because Web applications are not single user applications. That means when you want to serve pages to many simultaneous users with such a slow method it won't scale well, meaning that you need more hardware to serve more people and then the its cost becomes very relevant because the software solution you used is wasteful. Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org -- E-mail: mlemos@acm.org URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp --