[Zope-CMF] Re: GS catalog support

[Georges Racinet]

Le 11 mai 2006, à 00:36, Rob Miller a écrit :

> yuppie wrote:
>> Tres Seaver wrote:
>>> Wichert Akkerman wrote:
>>>> It seems GS doesn't have its own list so I'm posting this here - 
>>>> all the
>>>> relevant people are here anyway :)
>>>>
>>>> I'm working on GenericSetup support for a number of packages from 
>>>> the
>>>> Plone 2.5 bundle but I'm running into a bit of a limitation in GS: 
>>>> the
>>>> current catalog export/import routines always use the same single
>>>> catalog; support for multiple catalogs is missing.
>>>>
>>>> Looking at the code it shouldn't be too hard to write something that
>>>> handles multiple catalogs, but that would mean either creating a new
>>>> import/export-step with a new XML file or breaking the format for 
>>>> the
>>>> current catalog.xml.
>>>> I'm not sure what the best approach is at the moment; any opinions?
>>>
>>> I would create one XML file per catalog, using the current format, 
>>> and
>> Agreed.
>>> modify the export / import step to create / look for a 'catalogs.xml'
>>> file which somehow points to the locations of the catalog(s) within 
>>> the
>>> site, an maps them to the separate XML files.  The import step would
>>> need to provide BBB for profiles which did not create this new file,
>>> defaulting to a mapping from 'catalog.xml' -> 'portal_catalog'.
>> I would do that in a different way.
>> I still believe a refactoring as proposed here would be an 
>> improvement, it would also resolve the multiple catalogs issue:
>> http://mail.zope.org/pipermail/zope-cmf/2005-November/023331.html
>
> i'm not so fond of this idea, actually.  while i'm all for simplifying 
> things, i'm loathe to give up the flexibility that you admit we'll be 
> sacrificing. GenericSetup is likely to be used in a myriad of ways, 
> just because we can manage to get CMF itself to work with a less 
> flexible GenericSetup doesn't mean that other use cases won't need it. 
>  i'm especially concerned about losing the ability to have one tool's 
> import step depend on another's.
>
> i'm all for reducing boilerplate, though; i 100% agree that there's 
> too much of it currently.  can you imagine a way to reduce the 
> boilerplate without sacrificing the flexibility?

Hi, sorry to be late to this party, I didn't notice this proposal, but 
maybe was it simply because I didn't use GS at all at this time... I'll 
take the opportunity to mention that the two flexibility features you 
mention are quite important to me.

When developing with GS I rerun just one step all the time, be it for 
quickness or because I may be fixing a small dent while working on a 
bigger thing at the same time. It's also interesting when you want, 
say, to update a broken workflow on the fly without changing 
site-dependent parameters, like LDAP connections and such.

As for dependencies, it's true that the one mentionned is a bit 
artificial, but there are more serious ones outside of the CMF. One 
really needs to have portal_types set to initialize an object built on 
a FTI, for instance. This is of course much more serious.

Finally, having the tools being exported under their true id breaks 
snapshots (although I'm not 100% sure if they are a feature of the GS 
tool itself), because of the UniqueObject inheritance, but that could 
be easily solved.

Disclaimer: I'm familiar with the use of GS made within CPS.

Cheers,