suggestion for central place to import tool interfaces from (was: Re: [Framework-Team] Effects of the tools-as-utilities branch)

Andreas Zeidler az at
Fri Mar 9 11:47:15 UTC 2007

On Mar 7, 2007, at 10:57 PM, Martin Aspeli wrote:
> Hi guys,


> I believe Jens merged, and we now have some interesting side- 
> effects...

first of all i'd like to say i agree with martin that it's great this  
branch is merged so we can finally start using `getUtility()`.   
however, having started to do just this yesterday (in a project  
tomster and i are currently working on) i've noticed that a) some  
tools are still missing and b) it's kinda cumbersome to find the  
correct interface to import before using `getUtility()`, at least in  
some cases.

while a) should be relatively easy to fix (my only question in this  
regard would be if it's okay to just add missing tools to  
`componentregistry.xml` at this point?) i'd like make a suggestion  
for b):  how about importing all relevant interfaces into  
`CMFPlone.interfaces` so it'd be possible to always import all  
interfaces used to look up tools via `getUtitlity()` from there, no  
matter where they're originally from?

for example, the tool i was missing in this particular case was  
`portal_groups`.  as it turns out it wasn't registered as a utility  
yet, so i just added


to the `componentregistry.xml` of my site product for now.  what  
bothered me here was to dig through various interfaces to (hopefully)  
come up with the correct one to use.  in this case this was slightly  
confusing, since plone still registers its own groups tool in its  
`initialize()`, which is based on the one in  
`Products.GroupUserFolder.GroupsTool`, but in `toolset.xml` the one  
from `` is used, and that's also the  
one used in an instantiated plone site.  not exactly knowing the  
details of the relationship between membership and groups tools from  
cmf, plone, groupuserfolder and plonepas this was rather confusing,  
like i said.

so what do you think about having a central place to import those  
tool interfaces from so developers can avoid having to go read a lot  
of code to find the right one?  maybe a dedicated place like  
`` would be better than cluttering  
`CMFPlone.interfaces` itself, but imho this would be a great  



zeidler it consulting - - info at
friedelstraße 31 - 12047 berlin - telefon +49 30 25563779
pgp key at -
please sign the "climate wake up call" @

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the Framework-Team mailing list