$xmldoc = domxml_new_xmldoc(); // populate nodes of document here
// Now render it using whatever XSLT backend is available $proc = xslt_create(); $data = xslt_process($proc, $xmldoc, $xsl); The advantage is that the xml doc just created in code using one extension can be dropped straight into the XSLT processor, of a different extension saving line(s) of PHP script (which converts the XML doc tree into text), and most likely (depending on the internal implementation) eliminates that text conversion and re-parsing before the XSLT processor can use it. So thats less code to write, less for the ZE to parse/compile and most likely it will be faster to execute than the equivalent code in PHP script. It doesn't look like much, but it's the kind of thing that makes PHP "really nice" to use. The same concept could be applied to other extensions that are related in their application; for instance, the vpopmail, imap and mailparse extensions could be used interchangably for some purposes, image extensions could re-use each others image handles and so on. All this can be done in user-space, but with a load of "glue scripts": while we keep saying "but PEAR can do that", not all projects can or want to use PEAR (sorry Stig!), in particular, some commercial projects would prefer to keep things very lean, or would feel safer building up their own frameworks. Having this kind of "native shortcut" is an attractive feature, IMHO. Stig can probably come up with some better examples :-) --Wez. On 21/04/02, "Andi Gutmans" <[EMAIL PROTECTED]> wrote: > Hey, > > Although this sounds interesting I still have a hard time seeing the end > result. > Can you please give a description/examples on how this will impact the end > user? > > Thanks, > Andi -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
