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,
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
