Re: Considering package proposal: Cgiapp

On Apr 10, 2005 8:30 PM, Matthew Weier O'Phinney <mweierophinney@gmail.com> 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. > > 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. > The different template engines have generally fairly different ideas on how things work and people like them for different reasons. There is/was an effort underway to create a base template engine that the others could derive from and add to, but I'm not sure where this went. The multiple DB abstraction layers also have different ideas behind them. DB is only DB abstraction whereas MDB also does datatype and schema abstraction. MDB also has a somewhat different design style behind it (it was ported to PEAR from Manuel Lemos' metabase abstraction layer). > Could somebody succinctly (and authoritatively) explain why PEAR "isn't a place > for framework[s]"? > I'm not authoritative, but here's my take. PEAR is meant to have highly re-usable code chunks which will work in any framework or coding style. The packages are meant to be pretty abstract to allow for easy interoperability. When we start allowing frameworks we're getting into the next layer of the application. The glue between it all (YAWP). The patterns that govern an application are different than the patterns used in a simple code module. Allowing frameworks into PEAR would also implicitly mean that PEAR is pushing one framework over others. It also will bring confusion as users would be asking "which is best"? (See endless threads about DB/MDB2/template engines.) However, there's great potential and we of course love frameworks based on PEAR as they promote PEAR usage. Now, with PEAR 1.4.0, other distribution channels can easily be set up with the PEAR installer to allow for installation of, say, frameworks. pearified.com is one such channel which will hopefully soon have more packages. You could try to get your framework in there or start another channnel for frameworks. This way we can keep the simple modules in PEAR and the frameworks in another place. -- Justin Patrin