Re: PEAR application framework
| From: | Jackson Miller | Date: | Fri, 15 Aug 2003 02:32:41 +0000 |
| Subject: | Re: PEAR application framework | ||
| References: | 1 2 3 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-7216@lists.php.net to get a copy of this message | ||
On Thursday 14 August 2003 12:24, Ron McClain wrote:
[snip]
> I do believe that a good framework that is tightly integrated with pear
> would
> be of interest to many developers, myself included. Don't think it should
> go in pear though.. there are just too many different possibilities
> inherent
> in framework architectures, so concensus will be near impossible.
This is why PEAR can be so important. I may be mistaken but there seems to be
some kind of a push to compatible APIs for "competing" packages. It would be
limiting to some degree if it only used flexy and not smarty or IT, but that
would be the discression of the developers/maintainers of the package. If
the PEAR::Application_Framework package didn't fit your needs then you could
be free to develop the PEAR::Application_Framework_MVC package (names for
example sake only).
I am really grateful that I don't have to develop a templating system and DB
abstraction layer for every app I develop, but have the freedom to
participate in the development of if I want to. I would be very grateful if
there was an entire framework that I didn't have to develop so that I can
focus on the work of actually creating the framework. It is the reason Web
Objects and stuff like that is so popular.
Whether or not PEAR is the place for this framework to be developed, PEAR
packages are definitely the building blocks for such a framework.
-Jackson
>
> If you are interested in a solution involving
> phrame/flexy/db_dataobjects/quickforms,
> let me know.. I've got some preliminary work done, and would be happy
> to collaborate.
>
> -Ron
>
> Matthias Nothhaft wrote:
> > Ron McClain wrote:
> >> There's been some discussion of this on the mailing lists, and I
> >> believe that
> >> the consensus reached was that pear is not the place for such monolithic
> >> packages because there is not likely to be a consensus on which packages
> >> should provide the functionality, so we'd likely end up with competing
> >> packages like the templates situation. I think that pear is designed
> >> to be
> >> a set of small, reusable components that can be glued together by
> >> application
> >> developers in any way they see fit.
> >
> > I agree. Let application devs decide what packages to use - or what
> > framework to use ;-)
> >
> >> With that said, have you looked at phrame?
> >> http://phrame.sourceforge.net.
> >> I'm using phrame with flexy templates and quickforms for the views
> >> currently,
> >> and it works pretty well. There's also phpmvc (http://phpmvc.net),
> >> but I
> >> don't know much about that one except that it's modelled after Java
> >> Struts.
> >
> > Well, I think both are not really interessting for business use
> > and I think that is the use PEAR is designed for!?
> >
> > In fact I do not know any application framework being open source
> > that can be used for a business solutions without getting mad!
> >
> > If I'm wrong, please send me the link.
> >
> > But this is just my personal opinion...
> > (and that's why I'm working on an open source
> > "enterprise app framework" based partly on pear)
> >
> >
> > Regards,
> > Matthias
> >
> >> -Ron
> >>
> >> Jackson Miller wrote:
> >>> I am sure I am not the only one who is interested in there one day
> >>> being a PEAR application framework package(s). I am wondering who
> >>> else has been thinking about this and if anyone is working on such a
> >>> project.
> >>>
> >>> I would like a system that glues together the best of the best
> >>> packages of PEAR. This would include a Templating package(Smarty?
> >>> IT?), Auth package (probably LiveUser and something more simple for
> >>> sites that don't need LU), database abstraction (MDB +
> >>> MDB_Query_Tool), QuickForm, some XML stuff, SOAP, the MAIL API, etc.
> >>>
> >>> I am thinking that the glue that could pull this together would be a
> >>> base module class that provides a consistent API for having pages
> >>> interact with the packages listed above. There may even be a good
> >>> way to have dependencies and some sort loadable module support.
> >>>
> >>> I understand that what I am describing is similar to projects like
> >>> MVC.php, but there is a sense of security in PEAR and the PEAR process.
> >>>
> >>> Has anyone else been mulling this over? Has anyone began work on
> >>> such a project? Is this a stupid or immature idea?
> >>>
> >>> Thanks,
> >>> -Jackson
--
jackson miller
cold feet creative
615.321.3300 / 800.595.4401
jackson@coldfeetcreative.com
cold feet presents Emma
the world's easiest email marketing
Learn more @ http://www.myemma.com