Re: Re: new template engine

From: Date: Tue, 24 Jul 2001 13:38:42 +0000
Subject: Re: Re: new template engine
References: 1 2 3 4  Groups: php.pear.dev php.pear.general 
Request: Send a blank email to pear-dev+get-1023@lists.php.net to get a copy of this message
"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. 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. 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. thank you, -bd

« previous php.pear.dev (#1023) next »