On Mon, Nov 15, 2010 at 3:20 PM, Iain Duncan <iainduncanli...@gmail.com>wrote:
> thanks guys, Ethan that sounds like exactly what I'm looking for!
> Can anyone ooint me at good examples of the combination?
Maybe not ;-)
Plone has been using z3c.autoinclude since .. 3.3 iirc, but I don't know how
many plugins are actually plugging themselves in this way. (Plone has
historically had other mechanisms for add-ons to register themselves, which
still work.) Anyway, Plone only defines a single extension point. The use
case is just automating registration/configuration of add-ons for every
package that's installed.
In my application (zope/plone based) there's a slightly more complex use
Like plone, we want to register application plugins that provide optional
features through ZCA configuration, and we want them to be automatically
enabled when the package is installed.
Meanwhile, we also want to allow for overriding certain core components.
Right now only one, the "global site configuration utility", but I can
imagine others too. (We want to allow the site configuration utility to be
overridden because different kinds of configuration mechanisms -- a single
INI file, multiple INI files, conceivably something persistent in the
database -- would make the most sense depending on how the application is
installed, and what features it's installed with.)
But, application plugins may need access to the site configuration utility
during their own registration.
So we provide two extension points. One is for registration of regular
optional features. The other is for registration of implementations of core
components. In our core ZCA registrations, we find-and-register the latter
early, and we find-and-register the former late. Packages declare which
extension point they want to plug into. A single package could conceivably
declare that it provides plugins for both extension points, but we haven't
I can point you to the code if this explanation isn't helpful .. there's a
lot of context & cruft so I don't think it would be self-explanatory though.
great input from this list as always. =)
> On Mon, Nov 15, 2010 at 7:34 AM, Ethan Jucovy <ethan.juc...@gmail.com>wrote:
>> On Mon, Nov 15, 2010 at 4:59 AM, Wichert Akkerman <wich...@wiggy.net>wrote:
>>> On 11/14/10 05:32 , Shane Hathaway wrote:
>>> > On 11/12/2010 03:17 PM, Iain Duncan wrote:
>>> >> Reading some of the diaolgue on the pylons/bfg merger has me curious
>>> >> about the following, wondering if any experts care to share opinions
>>> >> war stories:
>>> >> - what is the best use case for extending through entry points?
>>> >> - why/when would you use entry points and entires in an ini file vs
>>> >> registering modules/plugins as zca entries?
>>> >> - pros and cons of each approach?
>>> > With ZCA, you can register components temporarily for a test. You can
>>> > create a short-lived component registry. You can create multiple
>>> > registries for different parts of the application. You can store
>>> > registries in a database. Whatever makes sense.
>>> > With entry points, can you do any of that? Entry points seem far more
>>> > limiting. Please correct me if I am wrong.
>>> Entry points work without you having to configure and python, zcml, etc.
>>> code, which makes them a better fit for some tasks.
>> I think of the difference as -- ZCA is much more flexible and fine-grained
>> as a component configuration system; entry points are good for lightweight
>> tasks and for allowing a package to advertise the presence of a feature by
>> virtue of the package being installed. To me, it makes sense to think of
>> ZCA configuration as an integration layer attached to the application you're
>> putting together, and entry points as attached to packages you might reuse
>> (advertising features from the package you might want to make use of).
>> You can also combine their use: in the z3c.autoinclude system, packages
>> use entry points to advertise ZCML to be included. A package uses entry
>> points to say "I have ZCA configuration you might want, here" and a ZCA
>> configuration can say "include all the ZCA configuration for key 'foo' from
>> packages who offered it." Again, here, reusable packages advertise features
>> (in this case groupings of ZCA configuration) and in the integration layer
>> you put together a specific configuration.
>> Repoze-dev mailing list
> Repoze-dev mailing list
Repoze-dev mailing list