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 case. 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 needed that.. 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. -Ethan great input from this list as always. =) > > iain > > 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 >>> and >>> >> 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@lists.repoze.org >> http://lists.repoze.org/listinfo/repoze-dev >> >> > > _______________________________________________ > Repoze-dev mailing list > Repoze-dev@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev > >
_______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
