[Zope-CMF] [dev] GenericSetup: more refactoring - a small proposal
Hi! The setup handlers for adapter based import / export are just boilerplate. I'd like to move the complete responsibility for setting up tools to importToolset / exportToolset. toolset.xml already contains all the necessary information if we use the ID of the tool for computing the file names. catalog.xml would e.g. become portal_catalog.xml. GenericSetup would need some BBB code to handle CMF 1.5 profiles. Old-style tool handlers can still have their own registry step. This would make writing and maintaining tool handlers much simpler. On the other hand we loose some flexibility: - import/export of selected tools from a bigger profile: don't think we really need that - handling import dependencies: currently the 'workflow' step depends on the 'typeinfo' step. AFAICS we can easily get rid of that dependency. Nevertheless I think the refactoring would be an improvement and if there are no objections I'll work on this change. 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: [dev] GenericSetup: more refactoring - a small proposal
yuppie wrote: The setup handlers for adapter based import / export are just boilerplate. I'd like to move the complete responsibility for setting up tools to importToolset / exportToolset. toolset.xml already contains all the necessary information if we use the ID of the tool for computing the file names. catalog.xml would e.g. become portal_catalog.xml. GenericSetup would need some BBB code to handle CMF 1.5 profiles. Old-style tool handlers can still have their own registry step. This would make writing and maintaining tool handlers much simpler. On the other hand we loose some flexibility: - import/export of selected tools from a bigger profile: don't think we really need that What do you mean by i/o of selected tools from a bigger profile ? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: [dev] GenericSetup: more refactoring - a small proposal
Florent Guillaume wrote: yuppie wrote: - import/export of selected tools from a bigger profile: don't think we really need that What do you mean by i/o of selected tools from a bigger profile ? Right now each tool has its own import step and export step. The 'Import' and 'Export' tab of the setup tool allow to select single steps and run them independently. If tools become part of the 'Required tools' step you can just select / deselect them en bloc. 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: CMF 1.5 manage_afterAdd co
The patch I propose to include is: http://mail.zope.org/pipermail/cmf-checkins/2005-November/007137.html Could some Plone folks please test that switching to CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.5 doesn't cause problems in Plone ? This patch just changes the order of base class for File and Image, and to do the CMFCatalogAware recursion it calls its base class instead of redoing it by hand. Florent Florent Guillaume wrote: To make sure that CMF 1.5.5 will play well with Five 1.2, I have to make sure that no method manage_afterAdd redoes a recursion that one of its base classes was doing, as we have to be prepared to have the base class monkey-patched to use events, and have recursion done with events. Concretely, today CMFCatalogAware.manage_afterAdd does full recursion by itself in the children. To fix that, I would have to make CMFCatalogAware.manage_afterAdd delegate to its base class to do the recursion on non-opaque objects. But CMFCatalogAware is a mixin class, so the only way I'll do what I want is by using super(). Of course as you know, if you use super() somewhere you have to use it everywhere, otherwise Bad Things happen (see http://fuhm.org/super-harmful/). So I'll have to change the users of manage_afterAdd co in CMF to use super() correctly. Because some base Zope classes don't user super (), I have to reorder some classes. Namely, File and Image classes will have to be changed so that CMFCatalogAware is before OFS.Image.File in the bases. Plus some additional details to make getId() work. Does someone have a problem with me doing that in the CMF 1.5 branch? All with tests of course. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] Dead branches
Could folks having old CMF branches clean them up ? See http://svn.zope.org/CMF/branches/ This seems to concern: ajung, andrew, chrism, chrisw, gregweb, jshell, mj, regebro, shane, sidnei, slinkp, tseaver, yuppie. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: [dev] GenericSetup: more refactoring - a small proposal
Hi Florent! Florent Guillaume wrote: yuppie wrote: - import/export of selected tools from a bigger profile: don't think we really need that Right now each tool has its own import step and export step. The 'Import' and 'Export' tab of the setup tool allow to select single steps and run them independently. If tools become part of the 'Required tools' step you can just select / deselect them en bloc. Hm I don't like it, I import/export tools individually all the time. -1 from me. What are your use cases? Adding tools and loading the settings from an existing profile? Resetting existing tools? Others? Do you import/export only single tools or big sets of tools at once? I can see use cases like that, but I'd prefer a more decentralized solution. Using the setup tool for tasks like that makes it too complex and if I want to modify a single tool I don't want to switch to the setup tool and perform many steps to get my import. Possible alternatives: - A modified tool factory could allow adding pre-configured tools in a similar way as the 'CMF Action' and '* Type Information' factories on the trunk (that allow to choose presettings from profiles). - Tools could have an import/export tab that allows to load settings from an XML file. - I've experimented a bit with configuring sites via WebDAV. I was able to reconfigure portal_catalog by uploading a modified XML file. But I'm stuck with 2 issues: 1.) tool IDs don't have an '.xml' suffix 2.) tools like portal_workflow and portal_types that are represented by a directory of XML files are hard to bootstrap via WebDAV. Would one of these features be a good alternative for your use cases? 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
