Maurits van Rees, on 2007-06-23: > 2. What needs to happen on the import tab now on trunk? We want a > drop down that lists all extension profiles. When I select one of > those extension profiles, should I get a list of only those steps > for which this profile has an xml file?
This does not seem possible, unless we add more info about steps to the registry: the name of the xml file that the handler of that step will read. > Or should I just get a > list of all steps available (several dozen on Plone 3) and have the > extension profile as context when I click the correct button? I added that. I have no commit rights, so for the total changes (including the previous one for the Profiles tab), see here: http://paste.plone.org/15349 Just select your favorite extension profile, perhaps select some steps and then click the Import selected/all button. The tests still pass, but I did not add extra tests. The current manage_* methods from the setup tool are also not tested, so I do not feel very guilty. ;-) One thing that we may want to do differently: with this code it is possible to create a new Zope and Plone site, go to portal_setup, go to the Import tab *without* going to the Profiles tab first, select the eXtremeManagement extension profile (if you have that in your Products dir) and run all steps. Then all steps get run, except the importVarious step, as that has not been registered yet. Wait, that does not actually happen. The importVarious step gets run after all. Maybe it now gets registered on the fly in some part of the code. Oh well. One other thing that strikes me as odd: I added a few lines in my setuphandler like: logger.info("Migrated schema of %s", contentType) In the event log this correctly gives lines like this: INFO GenericSetup.eXtremeManagement Migrated schema of eXtremeManagement.Task But the message log on the import tab gives me lines like this: eXtremeManagement: Migrated schema of %s So the argument is lost somewhere. > As a test I added my own eXtremeManagement product in the Products > dir, which also has a GS extension profile with an importVarious > step. I registered this profile with the patch I linked to above. > Then I tried to import all steps. This meant that the > eXtremeManagement importVarious step was run, which gave problems > as it assumed some portal types to be available, which were not > there. I now fixed that by checking what the context is: > > def importVarious(context): > if 'Products/eXtremeManagement/profiles/default' \ > not in context._profile_path: > return > ... I now changed that to: if not context._profile_path.startswith(os.path.split(__file__)[0]): logger.info('Nothing to import: not in eXtremeManagement path') return I see that some other products (Plone, CMFEditions) use a different strategy: # Only run step if a flag file is present if context.readDataFile('cmfeditions_various.txt') is None: return So they add a simple text file to their profile directory and if that does not exist in the current import context, then the importVarious function quits. Works too. Any thoughts on which of the two strategies is better? Hm, I just selected my importVarious step and ran that step with its dependencies, but I did that with the base (Plone) profile. This step has three dependencies. These dependencies are imported (but with the xml files from Plone as their data) and then the importVarious step itself exits early because of the check I added: INFO GenericSetup.propertiestool Properties tool imported. INFO GenericSetup.catalog Catalog imported. INFO GenericSetup.workflow Workflow tool imported. INFO GenericSetup.eXtremeManagement Nothing to import: not in eXtremeManagement path So the dependencies are run, but then the code in the depending step realizes it does not actually need to run itself, so running the dependencies was not really needed. I understand what is happening, but it sounds a bit wrong to me. -- Maurits van Rees | http://maurits.vanrees.org/ [NL] Work | http://zestsoftware.nl/ "Do not worry about your difficulties in computers, I can assure you mine are still greater." _______________________________________________ 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