Re: Considering package proposal: Cgiapp

On Apr 11, 2005 3:20 AM, Lukas Smith <lsmith@php.net> wrote: > Matthew Weier O'Phinney wrote: > > 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. > > Such a place would need to be sourceforge or whatever site you prefer. > There could even be a pear frameworks site. I am for example releasing > my PEAR based framework on my own site soon. Which is precisely where I currently have Cgiapp (after having self-hosted for a year). > Also the main reason why we dont have frameworks in PEAR is that we > simply decided to stay at a certain level, which is the library. We > leave the glue code to our users. We do allow applications that are more > or less self-contained. Maybe we as see more and more applications > making it into PEAR we will have to reconsider our framework policy in > order to prevent needless code duplication. This makes absolute sense; thanks for this explanation, Lukas. My own use of PEAR is exactly as you describe: glue code, to get things done. Well, that and error handling! > > 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 <snip> > The idea here is that if the approach is suffciently different its not > considered redundant: like Cache and Cache_Lite where one is faster yet less > feature rich. Or even IT[X] vs. Flexy vs. Xipe (so our template engines dont > overlap all that much). However things like IT[X] and sigma are needless > overlap. > > > Could somebody succinctly (and authoritatively) explain why PEAR "isn't a > > place for framework[s]"? > > As you can see. Currently we dont want frameworks because this is a > layer we dont want to be involved with. However I do see that maybe down > the road we might need 2-3 frameworks in order to better handle > applications in PEAR. There's a part of me that would like to say, "What's the problem with having a Frameworks category? If there's more than one framework available, and they're sufficiently different, then it fits the criteria you've outlined." However, I also see what others have pointed out in this thread: you then get a bunch of questions to the lists about, "which is better?" Which ends up in flame wars, bruised egos, and time wasted from PEAR development. It *would* be nice to see an area on PEAR for listing alternate channels and PEAR-based applications/frameworks/what-have-you, particularly if code linked there were reviewed (somewhat) by PEAR developers. Thank you everybody for your responses! -- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/