Re: PHP XSLT extension

I think we could have both. A PHP userland function such as "$result = xslt_munge($strXML, $strXSLT);" and a way to hook into the output stream. We could start with the first which seems to be easier to do and continue with the latter. It would be nice if we could bundle an XSLT package with PHP. This means we would need to ask its author for permission. Andi At 01:07 PM 6/25/00 -0700, James Byers wrote:

        Sam,

        VA is in the process of building a content management / publishing

system based on XML/XSLT. We ran up against the same design question of how to choose stylesheets for a particular request and decided to build this logic in PHP-space.

        While pipelining would be desirable for speed reasons, we are caching
the final transformation result anyway -- and liked the flexibility of modifying

PHP or database logic instead of an external map. There are many parameters affecting the choice of stylesheet and, possibly, many alternate stylesheets that will work for a given transformation -- but only one optimal choice.

        The high-level flow of what we're doing is:

        - get language/locale/path and browser info. from the HTTP request
        - query for the XML components making up the page based on these
          parameters
        - query for the stylesheet[s] required to transform these components,
          choosing the optimal sheet based on the above parameters
        - apply the transformations or fetch pre-built components from the cache
        - build a resultant page from many XSLT-transformed components and,
          optionally, pure PHP components

        (There are some character set transformations I've neglected, but this

isn't relevant to the XSLT part.)

        For a given page, we aren't mandating all the output go through XSLT.

Some parts of our pages lend themselves very well to XSLT, namely the well- cacheable, mostly-static sections. Other parts, however, don't need the overhead of XSLT. For example, our page header is completely static except for one 'Login: username - $5000 in your shopping cart' section. This part of the page is going to be a straight PHP component. So, strict post-processing of the entire request doesn't fit our model. We would benefit most from a straight PHP interface to an XSLT processor called as:

        $result = xslt_munge($strXML, $strXSLT);

        We've tried TransforMiix, Sablotron, and both Java and C++ flavors
with varying degrees of success.  At the moment, we're using Xalan-J.  So far,

it has been the most stable and error-friendly of the bunch and supports XSLT parameters correctly. It isn't as fast as the C++ parsers, but as we're caching the final transformation result, this isn't a big deal.

        James

P.S. If anyone is interested, there's a fairly detailed design document on this system (called Valence) at: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/v1/DESIGN?cvsroot=valence

        We don't yet have a good high-level document, describing for example

the generic method for combining XML/XSLT and PHP components on the final output step. Hopefully, we'll have this in a week or so. On Sun, Jun 25, 2000 at 06:00:32AM -0400, rubys@us.ibm.com wrote: I think the biggest problem to be solved is how to specify which stylesheet to be used on a request by request basis. Up until this point, I had been assuming that this needs to be done external to PHP; now I am not so sure. The cocoon guys found that the pipelining of this data (having the filter consuming it as it is being produced) to be very important - otherwise the web servers memory requirements was excessive and the latency before the beginning of the output was an issue. So would I. For the moment, I am going to continue with Cocoon integration, but for the longer term a PHP native implementation of a site map would be worth exploring. I am still interested in hearing if post-processing PHP output was what people had in mind, or if there were other interesting ways in which people were thinking of using XSLT. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

--- Andi Gutmans <andi@zend.com> http://www.zend.com/