Geek Answers Handbook

Product Descriptions: Trigger Reinstallation

I am developing a product for Plone, say foo.core . In addition to this main product, there are also several related products. like foo.optional . These released products may be available in an instance, and if available, they may be installed (in other words: I cannot assume that the code is available or, if any, should be used).

These related products may override the settings made by foo.core (for example, in the Property Sheet). This works fine, but if I reinstall foo.core , the default settings will return. I would like to somehow automatically reinstall foo.optional when foo.core reinstalled in QuickInstaller.

The solutions that I could offer are as follows:

  • When foo.optional installed, it registers with foo.core . the latter, foo.core , will handle reinstalling all registered products when the main package is reinstalled.
  • The foo.core package raises an event that packages, such as foo.optional , can listen. The event handler will then run the reinstallation of foo.optional .
  • Make sure that foo.core does not overwrite any settings that may have been changed later by other products.

Perhaps there are more alternatives? What will be the Plonish approach?

Edit: I know that using update steps may be better than reinstalling the product. However, the IMHO problem remains the same: the Generic Setup profile used for the upgrade phase may have a parameter that changes in the Generic Setup profile for the foo.optional package.

Thus, using update steps makes my task harder: how do I determine whether to reinstall / update the update phase foo.core means foo.optional ? (It is still assumed that foo.core is basically unaware of foo.optional .)

+4
source share
3 answers

The solution to your problem is much simpler than you suggest:

We do not reinstall products such as in the past when the product is updated. Reinstalling the product will reuse your general configuration profile, so you can overwrite your settings.

Instead, you now provide upgrade steps. For example, if you change the version of your profile from 2 to 3, you will receive:

 <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 phase, you can do what you like, even re-run individual import steps.

If the product update is not associated with a change in the GS profile, do not increase its version in metadata.xml. In this case, you obviously also do not need the upgrade phase.

+5
source

I suspect that you are doing a lot more difficult with yourself, using the story about installing the Plone add-on (which is complicated by the "old" and "new" technologies that live side by side). I would take a step back and think more about the plug-in system you are trying to design / implement, and avoid turning Plone on until you need it [1].

You can also use entry points to implement at least part of the plugin system:

[1] Assuming Plone is a strict requirement and you are creating a content-driven application, otherwise you should probably use Django or Pyramid

+1
source

Installation / reinstallation does not create feelings in the context of an add-in. The dictionary has been modified to activate / deactivate, but this is not enough to understand the situation.

You have a “setup” in which you apply a configuration profile. Apply again and again the configuration profile does nothing but break existing configurations.

That is why each body will answer this question using the update step. We do not start the profile when reinstalling, we update the add-ons when the configuration profile has some changes.

So, if you are in the case where the parameters added by foo.core are changed using foo.optional, you can do the following.

With the new plone.registry, you can add an IRecord-related event handler:

  • add
  • change
  • remove

Consider the documentation:

http://pypi.python.org/pypi/plone.registry

I have done some code related to this when I want to rebuild the css registry when changing some settings:

https://github.com/collective/collective.jqueryuithememanager/blob/master/collective/jqueryuithememanager/registry.py

+1
source

More articles:


All Articles