[Zope3-dev] Re: Coarse-grained reuse.

[Martijn Faassen]

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