Re: Re: new template engine
| From: | Tomas V.V.Cox | Date: | Mon, 23 Jul 2001 18:06:04 +0000 |
| Subject: | Re: Re: new template engine | ||
| References: | 1 | Groups: | php.pear.dev php.pear.general |
| Request: | Send a blank email to pear-dev+get-1004@lists.php.net to get a copy of this message | ||
"Alan T. Miller" wrote:
>
> > > > Which Advantages has Smarty opposite the Intergrated
> > > > Template IT[X] ? I am very satisfied with the IT[X],
> > > > the ITX is clear still very unstably but to this one
> > > > can work.
>
> The point is not so much the technical merits of SMARTY vs. IT[X], or at the
> least, it should not be. The point is that there are a lot of people who are
> using SMARTY (PHPLIB Templatess and so on) and these people would like to be
> able to use the templates they have always used but as PEAR components.
>
> The point here to consider is not so much whether one template engine is
> better than another, the point is that if PEAR were to include those
> components that people either like to use now, would like to use in the
> future, or perhaps most importantly, plan to use, they would obviously see
> PEAR as much more attractive. This could have the effect of making PEAR seem
> indispensible. The result, I argue would be: increased use of PEAR,
> increased awareness of PEAR, increased involvement with PEAR, increased
> contributions to PEAR and on and on... which I feel is a good thing.
>
> If you think about it, there are still people out there who insist UNIX is
> better than Linux, maybe so, but the bottom line is that Linux moved the
> *NIX world a giant leap forward, which in turn has had the ironic effect of
> making Unix more attractive than ever. If one template engine is truly
> superior to another, then in the end, that template engine will be just
> that, the superior template engine, because that is the one people will use,
> further develop, further document, etc etc etc. Who really cares what
> happens to the others? At most they eat up a few bits of disk space
> lingering around on the CVS server.
>
> I see the addition of SMARTY, PHPLIB Templates, CachedFastTemplate and
> others as a big move forward and as a real turning point in PEAR's
> development if we allow it to occur. Moving in such a direction would send a
> message that PEAR is ready to move forward and wants to open its doors to
> others for contributions. As it stands PEAR is facing a real crisis as there
> are a lot of people who are feeling dienfranchised and like the developers
> of PEAR are nothing but a bunch of snooty programmers doing their own thing
> with no sense of community. Of course I am not making that accusation but I
> have seen that attitude out there on the net.
>
> Anyway... not to sound too critical, or to start a flame war, but I really
> think it is obvious that people really want to have a shared code repository
> that accommodates their needs, even if it means there are a few extra files,
> or it adds a little confusion here and there. Also, for the most part I
> think there is a general consensus that most people would like this code
> repository to be PEAR and not some other forked project.
>
> At the moment, there are many template engines in use, but they all lack
> something somewhere, bring them into PEAR, and eventually one will shine
> above the others and it will benefit us all.
>
IMHO the idea of PEAR is quite clear: "a set of highly reusable
components that meet certain requirements of coding standars,
documentation style, error reporting and quality". If Pear starts to
accept everything, Pear will become something like hotscripts and
believe me this will kill Pear. I think that there are thousands scripts
that meet in purpouse the Pear classes, but if people choose to use the
Pear ones it's because them meet their needs. Having many classes that
provide _similar_ functionalities only will confuse people and make
things harder to do, things like maintain, support or document.
You talk about forks. Forks in Open Source software is a natural thing
and benefit the developers as they can choose what they want/need. But
forks _inside Pear_ will be evil for both users and Pear developers. If
someone ask me, "what provides Pear?" and I answer "Pear provides 3
abstraction layers, 8 template systems, 3 documentation methods, ...",
he probably will think that Pear is at least silly (including me in
helping that mess to grow ;). I'm friend of improving, enhancing or even
replacing but not of duplicating.
I'll be very glad to see more developers joining to the Pear effort, but
for me to join to a proyect means help them, not "hey you, I come here
with my things put them over you and please also help me in maintain
them and correct bugs". Pear is entirely open to anybody that comes with
ideas on how to improve actual things or developing new ones, and sure
will open their doors to you.
The people that don't know nothing about Pear could think that Pear
developers are snooty, egoist, etc. ok, but nothing more far from the
reality as Pear is an _Open Source_ proyect and is making many efforts
to give the community good code and resources for distributing and
installing them in a easy way. Perhaps some parts not yet very
"user-friendly" but this subject is changing step by step. And of course
if you want to see that happen more quickly you only need to join Pear
:)
Tomas V.V.Cox