Hi, I think this is a discussion that should happen in turbogears-trunk also, this is a topic we are going to exhaust at pycon.
On Wed, Mar 18, 2009 at 10:11 AM, sevenseeker <[email protected]> wrote: > > Howdy, > First of all, see relevant discussions at: > * http://trac.turbogears.org/ticket/1655 > * http://trac.turbogears.org/ticket/2275 > > I personally see this as a terrific idea and in the long term envision > a system with drop in plugin (eggs?) repository(s) or installed > globally. I have become spoiled with Trac's architecture and ease of > extending and wish this upon TG. > At http://trac.turbogears.org/ticket/1655#comment:16 I made some light > comments regarding approaches to existing patterns (and a system) of > plugin architectures. > > I won't repeat what I typed there but basically I mentioned 4 > approaches I am familiar with: > * zope.interface - http://pypi.python.org/pypi/zope.interface/3.5.1 > * entry points (minimal exposure, but it seems robust from that > exposure) > * ABC (abstract base classes) - > http://docs.python.org/whatsnew/2.6.html#pep-3119-abstract-base-classes > * Trac like (which is zope.interface like) approach - > http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture > > Note that ABC is >= Python 2.6. > I think the 4 methods you mention are oriented to "applications" not "frameworks" so IMO they all fail mostly at the intended goal of the features. (see below) and IMO the "component arch" shouldn't be based in any of them. > Now some questions... > What exactly are the reasons/goals for wanting to implement a > component based approach? > Reusability of TG applications in other TG applications. Classic example someone writes a blog engine and I want to use it inside my TG application. Please note that the goal of both tickets is to add client code portability, the framework itself already has several "hooks" and "plugin" points, to name a flew how you can switch templates, the call_on_startup/shutdown functions, the flexible ORM, and all the different Controller classes. > Is it important to add not just implement new features that are > themselves implemented by other plugins? > under the above this question is irrelevant as in "application" land you will have more than one app that serves the same purpose. > How important is it to be backwards compatable? > very we are building 2.1 not 3.0 > Thanks, > Jason > > *** I will be at PyCon 2009 including the Sprints, so that would be a > perfect time to discuss this. Also, I am going to propose a BoF for > plugin/component based architectures. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
