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
> 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.
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 Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list