Re: New XSLT class for PEAR
| From: | Christian Stocker | Date: | Mon, 24 Feb 2003 16:51:48 +0000 |
| Subject: | Re: New XSLT class for PEAR | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-13768@lists.php.net to get a copy of this message | ||
On Mon, 2003-02-24 at 17:42, Dan Kuykendall wrote:
> Christian Stocker wrote:
> > Hi
> >
> > I just looked quickly through your code...
> >
> > 1) I like the "browser supports xslt"-idea, but why aren't you building
> > the idea into the existing XSLT wrapper? 2 different XSLT-Wrappers won't
> > get my +1...
>
> I didnt spend a ton of time to understand the existing XSLT_Wrapper
> because it seemed to make it even more comlicated to use XSLT than just
> using PHP's built in XSLT. I may have missed something and do plan on a
> more detailed look. I do like the other XSLT class for the purpose of
> choosing an XSLT engine to use, but I dont really see why its all that
> important since PHP's xslt support is working pretty well.
I don't like sablotron (anymore) for several reasons and prefer libxslt
for example. Others prefer features of other processors, etc. so
XSLT_Wrapper makes sense. Although, I never tested it (I use my own
wrapper..) and maybe it's not that simple to use. If that's the case,
there is certainly no problem to add methods, which make XSLT_Wrapper
easier to use.
Commiting a second XSLT_Wrapper into PEAR just doesn't make sense to me
and should be avoided, unless you do something completely different than
XSLT_Wrapper and can't integrate that in a decent way.
> > 2) Mozilla > 0.9.4 supports xslt as well
>
> I have had problems getting mozilla to accept that the results are XML
> if the file extension is .php
> If we have somefile.xml and it has the exact same contents, it will
> process the XML, but with the script being .php it wont.
> I plan on finding a solution to this, but havent got one yet. One
> possibility maybe that I need to set the content type with the HTTP headers.
Yes, you have to send the files as "Content-type: text/xml", otherwise
Mozilla won't do anything.
> > 3) reading the xml/xsl into php memory and then sending to Sablotron is
> > (IMHO) quite stupid, Sablotron can read from the file system. Somehow
> > this should be supported, too..
>
> Good point. I can correct that pretty easily.
>
> > 4) Building a template system around XSLT??? mmmh, doesn't make much
> > sense to me ;)
>
> Well, I can agree, but I keep running into people who dont want to
> construct the XML. Even using XML_Tree seems to throw off some people
> (which is the reason for my importVar() addition to XML_Tree).
>
> There are also some other things that can be more easily supported, such
> as themes.
As I said, it's just my opinion, maybe someone else can use it and I'm
certainly not against it.
chregu