Maurits van Rees wrote:
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:

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

all of the steps for a profile will be loaded into the setup tool the first time you run any of the steps for that profile. what's missing is the option of loading all of the steps from a profile WITHOUT actually running them, so that you could run only the importVarious from your profile before running any of the other ones. i imagine a 'load import steps' button on the profile page, next to the 'import' button.

One other thing that strikes me as odd: I added a few lines in my
setuphandler like:"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:

I now changed that to:

    if not context._profile_path.startswith(os.path.split(__file__)[0]):'Nothing to import: not in eXtremeManagement path')

I see that some other products (Plone, CMFEditions) use a different

    # Only run step if a flag file is present
    if context.readDataFile('cmfeditions_various.txt') is None:

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?

i like the file check, myself. my second choice would be checking the active profile by profile id. the path check you're using would be my third choice. but it's better than nothing.

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 

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.

i agree that it's awkward, but it is actually the right behaviour.
ideally the profile check would happen before the dependencies are run.


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to