[Zope-CMF] Re: Genericsetup design rules

yuppie y.2007- at wcm-solutions.de
Mon Mar 5 07:42:38 EST 2007


Hi Reinout!


Disclaimer: I believe that the current way extension profiles are 
implemented has some fundamental issues, see:
http://mail.zope.org/pipermail/zope-cmf/2006-July/024665.html

Reinout van Rees wrote:
> Is there a generally accepted rule for what generic setup (or a GS
> profile, please pardon some possibly shaky terminology)

The terminology is important here, because it helps you to understand 
the responsibilities:

- GenericSetup is in the first place a tool. For the tool most files in 
a profile are just data without any meaning.

- Profiles are just data, they don't do anything unless interpreted by a 
setup handler.

- Setup handlers (and adapters) implement the behavior of import steps 
and export steps. This is where directives like 'insert-before' are 
implemented. GenericSetup ships with some handlers for generic Zope 
objects. But most setup handlers ship with the products that implement 
the corresponding objects.

> is supposed to
> do in case you have an existing list of things? As an example, take
> the skins.xml. That's one of the better ones. You have "add-before"
> and "add-after" or however they're called to position an *extra* skin
> in just the right spot. But I don't believe you've got a "zap
> everything, this is the new list" option.
> 
> There are some other profiles where you don't even have the option of
> add-before or add-after. And purge=YESPLEASE also doesn't work in
> quite a lot of cases (sometimes even giving parse errors). That
> regularly makes me want to revert to doing such things in custom .py
> files again instead of doing it nice and tidy
> with genericsetup.
> 
> So:
> 
> * Is there some generic guideline for what a genericsetup profile, in
> general, should implement?

Are you aware of this file?

http://svn.zope.org/GenericSetup/trunk/doc/profiles.txt?rev=68512&view=auto

It describes some generally useful update directives. But that doesn't 
mean all handlers have to implement them.

> * Some of those missing addBefore=.. things strike me as pretty
> essential, is that something I could file bugs for or is it perhaps
> intentional (as there is a better way to handle it)?

I would categorize that as feature request, not bug report. The handlers 
are not broken if they don't implement these directives, but they are 
missing a useful feature.

For many objects there are still no setup handlers at all, so people 
might have other priorities. Implementing update directives in every 
handler is a lot of work, so in the long run it might make more sense to 
make them obsolete by more fundamental changes.


Cheers,

	Yuppie



More information about the Zope-CMF mailing list