Re: PHP XSLT extension

I am curious as to how people expect to see PHP and XSLT working together. At one level, simple integration between PHP and XSLT could be accompished with the addition of a single API that does an xstl_transform, where three files are specified: the input, the stylesheet, and the output. In discussing this with others, a different approach has surfaced. Namely to to treat the output produced by the PHP page itself as the input to XSLT. There would need to be a means to specify the stylesheet to be used, but more on that in a minute. What this would help address is a criticism that I have heard from time to time expressed about PHP (and ASP, and JSP, and ...); namely that it doesn't encourage the separation of content, logic and presentation. This sounds complicated, but the way it would work is pretty simple. When used in this way, PHP pages would be simplified - they merely would be responsible for taking the request parameters (including cookies and session data) and processing the result. Instead of intermixing the logic to handle the presentation of the data (i.e., HTML tags), the PHP page would simply focus on tagging and organizing the data hierarchically. Again, the output of the PHP page would then be processed through a stylesheet. Ideally, this would either be done concurrently (i.e., in a pipeline); or by the client. Also, the true strength of this approach become apparent when the site designer can vary the choice of stylesheet on a request-by-request basis. For example: depending on the request, send the results as XML, PDF, WAP, or HTML. The first implementation of these concepts that I am aware of is cocoon at xml.apache.org. It has a (currently) Java centric XSP language that can be used as input, and a "site map" which configures the pipeline of processors. Earlier this week, I started work on adapting the PHP servlet to be able to be run as a Cocoon generator. It is also worth noting that there is a new Perl implementation of these concepts being developed at http://axkit.org/. There is no reason that a similar effort couldn't be built into sapi/apache or any of the other server APIs. In fact, it could be built into the sapi structure itself, with the individual server implementations simply being responsible for determining where to get the appropriate configuration information. That's enough thoughts for now - I hope this helps to bring into focus some of the various alternatives worth exploring. - Sam Ruby