Re: [PHP-DEV] PHP XSLT extension From: Andi Gutmans (andi <email protected>)
Date: 06/25/00

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 <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> 

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

-- 
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>