[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