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 Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
