Re: Considering package proposal: Cgiapp

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. 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.

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

For the databases the reason is that back then we didnt have such a clear "no redundant policy" and also the development time and ressources needed to create a new version of such package like MDB are simply very long and so are the migration periods. So that makes them kinda special. Template engines are a mess. Now for RDF it gets interesting. We have multiple parser because they do things differently. We have full fledged RDF parser and simple RSS parsers. 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. However applications in PEAR is slowly picking up and for now I see them mostly in the area of tools (like schema, package.xml, documentation generation), rather than enduser applications (news, shop etc). regards, Lukas