[Zope-CMF] Re: GS catalog support

[Rob Miller]

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?

-r