[Zope-CMF] Re: GS catalog support
Hi! Georges Racinet wrote: Le 11 mai 2006, à 00:36, Rob Miller a écrit : yuppie wrote: 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? Sorry. I did not mean to start that discussion again at this point. I just wanted to make sure that *if* we decide to implement that proposal the catalog support changes don't make implementing it harder. To start the discussion again the mentioned proposal is inappropriate because it doesn't reflect the discussion that already took place. The proposal is deferred because one result of the discussion was that we need a replacement for the partial imports: An import/export tab for the tools themselves. And this is not just about reducing boilerplate, it's also about moving to a more object orientated approach that makes new features like the import/export tab on object level easier to implement. 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. I'm not sure I understand your example. After the proposed change there still will be 3 setup steps: 1.) Setting up all the tools with default (empty) settings. 2.) Importing the settings for all the tools in random order. 3.) Importing dependent import steps like content import. AFAICS your example will work with that order. But I would be interested in learning about use cases that will not work with that order. 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. Yes. Snapshots are a generic GS feature. And of course we need backwards compatibility code if we change the file names. But the renaming might not be necessary. Cheers, Yuppie ___ 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
[Zope-CMF] Re: GS catalog support
Hi! 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 But there is not everything prepared for that change, so for now I'd like to see things done the old way: One import step per tool. Ideally the names of the XML files created by the export steps correspond to the IDs of the tools. For historical reasons tools starting with 'portal_' loose that part of the name. And there are still some XML files like 'workflows.xml' and 'cachingpolicymgr.xml' that have completely different names. Besides that naming issue 'importObjects' and 'exportObjects' should work out of the box for other catalogs and adding new handlers requires only a few lines of code. Cheers, Yuppie ___ 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
[Zope-CMF] Re: GS catalog support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 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'. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEYLJH+gerLs4ltQ4RArjzAKDWcJIsms/CUI4OvYp011WVBATDZwCgoQm2 mNx2FNxyX0l/OuSDSpCpN6o= =JqLp -END PGP SIGNATURE- ___ 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
