[Zope3-dev] Course-grained reuse.

[Jim Fulton]

Martijn Faassen wrote:
...
> One form of abstraction I'm still grasping for in Zope 3 is support for 
> coarse-grained components. When I have a whole bunch of (local) 
> utilities, content objects, views, permissions and the like that work 
> together, tied together with quite a bit of ZCML, I'd like to be able to 
> reuse that more easily in an application. Right now the only way to 
> reuse code like that I can find is to copy it and modify it, but that's 
> wrong -

Right.

 > it'd like to be able to use all that code from my application
> without having to copy or modify it.
 >
> For instance, for an application I needed a user and group management 
> system with a ZODB user interface. This uses the catalog, defines a 
> number of content objects and adds a bunch of views. Extracting this 
> functionality from the application turned out harder than I'd like it to 
> be. And then I haven't figured out yet how to reuse it without having to 
> copy and modify code...
> 
> Are there patterns to do this in current Zope 3? Part of the problem is 
> a dependency on local utilities - I believe the new local utility 
> registration API you're working on should help there. For the rest, I 
> guess I could just copy and rewire the ZCML, but that is quite a bit of 
> work and failure-prone. I could also invent a ZCML statement with a much 
> higher level of abstraction that takes the place of dozens of lower 
> level statements, but people argue against this rather a lot. What other 
> strategies could I employ?

It's hard to comment without knowing the specifics.  We do this sort of thing
by registering the thing we want to reuse and then overriding bits as needed.

I suspect that there are lots of little problems confounding you, including:

- lack of worked out patterns in Zope 3

- lack of knowledge on your part

- perhaps poor factoring in the things you are trying to reuse that makes your
   job more difficult.

<shrug>

I'll observe some open issues that I'm aware of:

- You can't override subscriber registrations

- We don't have a good way for installing collections of local
   components that work together.  For our projects, we've
   used the generation machinery to automate this, but that only
   works if you want to install things in the root folder.

   I don't think high-level ZCML is the answer.

It's possible that the new registration machinery will help
(if I every find time to finish it).  For example, perhaps
you could define an "assembly in a ZCML file and use that assembly as
a base for one or more sites.  Then you still need a way of dealing
with persistent data.  One thought I've had is that open connections should
get registered as utilities and unregistered when they are closed.
Then components registered globally could still get at databases
within the context of a request at run time.

I agree need some model for course-grained assemblies of components.

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