Re: Considering package proposal: Cgiapp

On Apr 10, 2005 10:30 PM, Helgi Þormar <helgi@trance.is> wrote: > On Sun, 2005-04-10 at 22:23 -0400, Matthew Weier O'Phinney wrote: > > > The class' usefulness is primarily in providing a solid framework for > > building reusable web applications. As an example, where I work we have > > created a Cgiapp-derived superclass that handles authentication, placement > > of content in a sitewide template, configuration of sitewide content on a > > per-application level, etc.; all applications then derive from this > > superclass, which gives them a common framework. Applications can also be > > easily extended; as an example, I extended a basic image gallery class to > > create an ecards class. > > You just said it here, it's a framework and PEAR isn't a place for > framework, just look at the yawp proposal ... It will never be accepted, > at least in it's current form (Tho I'm doubtful even tho it will change > since it's essentially a framework) I was vaguely aware of some turmoil surrounding YAWP, but I wasn't sure, in the end what it was (it happened before I started monitoring pear-dev; I'm aware of it through Paul Jones' blog). Apparently, the following comment from Lukas sums it up: http://marc.theaimsgroup.com/?l=pear-dev&m=107999349524321&w=2 So, from what I can see, frameworks are not considered good fodder for PEAR, but PEAR-based frameworks are "encouraged", though there doesn't appear to be a place on the PEAR website for listing such frameworks. The primary reason that Lukas cites is that there are many ways of approaching programming, and PEAR doesn't want to necessarily endorse any given framework over another. I guess I'm a little confused, however. I see competing DB abstraction layers (DB, MDB, DB_ado), several template engines (okay, I also saw the comment that some PEAR devs feel that shouldn't have been allowed to happen), several RDF parsers/implementations (albeit some based on different APIs). Are abstract framework implementations that much different? These are really simply development patterns, and a repository for implementations of such patterns could be tremendously useful for developers. My thought is that PEAR would be ideal for this, especially with its emphasis on abstract, generalized code. Could somebody succinctly (and authoritatively) explain why PEAR "isn't a place for framework[s]"? -- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/