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

Martijn Faassen faassen at infrae.com
Thu Mar 16 06:20:17 EST 2006


Jeff Shell wrote:
> On 3/15/06, Martijn Faassen <faassen at infrae.com> wrote:
> 
>>Jim Fulton wrote:
>>
>>>- 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:
> 
> 
> I think I understand what you're saying. I run this pattern a lot
> myself. To date, I've used the event handler approach to catch when my
> site is added. But also, to date, I've stuffed a lot of the setup code
> into a single function called by the event handler.
> 
> I don't think there's anything wrong with "custom Python" code to set
> this up. It's programmatic, isn't it? A lot of it may be repetitive,
> and if that's the case, functions/methods can help. Are we all just so
> used to writing big long blocks of code in Zope 2 Python Scripts that
> we've forgotten we can do this?

Writing Python code for setup is very handy, but we've also seen where 
it went wrong in Zope 2. Writing Python code for setup therefore worries 
me. What's the Zope 3 idea on this? It used to be simple: we had ZCML 
for such things. But when I started using Zope 3 ZCML turned out to be 
insufficient from the start for this activity, so I used Python code 
(with an event hooked up to the site add event, too). And now, ZCML is 
not going to be used for some of this anymore, so I become less certain.

Where I think "just using Python code" starts going wrong (potentially) 
is when I want to combine my setup Python code with your setup Python 
code to build a larger application.

I'd like there to be common patterns so there's at least a reasonable 
chance that you can plug my TTW UI for user management into your 
application without having to rewrite large parts of either. I'd also 
like this pattern to be there when I'm *writing* my larger application, 
so I say, 'okay, this is all for TTW user management' then, and then 
more easily extract it later.

> I'm trying to abstract some common Bottlerocket patterns out into new
> base framework/library for my company to use, and this is actually one
> of them. I was trying to come up with something last night for just
> this issue. Basically, I thought of writing a couple of interfaces
> that would do something *like* zope.app.generations, but instead of
> being a 'database opened' event response, used to automatically patch
> persistent data with the expectations of code, these things would work
> on a 'site added' event. What I didn't spend any time thinking about
> was whether to have future upgrades go through this tool, or through
> generations.

This may be in the direction of a solution. I haven't studied 
generations in detail, myself. Anyway, any such solution needs to be in 
the common codebase, otherwise we're going to end up with a lot of 
custom ones.

[snip design ideas]

> * Using an adapter to bind the configurator to the site allows the
>   'framework' to handle when and how the configuration gets run for
>   a particular site / added object, but doesn't worry about what it
>   does.
> * Use the wonders of object oriented technology to provide a base
>   class with helpful methods for the common configuration chores.
> * Use this same wonder to allow common sites to share common tasks
>   for establishing local utilities.
> * Still have the power to be as programmatic as needed, which can
>   ensure that the utilities are established in a proper order and
>   deal with specific situations regarding their establishment. Or
>   just to handle dealing with very repetitive situations in an
>   easier fashion.

I think ordering may become important eventually. I.e. I can only 
install my Foo thing into a site if Baz is already installed. I'd think 
I'd like to be able to express such ordering in some declarative way.

> Maybe something like that is what Jim's talking about in regards to assemblies?
> 
> ZCML really can't handle this. Not unless the ZCML in question was
> basically a pointer to a callable object, at which point you've got an
> event handler all over again. I'm looking at my code to set up the
> authentication utility for some of our sites. Very specific rules
> about what plugins are needed (users, groups, http credentials) and
> things in those plugins (default groups). There's no way I'd want to
> automate that in anything BUT Python. (Plus, in its current form, this
> code can also be used by a view that responds to there being no auth
> system setup).

I agree that just using ZCML obviously won't cut it. But perhaps some 
ZCML can at least help organizing the whole (pointing to the Python code 
to do the complicated stuff for each bit).

Regards,

Martijn



More information about the Zope3-dev mailing list