Re: [phplib] The change to PEAR... From: Kristian Koehntopp (kris <email protected>)
Date: 01/18/01

In netuse.lists.phplib you write:
>Ahh.. this make more sense! But again.. if all of your data (including
>the external [X]HTML) is known before hand, what makes it more powerful
>than plain HTML templates? Just the ability to do fancier things at a
>later data?

Template is procedural. You have to write code that navigates
the data structures and sets the variables, you have to write
code to call the set_block() and parse operations in the right
order.

If you chose to select XSLT push processing as your paradigm,
you do not bother at all. You define locally how each element
will be rendered:

<xsl:template match="bookref">
 <a target="bookref"
    href="{concat('http://www.amazon.de/exec/obidos/ASIN/',
                  . <email protected>,
                  '/kristiankohntopp')}">
  <xsl:value-of select=". <email protected>"/>
 </a>
</xsl:template>

and if this element is ever encountered the appropriate
matchrule fires. You do not care about context or invocation, it
happens automatically. This is for some contexts (transformation
of fulltext with specialized XML formatting markup in it) much
easier than Template can ever hope to be.

On the other hand you have XML data of table nature, for
example SQL query results. Such data us best processed using
iteration loops and pull processing. Here you have name rules
and you call them manually in a <xsl:for-each/>

   <xsl:for-each select="chapter">
    <hr/>
    <xsl:call-template name="chaphead"/>
    <xsl:call-template name="chapter"/>
   </xsl:for-each>

Read "call-template" as "gosub" and you understand what happens
here.

>Right, that's all good, but to restate the obvious just for the
>record, till GoLive, Dreamweaver, and the other GUI design
>tools catch up, plain HTML templates are still required.

XMetal, XmlSpy and XmlWriter. And emacs, of course (curse?).

And besides, simplified stylesheet syntax is just plain HTML,
plus some "browser specific tags with funny names".

>[on a side note.. would you, or anyone, have any data about performance
>between Sablotron Vs. some/any HTML based template engine]

Johann-Peter Hartmann has data on XSLT engines,
http://www.php-kongress.de/2000/abstracts.php#13, comparing Sab,
Cocoon, Xalan, Cocoon II/servlet, and TransformiiX. Sab is the
least complete of all, but also the fastest. Ulf has data on
Template engines comparing FastTemplate, EasyTemplate and
PHPLIBs Template and ITX. ITX is in first, Template is second,
FastTemplate is slowest. There are no numbers of Template vs.
XSLT I know of.

>And I also understand and agree with the decsion to move phpLib
>into PEAR. In theory, it is a great idea and helps people on a
>much larger scale and benifits all of the PHP community. I
>think that in practice though it will be a bit more difficult
>for the porters as well as the users. My beef is with the fact
>that as it stands now, PEAR is not very useful nor very well
>designed (that i can tell) in terms of scaling up to something
>the size of CPAN.

If you think that the PEAR people need a spanking, I have some
cat-5 (shouldn't that be cat-o-9?) cable to make floggers from.
Preferably spank them with diffs or commits. A PEAR that sucks
is of no use to you, either, as it will ruin the reputation of
PHP. If you think a mass spanking is needed, you should conspire
on this list and then take them over. I know you can do it.

>And in answer to one of my orginal questions: the PEAR group is working
>on a license for PEAR modules that will be GPL complaint. See
>http://marc.theaimsgroup.com/?l=php-pear&m=97893078603364&w=2 for details.

Not an issue with PHPLIB, as we are LGPL and do play nice with
the PHP license.

Kristian

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>