Jim Fulton wrote:
Martijn Faassen wrote: ...
[coarse grained component reuse]
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.
I realize this. I'm grasping to describe even what I would like to be
able to do. The specific are unfortunately quite diverse and scattered
across content code, utilities, ZCML, view code, etc.
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:
I suspect so too, along with just not having a clear picture of what the
ideal solution should even look like.
- 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 think all three are true. I have enough knowledge to attempt to amend
my lack of knowledge (and experience) and the lack of factoring in my
code by, among other things, discussing this here. It's something I've
been thinking about on and off for a while now. I'm also trying to see
the patterns that would help here.
<shrug>
I'm quite keen to make progress in this myself. :)
I'll observe some open issues that I'm aware of:
- You can't override subscriber registrations
Not something that I've had to worry about yet.
- 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.
Right. So far what we've done is some setup code to:
* create utilities in the application's site object
* create indexes in the catalog we just set up.
* create some content objects that come with the application into the
site object (typically folder-like things that will contain the actual
content the user creates)
Especially for the first two cases using custom Python code feels wrong.
It'd be better if there was some framework this custom Python code could
be registered with. I'm not thinking about the registration stack stuff,
but at least some way to register "Hey, this code wants to install stuff
into a site" somewhere, so that in my application I can use that. What
it's doing is a bit like a factory, but it's different in that:
* it's not just creating a single object.
* what's created is going to be stuffed into an existing object.
I see you say something quite similar when you talk about 'assemblies'
below. That's a good word.
I don't think high-level ZCML is the answer.
I don't see a way out through ZCML yet either. As I said, I'm just
grasping for patterns.
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.
Yes, to give feedback on the pattern: I think that could be useful.
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.
Hmm, what if your utility is already local and uses the ZODB as an
integral part of itself, such as the intid service a catalog with
indexes? Would they need to be rewritten to work with this pattern?
I agree need some model for course-grained assemblies of components.
I think this would indeed be a major step in the right direction for my
troubles. I think there are other issues as well, but this is one of the
larger hurts I'm feeling. As to the other issues, I will think about
ways to articulate them better.
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
