Re: [phplib] The change to PEAR... From: nathan r. hruby (nhruby <email protected>)
Date: 01/18/01

Kristian Köhntopp wrote:

> "Max A. Derkachev" wrote:
>
>> Well, XSLT is the right thing, of course, but it needs not only an XSL
>> template, but also an input XML document, doesn't it?
>
>
> If you are using a HTML/XHTML document as the stylesheet and are
> using only XSLT parameters in your stylesheet, an empty XML file
> will do. The stylesheet is instead the document being served. This
> is identical to Template, where the template contains the HTML,
> and {NAME} sections are being replaced by variables.
>
> What Template calls variables are <xsl:param/>s in XSLT nomenclature.
> <xsl:variable/>s are the same syntactically, but defined internally
> in an XSLT template (the source of the definition is different).
>
>
>> Your template engine, instead, helps to produce any document
>> (HTML, XML, plaintext or, maybe, even a binary) from scratch.
>
>
> Using <xsl:output/> definitions, you can produce XML, HTML or
> plaintext.
>
>

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?

>> So, I don't see how we could quit using Template and friends in favour
>> of XSLT - for me they're different things, while sound similar.
>> Do I misunderstand something?
>
>
> I believe so. Simplified XSLT syntax is just Template with
> a different syntax for {NAME} and a normative comittee behind
> it.
>

Point. And a good one.

> Fully fledged XSLT is way more powerful than Template, and
> the upgrade path from Simplified XSLT to full XSLT is smooth.
>
> Kristian

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. There's also the thought that,
logically, HTML templates make more sense simply becasue you're dropping
in the right data in the right place, as opposed to a pseudo-translation
of data.

I work with designers everyday, and trying to teach them XLST and to
code it with out the ability to instantly see the graphical layout would
be impossible, they have problems enough understanding why not every
file needs a <body></body> tag :)

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

In reply to the rest of this PEAR thread, I really don't want to come
off as a troll here (in my previous posts or this one). Understnad that
i'm arguing from several places all at once: an individual user (who
sees this as new and exciting),a devloper of apps that use phplib (who
sees this as a little scary) and as a disliker of PEAR (who sees
legitimate issues with it).

Phplib has been an invaulable tool for me, and Kristian himself has
helped support phpSlash, without him it probably wouldn't exsist today.
  For those things I thank him and Ulf enormously and endlessly (Perhaps
we should make t-shirts, <sniff.. wipe tear>)

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. Or even scaling to anything larger than
it is now. (also the PEAR DB class just ain't db_sql, but that is really
my biased and subjective opnion)

Kristian has stated that the best way to make it useful is to jump in
and fix it, which is a great senitment, but one I currently don't have
time to act on. (The last time I did that I ended up with
maintainership of phpSlash :) And I think some of the problems are not
fixable by one individual, they are larger issues that need to be
addressed by the php community as a whole [ie: module desgin (dealt with
to a certian degree), keeping in synch with PEAR (for both module
devlopers and app devlopers and end users)], as well as the designers of
PHP [ie: namespaces]

I think there are a lot of unanswered questions and a lot of thought
that still needs to go into PEAR before it can be a truly invaluable
resource, and I worry that putting phplib into PEAR now will have
detrimental effects as PEAR hits the wall with these questions and
instead of properly devloping PEAR into its own thing it'll become a
patchwork of diffrent standards and implementations. I'd like to see
this merger of phpLib into PEAR as a good reason to work on these
questions and issues so they don't bite all of us in the ass later.

Yes.. i'm a big worry wort. Sue me.

Yes, Ulf and Kristian's statments of an easy migration make me feel a
lot better about the whole thing.

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.

-n 

-- 
........
nathan hruby
Webmaster: UGA Department of Drama and Theatre
Project Maintainer: phpSlash, Carousel
nhruby <email protected>
........

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