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

Hello Jirka, On 16-Mar-00 13:15:59, you wrote: >> >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. >But it may be ugly document which is hard to manage, because you mix >structure (your own "hi-energy" tags) with presentation classical HTML >tags like <table>, <font>, ... Right, but for the end users that is irrelevant. Any browser may display XHTML and that's what matters. Users could not care less of separation of content from data, that's a programmers concern. The original poster already has his data separated in the database. Serving HTML/XHTML is just a matter of insering that data into HTML templates. Taking data from the database to generate XML and than transforming into HTML to serve to the user, it's pretty much like going from Europe to America flying over Asia, rather than going straight over the Atlantic. Either way you will get there. Don't you think? >> 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. >You are wrong. XSL(T) all necessary to generate things like ToC, >references and so on. I had 10 year experience with TeX and one year with >XSLT, and I must say, that in XSLT it is much more simple and elegant to >write code which extracts ToC, computes cross-references, generates index >and so one. If you do not believe, have a look at XSL stylesheets >for DocBook documentation DTD (www.nwalsh.com). Not that I don't believe. I had no information about it. Most the XSL stylesheets look cryptic to me. Personally I prefer defining the contents of a document folling it's flow rather that defining rules for matching and replacing. If you can do TOCs with XSL now, it is because it was added support to iterative processing. I just don't know how things like page numbering will appear in table of contents when it only makes sense for media formats meant to be laid out in numbered printed pages. >> 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. >Over two last year, XSLT changed rapidly. But now it have quite powerful >set of features. Some things are still lacks -- e.g. generating multiple >documents by single stylesheet. But this can be overcomed by using XT >non-standard (but very usefull) extension. I don't know enough about it to figure well how everything can be made to work with a single document module. I wonder how things like for instance pictures are supported as formatting objects and then are outputted as separate files for some formats (HTML) and as embedded data in others (PDF, Postscript, RTF, etc..). Another puzzling point about XML/XSL composing is that how metadata like hyperlinks and document properties (author name, document date, etc..) are passed explicitly to the end formats rather then by rule (XSL rules). I haven't looked thoroughly into DOM formatting objects so I did not find support for this kind of data tags. >> 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. >One a little bit faster machine (333 MHz) XT processor is able to handle >0.5MB input file and apply rather complicated transformations on it in few >seconds (5-10). If you use it as servlet for smaller documents, Do you have any pointers for pages that detail the conditions of performance tests like that? >performance is not so bad. And there are upcomming projects, which focus >on inteligent caching. For example Cocoon (xml.apache.org/coccon/) has I'm not sure what kind of caching are you talking about. I have developed a smart server side caching engine that was only smart because for each page the programmer would tell the engine if the target data is still upto date rather than being the engine to figure that automatically. That has to be that way because if you are pages are generated dynamically there is no way for a fully automatic engine to figure if data is always upto date. That is the case of the original poster's data. It comes from a database. If he generated XML from that data by inserting it in the appropriate spots and then used XSLT to transform it to XML there is nothing to cacheable that the XSLT engine could. The cacheability checks would have to be done before ever generating the target HTML. Anyway the point is that frequently the output is not very cacheable because the data required to generate it is very dynamic, like often is the data from databases, which is the case of the original poster. >idea, that XSLT stylesheets will be complied to filters in Java .class >files. You will get flexibility of XSLT and speed of Java. The speed of Java was never very exciting! :-) 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 --