Martin Aspeli, on 2007-05-11: > I'm not sure it's desirable to hide things from portal_setup, since that > would probably have other side-effects. Maybe this is something we need > support for at the CMF level, though - different types of profiles being > listed differently in the UI.
In zcml you can register your profile as providing either Products.GenericSetup.interfaces.BASE or Products.GenericSetup.interfaces.EXTENSION It could help to have this as an option: Products.GenericSetup.interfaces.MIGRATION Then portal_setup could list this differently. > It may also be interesting to have a view (say, a control panel page?) which > could list migration profiles (categorised by product?) and allow them to be > invoked, therefore bypassing portal_setup for this purpose. With a big of > intelligence, we could also make sure that this executed sequences of > upgrade steps: alpha 1 -> alpha 2 -> beta 1 -> beta 2 -> beta 3 ... for a > particular product, from a particular start point. This sounds a lot like Zope 3 schema generations. See paragraph 19.4 in Philipp's book. Or in code: zope.app.generations. A control panel page view is defined in the browser/ directory. And that is actually what I have been experimenting with in this week on a branch of eXtremeManagement: https://svn.plone.org/svn/collective/eXtremeManagement/branches/mvr-annotations2/migrations The migration profiles part is not there yet. I started investigating that and got sidetracked into some Poi, Plone 3 and annotations issues. > Might be an interesting project. :) If it can be done in a light-weight > fashion, it'd be nice to have a single infrastructure for this that third > party products could depend on. importVarious-like steps could be used where > GS profiles weren't sufficiently flexible. Any takers? The idea I am playing with on that eXtremeManagement branch mentioned above, is to add a property sheet 'generations' to portal_properties. I add an integer property called 'eXtremeManagement' and set that to zero. In evolve1.py I want to do some migration and then set the property to one. A first install of eXtremeManagement would probably just need to apply the main GS extension profile and set portal_properties.generations.eXtremeManagement to the latest generation number. I would actually want to shield the user from this migration by simply integrating this in the installer so that it automatically gets called on a reinstall of eXtremeManagement. I would say for add-on products this makes sense. I will try to keep the eXtremeManagement specific part separated from the more generally useful part. So: I am not yet thinking about adding a control panel page for this. But it might be an option eventually. Does the general idea about using zope 3 generations for migration make sense? -- 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." _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
