[Zope3-dev] RFC: Local Component Management Simplification

[Jim Fulton]

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>> I've posted a proposal to simplify local component management at:
>>
>>   http://dev.zope.org/Zope3/LocalComponentManagementSimplification
>>
>> Comments and questions are welcome.
> 
> 
> I like the proposal.
> 
> I'm trying to figure out what this means exactly:
> 
> """
> Registries may place restrictions on objects registered. In particular, 
> local registries stored in the ZODB will have to be able to store 
> registered objects (or references to registered objects) in the ZODB.
> """
> 
> So, this means that for a ComponentRegistry that's in the ZODB 
> (non-global),

Note that "non-global" and "stored in the ZODB" need not be correlated,
For example, a local registry need not store it's information in the ZODB.
Or, for that matter, a registry could conceivably store data in the ZODB
and in memory.  My only point is that an implementation is allowed to place
restructions on registered components not mentioend here,

 > the utility you want to register needs to be pickleable,
> or 'referenceable'. How would such a reference to a registered object 
> that's not in the ZODB work?

This is up to the implementation.

BTW, the new adapter registries have __bases__ attributes and
support multiple base registries.  The same will probably hold for
component registries (that handle both adapters and utilities).
So, one could have a local registry that stores it's data in the ZODB
and that has as one of it's bases a ZCML-defined registry that is
separate from the normal global registry.


> Related to this, I'm looking for a new (the horror!) ZCML knob which 
> would allow me to say:
> 
> For this content object (that is a site), when it's installed into the 
> ZODB (like a CMFSite or a Silva Root), please also install the following 
> local utilities (catalog, intid utility, etc).
> 
> Here's an idea that I haven't really thought through:
> 
> <localUtility
>   class=".mycatalog.Catalog"
>   name="mycatalog"
>   for=".interfaces.IMySite">
> ...
> </localUtility>
> 
> this would set up somekind of subscriber for IMySite so that whenever an 
>  object providing IMySite is added to a container, a local utility of 
> type mycatalog.Catalog would be set up in it straight away.

As mentioned by Stephan, you can simply set up a subscriber.

One issue with subscribers currently is that ZCML subscriber directives
can't be overridden.  We need a fix for this.

> The component registration interface as proposed would help some setup 
> code cleaner, but having such functionality in ZCML would clean up quite 
> a bit more registration code -- right now we have an event handler that 
> gets called when a site is added, and then calls a lot of Python code to 
> do the utility setup. It's lots of code that is really doing 
> configuration expressed as Python.

Good point.  I'm liking your proposal.  It deserves some more thought.
However, another way to do the same thing woyuld be to allow ZCML to
define multiple registries and have a way of saying that a site of a
particular kind should use an additional ZCML-defined base registry.


> (Of course in case of a catalog this sort of begs the question whether 
> setting up catalog indexes should be configurable through ZCML too...)

Yup.

BTW, I like the Plone (CMF?) mechanism in which a product can specify
an installation UI so that someone can walk up to a site TTW and elect
interactively to install a product.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org