Question

I’m developing a product for Plone, say foo.core. Besides that core product, there are also several related products. like foo.optional. These releated products may be available in the instance and if they are available they may be installed (in other words: I cannot assume the code is available or, if it is, should be used).

These related products may override settings made by foo.core (e.g. in a Property Sheet). This works fine, but if I reinstall foo.core, the default settings are back. What I’d want is to somehow automatically reinstall foo.optional when foo.core is reinstalled in the QuickInstaller.

The solutions I could come up with are:

• When foo.optional is installed, it
  registers itself with foo.core. The
  latter, foo.core, will handle the
  reinstallation of all registered
  products when the core package is
  reinstalled.
• The foo.core package
  triggers an event which other
  packages, like foo.optional, can
  listen for. An event handler will
  then trigger the reinstall of
  foo.optional.
• Make sure that foo.core
  doesn’t overwrite any settings that
  may have been customized later by
  other products.

Perhaps there are more alternatives? What would be the ‘Plonish’ approach?

Edit: I know that using upgrade steps might be better than reinstalling the product. However IMHO the problem remains the same: the Generic Setup profile used for the upgrade step might have a setting that is modified in the Generic Setup profile for the foo.optional package.

So using upgrade steps makes my problem even harder: how should I determine whether the upgrade step of foo.core means foo.optional should be reinstalled/upgraded? (The assumption is still that foo.core in principle does not know about foo.optional.)

Answer 1

The solution to your problem is much easier than what you propose:

We do NOT reinstall products like we did in the past when the product is updated. Reinstalling a product will cause your generic setup profile to be reapplied which is why you get your settings overwritten.

Instead you now provide upgrade steps. For instance if you change your profile version from 2 to 3 then you would have:

<genericsetup:upgradeStep
  title="Upgrade foo.core from revision 2 to 3"
  description="Adds stuff"
  source="2"
  destination="3"
  handler="foo.core.upgrades.two_to_three.addStuff"
  sortkey="1"
  profile="foo.core:default"
  />

Inside the upgrade step you can do what you like, even re-run individual import steps.

If your product upgrade does not involve changing the GS profile, do not increment the version in metadata.xml. In that case you obviously don’t need an upgrade step either.