[Web-SIG] repoze.bfg web framework 1.0 released

[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