On Sun, 2002-04-21 at 20:30, Wez Furlong wrote:
>
> $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.
Don't worry, I happen to agree completely (especially since I'm faced
with this exact problem at work).
> Stig can probably come up with some better examples :-)
Here's an example where database (imaginary "dbz" unified interface)
meets stream:
$fp = fopen("http://www.example.com/file.gif";, "r");
$st = dbz_prepare('INSERT INTO gifs VALUES(:gif)');
dbz_bind_input($st, ':gif', $fp);
$res = dbz_execute($st);
The third parameter to dbz_bind_input() may be any resource that
supports the output interface. You could say that for non-file/url
resources, input/output interfaces provide serialization. If
non-resouce types can have stock interfaces, you can pass objects and
everything around freely. God, that would be nice. :-)
- Stig
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
![http://www.example.com/file.gif"](http://www.example.com/file.gif"){kind=link}