Re: Re: new template engine

Burak DAYIOGLU wrote: > > "Stig S. Bakken" wrote: > > decision. Right now "all of us" are maintaining "all of it", but that > > has to change. > > I don't want to be a noise source but the single most important reason > that "all people" are maintaining "all of it" is that the whole PEAR > project lacks documentation. > > People have long been asking for documentation to be able to understand > the framework, the classes and their interrelations. However it is of > the lowest priority for the PEAR developers. You are doing an excellent > job with improving PEAR, but for non-PEAR-hackers to be able to keep up > we need some simple documents or even the shortest sample code > fragments. > Unless this is done, I don't expect the PEAR developer community to > expand. > > I've been reading the lately discussions regarding what should be > included > in PEAR (e.g. numerous kinds of template engines or just a single one > doing some "best"). > > To me, having a single framework (instead of the original goal of the > project to become an archive like CPAN is for PERL) looks more > appropriate. The major rationale for this is that many classes require > heavy interrelations (e.g. access control, user mgmt., session). > Unless we have a total framework that helps us worm in harmony, PEAR > will > be just a class collection. > > In that latter case, using multiple classes together will require heavy > customization and knowledge of class interiors (to glue classes > appropriately), which will limit people from adopting it. I guess PHPLIB > people are the most appropriate ones to inform us on the issue with > their > prior experiences. Seen from the outside, it seems that PHPLIB has had problems getting contributors and keeping development alive. I think one of the reasons for this is that PHPLIB is "monolithic". PEAR tries to avoid this trap by making a modular system that scales better with respect to number of developers. This is just my perception of the PHPLIB situation though. > The model for PEAR, CPAN, IMHO, is far from being the most appropriate > means of PERL component distribution. Most components require some > specific version of other components which is sometimes troublesome to > get a working set together. PEAR doesn't try to be an even remotely appropriate means of Perl component distribution. ;-) > IMO, what we need is a single framework to tie components together. I > do know that such a framework will become aged in a few years (if not > months) but this is the way we use class libraries to deliver working > code: > I guess much people use either (1) entire frameworks > to use when developing PHP applications or (2) collect > some PHP codes, build their own frameworks prior to > application programming and develop applications > afterwards. > > I know that some people will not like even the "best" framework but is > there a chance to make everyone happy? > > I'm eagerly waiting for your comments. The scope of PEAR goes beyond application frameworks. One of the problems with application frameworks is that they usually provide "all or nothing". The most recent site I built with PHP (alltheweb.com) uses a few PEAR components, but the rest is in-house code. If PEAR was an application framework, we would not afford to use it (speed is king). That being said, I don't have any problems with the concept of application frameworks within PEAR in general. But there is no such thing as "the best framework", it all depends on what you need. - Stig