Re: [PHP-DEV] PHP XSLT extension From: James Byers (jbyers <email protected>)
Date: 06/25/00

        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 <email protected> 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 <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>