repoze.bfg web framework 1.0 released

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

repoze.bfg web framework 1.0 released

Chris McDonough
Summary
-------

The first major release of the BFG web framework (aka "repoze.bfg"),
version 1.0, is available.  See http://bfg.repoze.org/ for general
information about repoze.bfg.

Details
-------

BFG is a Python web framework based on WSGI.  It is inspired by Zope,
Pylons, and Django.  It makes use of a number of Zope technologies
under the hood.

BFG is developed as part of the more general Repoze project
(http://repoze.org).  It is released under the BSD-like license
available from http://repoze.org/license.html .

BFG version 1.0 represents one year of development effort.  The first
release of BFG, version 0.1, was made in July of 2008.  Since then,
roughly 80 pre-1.0 releases have been made.  None of these pre-1.0
releases explicitly promised any backwards compatibility with any
earlier release.

Version 1.0, however, marks the first point at which the repoze.bfg
API has been "frozen".  Future releases in the 1.X line guarantee
API-level backward compatibility with 1.0.  A backwards
incompatibility with 1.0 at the API level in any future 1.X version
will be considered a bug.

More Details
------------

BFG contains moderate, incremental improvements to patterns found in
earlier-generation web frameworks.  It tries to make real-world web
application development and deployment more fun, more predictable, and
more productive.  To this end, BFG has the the following features:

- WSGI-based deployment: PasteDeploy and mod_wsgi compatible.

- Runs under Python 2.4, 2.5, and 2.6.

- Runs on UNIX, Windows, and Google App Engine.

- Full documentation coverage: no feature or API is undocumented.

- A comprehensive set of unit tests.  The repoze.bfg package contains
   11K lines of Python code.  8000 lines of that total line count is
   unit test code that tests the remaining 3000 lines.

- Sparse resource utilization: BFG has a small memory footprint and
   doesn't waste any CPU cycles.

- Doesn't have an unreasonable set of dependencies: "easy_install"
   -ing repoze.bfg over broadband takes less than a minute.

- Quick startup: a typical BFG application starts up in about a
   second.

- Offers extremely fast XML/HTML and text templating via Chameleon
   (http://chameleon.repoze.org/).

- Persistence-agnostic: use SQLAlchemy, "raw" SQL, ZODB, CouchDB,
   filesystem files, LDAP, or anything else which suits a particular
   application's needs.

- Provides a variety of starter project templates.  Each template
   makes it possible to quickly start developing a BFG application
   using a particular application stack.

- Offers URL-to-code mapping like Django or Pylons' *URL routing* or
   like Zope's *graph traversal*, or allows a combination of both
   routing and traversal.  This helps make it feel familiar to both
   Zope and Pylons developers.

- Offers debugging modes for common development error conditions (for
   example, when a view cannot be found, or when authorization is being
   inappropriately granted or denied).

- Allows developers to organize their code however they see fit; the
   framework is not opinionated about code structure.

- Allows developers to write code that is easily unit-testable.
   Avoids using thread local data structures which hamper testability.
   Provides helper APIs which make it easy to mock framework components
   such as templates and views.

- Provides an optional declarative context-sensitive authorization
   system.  This system prevents or allows the execution of code based
   on a comparison of credentials possessed by the requestor against
   ACL information stored by a BFG application.

- Behavior of an an application built using BFG can be extended or
   overridden arbitrarily by a third-party developer without any
   modification to the original application's source code.  This makes
   BFG a good choice for building frameworks and other "extensible
   applications".

- Zope and Plone developers will be comfortable with the terminology
   and concepts used by BFG; they are almost all Zope-derived.

Excruciating Details
--------------------

Quick installation:

   easy_install -i http://dist.repoze.org/bfg/current repoze.bfg

General support and information:

   http://bfg.repoze.org

Tutorials

   http://docs.repoze.org/bfg/current/#tutorials

Sample Applications

   http://docs.repoze.org/bfg/current/#sample-applications

Detailed narrative and API documentation:

   http://docs.repoze.org/bfg/current

Bug tracker:

   http://bfg.repoze.org/trac

Maillist:

   http://lists.repoze.org/listinfo/repoze-dev

IRC support:

   irc://irc.freenode.net#repoze

repoze.bfg is developed primarily by Agendaless Consulting
(http://agendaless.com) and a team of contributors.

Special thanks to these people, without whom this release would not
have been possible:

Malthe Borch, Carlos de la Guardia, Chris Rossi, Shane Hathaway, Tom
Moroz, Yalan Teng, Jason Lantz, Todd Koym, Jessica Geist, Hanno
Schlichting, Reed O'Brien, Sebastien Douche, Ian Bicking, Jim Fulton,
Martijn Faassen, Ben Bangert, Fernando Correa Neto, YoungKing, Rob
Miller, Wichert Akkermann, David Pratt, Mark Ramm, and Chris Perkins.
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: repoze.bfg web framework 1.0 released

Graham Dumpleton-2
> The first major release of the BFG web framework (aka "repoze.bfg"),
> version 1.0, is available.  See http://bfg.repoze.org/ for general
> information about repoze.bfg.
>
> ...
>
> - WSGI-based deployment: PasteDeploy and mod_wsgi compatible.
>
> ...
>
> - A comprehensive set of unit tests.  The repoze.bfg package contains
>  11K lines of Python code.  8000 lines of that total line count is
>  unit test code that tests the remaining 3000 lines.

A question about your testing if you have time. Is this done in a fake
WSGI hosting environment, ie., test harness, or is it able to be run
through WSGI servers such as Paste server, Apache/mod_wsgi, etc, in
some way?

Am curious from the point of view that standalone test suites for WSGI
itself to run against WSGI hosting mechanisms don't really exist, so
the test suite for BFG, with the presumption that it would exercise a
lot of WSGI functionality, might be a good regression test for WSGI
servers themselves.

Graham
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: repoze.bfg web framework 1.0 released

Randy Syring
In reply to this post by Chris McDonough
Chris,

Sounds interesting.  Question: Does it support some
kind of module/plugin architecture that will allow me to develop "plug-
in" functionality across projects?  What would be called in
Django an "app".

For example, I would like to have a "news", "blog", and "calendar"
module that I can plug into different applications.  The goal is to
have everything for the module contained in one subdirectory or package including
any configuration, routing, templates, controllers, model, etc.  So,
something like this:

/modules/news/...
/modules/calendar/...
/modules/blog/...

Or:

packages/
   MyProj
   NewsComponent
   CalendarComponent
   BlogComponent

I ended up writing my own framework because I needed this and didn't want to go with Django and Pylons didn't support it:

http://groups.google.com/group/pylons-discuss/browse_thread/thread/14aef22ddb90347f

But would love to be able to use something else that was more of a community effort.

Thanks.
--
--------------------------------------
Randy Syring
RCS Computers & Web Solutions
502-644-4776
http://www.rcs-comp.com

"Whether, then, you eat or drink or whatever you do, do all to the glory of God." 1 Cor 10:31


On Sun, Jul 5, 2009 at 8:47 PM, Chris McDonough <[hidden email]> wrote:
Summary
-------

The first major release of the BFG web framework (aka "repoze.bfg"),
version 1.0, is available.  See http://bfg.repoze.org/ for general
information about repoze.bfg.

Details
-------

BFG is a Python web framework based on WSGI.  It is inspired by Zope,
Pylons, and Django.  It makes use of a number of Zope technologies
under the hood.

BFG is developed as part of the more general Repoze project
(http://repoze.org).  It is released under the BSD-like license
available from http://repoze.org/license.html .

BFG version 1.0 represents one year of development effort.  The first
release of BFG, version 0.1, was made in July of 2008.  Since then,
roughly 80 pre-1.0 releases have been made.  None of these pre-1.0
releases explicitly promised any backwards compatibility with any
earlier release.

Version 1.0, however, marks the first point at which the repoze.bfg
API has been "frozen".  Future releases in the 1.X line guarantee
API-level backward compatibility with 1.0.  A backwards
incompatibility with 1.0 at the API level in any future 1.X version
will be considered a bug.

More Details
------------

BFG contains moderate, incremental improvements to patterns found in
earlier-generation web frameworks.  It tries to make real-world web
application development and deployment more fun, more predictable, and
more productive.  To this end, BFG has the the following features:

- WSGI-based deployment: PasteDeploy and mod_wsgi compatible.

- Runs under Python 2.4, 2.5, and 2.6.

- Runs on UNIX, Windows, and Google App Engine.

- Full documentation coverage: no feature or API is undocumented.

- A comprehensive set of unit tests.  The repoze.bfg package contains
 11K lines of Python code.  8000 lines of that total line count is
 unit test code that tests the remaining 3000 lines.

- Sparse resource utilization: BFG has a small memory footprint and
 doesn't waste any CPU cycles.

- Doesn't have an unreasonable set of dependencies: "easy_install"
 -ing repoze.bfg over broadband takes less than a minute.

- Quick startup: a typical BFG application starts up in about a
 second.

- Offers extremely fast XML/HTML and text templating via Chameleon
 (http://chameleon.repoze.org/).

- Persistence-agnostic: use SQLAlchemy, "raw" SQL, ZODB, CouchDB,
 filesystem files, LDAP, or anything else which suits a particular
 application's needs.

- Provides a variety of starter project templates.  Each template
 makes it possible to quickly start developing a BFG application
 using a particular application stack.

- Offers URL-to-code mapping like Django or Pylons' *URL routing* or
 like Zope's *graph traversal*, or allows a combination of both
 routing and traversal.  This helps make it feel familiar to both
 Zope and Pylons developers.

- Offers debugging modes for common development error conditions (for
 example, when a view cannot be found, or when authorization is being
 inappropriately granted or denied).

- Allows developers to organize their code however they see fit; the
 framework is not opinionated about code structure.

- Allows developers to write code that is easily unit-testable.
 Avoids using thread local data structures which hamper testability.
 Provides helper APIs which make it easy to mock framework components
 such as templates and views.

- Provides an optional declarative context-sensitive authorization
 system.  This system prevents or allows the execution of code based
 on a comparison of credentials possessed by the requestor against
 ACL information stored by a BFG application.

- Behavior of an an application built using BFG can be extended or
 overridden arbitrarily by a third-party developer without any
 modification to the original application's source code.  This makes
 BFG a good choice for building frameworks and other "extensible
 applications".

- Zope and Plone developers will be comfortable with the terminology
 and concepts used by BFG; they are almost all Zope-derived.

Excruciating Details
--------------------

Quick installation:

 easy_install -i http://dist.repoze.org/bfg/current repoze.bfg

General support and information:

 http://bfg.repoze.org

Tutorials

 http://docs.repoze.org/bfg/current/#tutorials

Sample Applications

 http://docs.repoze.org/bfg/current/#sample-applications

Detailed narrative and API documentation:

 http://docs.repoze.org/bfg/current

Bug tracker:

 http://bfg.repoze.org/trac

Maillist:

 http://lists.repoze.org/listinfo/repoze-dev

IRC support:

 irc://irc.freenode.net#repoze

repoze.bfg is developed primarily by Agendaless Consulting
(http://agendaless.com) and a team of contributors.

Special thanks to these people, without whom this release would not
have been possible:

Malthe Borch, Carlos de la Guardia, Chris Rossi, Shane Hathaway, Tom
Moroz, Yalan Teng, Jason Lantz, Todd Koym, Jessica Geist, Hanno
Schlichting, Reed O'Brien, Sebastien Douche, Ian Bicking, Jim Fulton,
Martijn Faassen, Ben Bangert, Fernando Correa Neto, YoungKing, Rob
Miller, Wichert Akkermann, David Pratt, Mark Ramm, and Chris Perkins.
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/randy%40rcs-comp.com


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: repoze.bfg web framework 1.0 released

Graham Dumpleton-2
2009/7/6 Randy Syring <[hidden email]>:
> Chris,
>
> Sounds interesting.  Question: Does it support some
> kind of module/plugin architecture that will allow me to develop "plug-
> in" functionality across projects?  What would be called in
> Django an "app".

The documentation says:

"""
Like Zope, but unlike Pylons applications or most Django applications,
when you build a repoze.bfg application, if you obey certain
constraints, the application you produce can be reused, modified,
re-integrated, or extended by third-party developers without
modification to the original application itself. See Extending An
Existing repoze.bfg Application for more information about extending
or modifying an existing repoze.bfg application.
"""

http://docs.repoze.org/bfg/current/narr/introduction.html#differences-from-other-frameworks
http://docs.repoze.org/bfg/current/narr/extending.html#extending-chapter

Graham

> For example, I would like to have a "news", "blog", and "calendar"
> module that I can plug into different applications.  The goal is to
> have everything for the module contained in one subdirectory or package
> including
> any configuration, routing, templates, controllers, model, etc.  So,
> something like this:
>
> /modules/news/...
> /modules/calendar/...
> /modules/blog/...
>
> Or:
>
> packages/
>    MyProj
>    NewsComponent
>    CalendarComponent
>    BlogComponent
>
> I ended up writing my own framework because I needed this and didn't want to
> go with Django and Pylons didn't support it:
>
> http://groups.google.com/group/pylons-discuss/browse_thread/thread/14aef22ddb90347f
>
> But would love to be able to use something else that was more of a community
> effort.
>
> Thanks.
> --
> --------------------------------------
> Randy Syring
> RCS Computers & Web Solutions
> 502-644-4776
> http://www.rcs-comp.com
>
> "Whether, then, you eat or drink or whatever you do, do all to the glory of
> God." 1 Cor 10:31
>
>
> On Sun, Jul 5, 2009 at 8:47 PM, Chris McDonough <[hidden email]> wrote:
>>
>> Summary
>> -------
>>
>> The first major release of the BFG web framework (aka "repoze.bfg"),
>> version 1.0, is available.  See http://bfg.repoze.org/ for general
>> information about repoze.bfg.
>>
>> Details
>> -------
>>
>> BFG is a Python web framework based on WSGI.  It is inspired by Zope,
>> Pylons, and Django.  It makes use of a number of Zope technologies
>> under the hood.
>>
>> BFG is developed as part of the more general Repoze project
>> (http://repoze.org).  It is released under the BSD-like license
>> available from http://repoze.org/license.html .
>>
>> BFG version 1.0 represents one year of development effort.  The first
>> release of BFG, version 0.1, was made in July of 2008.  Since then,
>> roughly 80 pre-1.0 releases have been made.  None of these pre-1.0
>> releases explicitly promised any backwards compatibility with any
>> earlier release.
>>
>> Version 1.0, however, marks the first point at which the repoze.bfg
>> API has been "frozen".  Future releases in the 1.X line guarantee
>> API-level backward compatibility with 1.0.  A backwards
>> incompatibility with 1.0 at the API level in any future 1.X version
>> will be considered a bug.
>>
>> More Details
>> ------------
>>
>> BFG contains moderate, incremental improvements to patterns found in
>> earlier-generation web frameworks.  It tries to make real-world web
>> application development and deployment more fun, more predictable, and
>> more productive.  To this end, BFG has the the following features:
>>
>> - WSGI-based deployment: PasteDeploy and mod_wsgi compatible.
>>
>> - Runs under Python 2.4, 2.5, and 2.6.
>>
>> - Runs on UNIX, Windows, and Google App Engine.
>>
>> - Full documentation coverage: no feature or API is undocumented.
>>
>> - A comprehensive set of unit tests.  The repoze.bfg package contains
>>  11K lines of Python code.  8000 lines of that total line count is
>>  unit test code that tests the remaining 3000 lines.
>>
>> - Sparse resource utilization: BFG has a small memory footprint and
>>  doesn't waste any CPU cycles.
>>
>> - Doesn't have an unreasonable set of dependencies: "easy_install"
>>  -ing repoze.bfg over broadband takes less than a minute.
>>
>> - Quick startup: a typical BFG application starts up in about a
>>  second.
>>
>> - Offers extremely fast XML/HTML and text templating via Chameleon
>>  (http://chameleon.repoze.org/).
>>
>> - Persistence-agnostic: use SQLAlchemy, "raw" SQL, ZODB, CouchDB,
>>  filesystem files, LDAP, or anything else which suits a particular
>>  application's needs.
>>
>> - Provides a variety of starter project templates.  Each template
>>  makes it possible to quickly start developing a BFG application
>>  using a particular application stack.
>>
>> - Offers URL-to-code mapping like Django or Pylons' *URL routing* or
>>  like Zope's *graph traversal*, or allows a combination of both
>>  routing and traversal.  This helps make it feel familiar to both
>>  Zope and Pylons developers.
>>
>> - Offers debugging modes for common development error conditions (for
>>  example, when a view cannot be found, or when authorization is being
>>  inappropriately granted or denied).
>>
>> - Allows developers to organize their code however they see fit; the
>>  framework is not opinionated about code structure.
>>
>> - Allows developers to write code that is easily unit-testable.
>>  Avoids using thread local data structures which hamper testability.
>>  Provides helper APIs which make it easy to mock framework components
>>  such as templates and views.
>>
>> - Provides an optional declarative context-sensitive authorization
>>  system.  This system prevents or allows the execution of code based
>>  on a comparison of credentials possessed by the requestor against
>>  ACL information stored by a BFG application.
>>
>> - Behavior of an an application built using BFG can be extended or
>>  overridden arbitrarily by a third-party developer without any
>>  modification to the original application's source code.  This makes
>>  BFG a good choice for building frameworks and other "extensible
>>  applications".
>>
>> - Zope and Plone developers will be comfortable with the terminology
>>  and concepts used by BFG; they are almost all Zope-derived.
>>
>> Excruciating Details
>> --------------------
>>
>> Quick installation:
>>
>>  easy_install -i http://dist.repoze.org/bfg/current repoze.bfg
>>
>> General support and information:
>>
>>  http://bfg.repoze.org
>>
>> Tutorials
>>
>>  http://docs.repoze.org/bfg/current/#tutorials
>>
>> Sample Applications
>>
>>  http://docs.repoze.org/bfg/current/#sample-applications
>>
>> Detailed narrative and API documentation:
>>
>>  http://docs.repoze.org/bfg/current
>>
>> Bug tracker:
>>
>>  http://bfg.repoze.org/trac
>>
>> Maillist:
>>
>>  http://lists.repoze.org/listinfo/repoze-dev
>>
>> IRC support:
>>
>>  irc://irc.freenode.net#repoze
>>
>> repoze.bfg is developed primarily by Agendaless Consulting
>> (http://agendaless.com) and a team of contributors.
>>
>> Special thanks to these people, without whom this release would not
>> have been possible:
>>
>> Malthe Borch, Carlos de la Guardia, Chris Rossi, Shane Hathaway, Tom
>> Moroz, Yalan Teng, Jason Lantz, Todd Koym, Jessica Geist, Hanno
>> Schlichting, Reed O'Brien, Sebastien Douche, Ian Bicking, Jim Fulton,
>> Martijn Faassen, Ben Bangert, Fernando Correa Neto, YoungKing, Rob
>> Miller, Wichert Akkermann, David Pratt, Mark Ramm, and Chris Perkins.
>> _______________________________________________
>> Web-SIG mailing list
>> [hidden email]
>> Web SIG: http://www.python.org/sigs/web-sig
>> Unsubscribe:
>> http://mail.python.org/mailman/options/web-sig/randy%40rcs-comp.com
>
>
> _______________________________________________
> Web-SIG mailing list
> [hidden email]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com
>
>
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: repoze.bfg web framework 1.0 released

Randy Syring

Graham Dumpleton wrote:
2009/7/6 Randy Syring [hidden email]:
  
Chris,

Sounds interesting.  Question: Does it support some
kind of module/plugin architecture that will allow me to develop "plug-
in" functionality across projects?  What would be called in
Django an "app".
    

The documentation says:

"""
Like Zope, but unlike Pylons applications or most Django applications,
when you build a repoze.bfg application, if you obey certain
constraints, the application you produce can be reused, modified,
re-integrated, or extended by third-party developers without
modification to the original application itself. See Extending An
Existing repoze.bfg Application for more information about extending
or modifying an existing repoze.bfg application.
"""

http://docs.repoze.org/bfg/current/narr/introduction.html#differences-from-other-frameworks
http://docs.repoze.org/bfg/current/narr/extending.html#extending-chapter

Graham

  
Graham,

Thanks for responding.  I read that section above, but I don't think it answers my question.  Or, maybe it does, just not the way I had hoped it would be answered.  My understanding is that you can reuse/modify/extend/etc. applications.  However, what I have in mind is not so much the integration of multiple applications as it is the integration of components into an application.  The difference being that my "blog component" doesn't have any kind of DB settings or global templates.  The configuration is minimal and only deals with things specific to the blog component (i.e. to allow coments or not).  However, the application level configuration contains DB settings, admin emails, etc. and also has global templates (i.e. the main templates that define the look and feel for the entire site).

So based on the documentation, I am certain I could extend an application if needed.  However, the real question I have is: can an application be made up of "pluggable" components that can be reused between applications?

--------------------------------------
Randy Syring
RCS Computers & Web Solutions
502-644-4776
http://www.rcs-comp.com

"Whether, then, you eat or drink or 
whatever you do, do all to the glory
of God." 1 Cor 10:31


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: repoze.bfg web framework 1.0 released

Chris McDonough
In reply to this post by Graham Dumpleton-2
On 7/5/09 10:37 PM, Graham Dumpleton wrote:

>> The first major release of the BFG web framework (aka "repoze.bfg"),
>> version 1.0, is available.  See http://bfg.repoze.org/ for general
>> information about repoze.bfg.
>>
>> ...
>>
>> - WSGI-based deployment: PasteDeploy and mod_wsgi compatible.
>>
>> ...
>>
>> - A comprehensive set of unit tests.  The repoze.bfg package contains
>>   11K lines of Python code.  8000 lines of that total line count is
>>   unit test code that tests the remaining 3000 lines.
>
> A question about your testing if you have time. Is this done in a fake
> WSGI hosting environment, ie., test harness, or is it able to be run
> through WSGI servers such as Paste server, Apache/mod_wsgi, etc, in
> some way?

The tests I mentioned in there are mostly unit tests; they don't test any
particular system configuration functionally.  In particular, none of the tests
actually invokes a request via a WSGI stack.

But we do use functional testing in projects that use the framework.  For
example, we use Twill (created by Titus Brown) to make sure things don't break
at the request/response level in this project:  http://karlproject.org.

> Am curious from the point of view that standalone test suites for WSGI
> itself to run against WSGI hosting mechanisms don't really exist, so
> the test suite for BFG, with the presumption that it would exercise a
> lot of WSGI functionality, might be a good regression test for WSGI
> servers themselves.

I think maybe some "ACID test" WSGI application could be built, and then some
set of functional HTTP-level tests could be run against that application to gain
confidence in a WSGI app.  This is more or less what we do with Twill on that
KARL project:  the developers use the Paste#http server, but we actually deploy
to a mod_wsgi server.  We can (and do) run the Twill tests against both to get
confidence that the app isn't going to fall over in production.

- C
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: repoze.bfg web framework 1.0 released

Chris McDonough
In reply to this post by Chris McDonough
On 7/5/09 11:44 PM, Randy Syring wrote:

> Chris,
>
> Sounds interesting.  Question: Does it support some
> kind of module/plugin architecture that will allow me to develop "plug-
> in" functionality across projects?  What would be called in
> Django an "app".
>
> For example, I would like to have a "news", "blog", and "calendar"
> module that I can plug into different applications.  The goal is to
> have everything for the module contained in one subdirectory or package
> including
> any configuration, routing, templates, controllers, model, etc.  So,
> something like this:
>
> /modules/news/...
> /modules/calendar/...
> /modules/blog/...
>
> Or:
>
> packages/
>     MyProj
>     NewsComponent
>     CalendarComponent
>     BlogComponent
>

I'm not sure if I can do this topic justice here (many have fallen on the sword
when approaching it before), but I'll try.

"Plugin apps" is maybe less a feature of BFG than the stuff that BFG is built on
top of.  Like Zope, BFG makes use of the Zope Component Architecture "under the
hood".  Unlike Zope, BFG tends to hide the ZCA (conceptually and API-wise) from
developers, because the ZCA introduces concepts like "adapters", "interfaces",
and "utilities".  Direct exposure to these concepts in user-visible code evokes
suspicion in people who just don't have the problems they try to solve.  The
problems that the ZCA tries to solve usually revolve around code testability and
reusability, and most people just don't care that much about these things.

So BFG is more like Pylons or Django in this respect: it provides helper APIs
and places to hang your code so that you can build a single-purpose application
reasonably easily without making you think in terms of building anything
reusable.  The final application usually happens to be overrideable and
extensible, but that's just a byproduct of using BFG, and doesn't really have
very much to do with building a system out of plugins.

In the meantime, the Zope Component Architecture is a fantastic system on which
to build a *framework* (as opposed to an application).  This is why BFG is built
on top of it.  If you are willing to use the ZCA conceptually and API-wise *in
your application code*, it becomes straightforward to build reusable
applications like you mention.

So the answer to your original question is probably no.  BFG itself isn't a
system which allows you to slot arbitrary components into place and have them
"show up" somewhere.  It's instead a system (like Zope) in which you can build
such a thing.  In fact, many of the applications that we (my company,
Agendaless) build are these kinds of applications, where we tend to want to
reuse a single application component across many "customers" or "projects".

The trick is this: when you build "pluggable applications", there's presumably
something you're going to want to plug these applications into.  I *think* this
the piece that most people are after when they talk about "pluggable
applications"; they actually don't care too much about the applications
themselves (because they'll build them themselves), it's the higher-level thing
that gets plugged into that is of primary interest.  For better or worse,
systems like Plone, Drupal, and Joomla are examples of such an application
framework.  These systems allow you to build small pieces of functionality that
drop in to some larger system.

We've done lots of Zope and Plone work, and we know the downsides of the "plug
this bit into the larger framework" pattern pretty well.  We've found that it's
useful to have the tools at hand to build miniature versions of such large
frameworks on hand, so we can quickly come up with a custom solution to some
problem without "fighting the framework" (any particular framework) so much.
BFG plus direct use of the ZCA in application code tends to let us avoid using
the larger frameworks in favor of rolling our own (more focused, simpler)
frameworks.

Unfortunately, I don't have any "simple example" application code to show with
respect to this pattern, because anything I could show here would be too trivial
to be useful.  More unfortunately, anything I can point you to that we've built
using this pattern will probably be too large to understand in any reasonable
amount of time (e.g. http://karlproject.org).

This has always been the historical problem with trying to promote use of the
ZCA for application code: until you work on a larger project that uses it
"right", it's just too abstract.  So by the time you actually need it, it's too
late and you've already invented your own mechanisms to do similar indirections.
  For those reasons, I think it would be a useful exercise to build some very
simple system that took "app plugins" and just exposed them in some very
concrete way to end users, even if it meant losing some presentation
flexibility.  Such a system could be created in any web framework, but using the
ZCA inside the web framework for such a task is a no-brainer to me.

Anyway, even this explanation is too abstract, so I'll stop it now. ;-)

- C
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com