A policy product is a regular product that can be installed as other Plone add-ons and will take care of general customizations to meet project needs.
Create a package boilerplate with paster: We have already created several product packages with the
paster
command. This time it won't be anything special.To create the
pox.policy
product, run the following command inside thesrc
folder of your buildout:paster create -t plone
Provide these values at the options
paster
prompts:Option
Value
Enter project name
pox.policy
Expert Mode?
easy
Version
1.0
Description
Policy product for PloneOpenX website
Register Profile
True
Add the policy product to your instance. In the main
[buildout]
section, modify theeggs
anddevelop
parameters:[buildout] ... eggs = ... pox.policy ... develop = src/pox.policy
Optionally, if you want the product to be installed at building time, modify the
[plonesite]
section:Create an extension profiles folder: In the package's folder, create this folder structure:
mkdir -p ./profiles/default
Build your instance up again by running:
./bin/buildout
Policy products are regular products with a special meaning, they configure the website with characteristics the project has and, sometimes, no other project has. Examples of these are the title and description of the site, the initial folders' structure (displayed most of the time on navigation bars), and installation of required products, among others.
Note
The <genericsetup:registerProfile />
directive (found at configure.zcml file) makes Plone aware of this product and turns it installable.
To understand how and when GenericSetup runs special installation scripts, you may find it useful to continue reading until There's more… or have a look at Installing CacheFu with a policy product. The key actions to keep in mind are:
Drop extension profiles (special
XML
files) you need in theprofiles/default
folder to let GenericSetup automatically install and configure anything you need.If there's no
XML
-based import step for a specific customization, updateconfigure.zcml
with a<genericsetup:importStep />
directive as explained in There's more...
In several recipes of this book, we trusted Plone's GenericSetup process to work as we needed: we dropped some special XML
files in the profiles/default
folder and everything worked as expected.
However, there might be times when we need special steps or actions to be taken when installing a product. For example, we may need to create folders or content inside the portal.
GenericSetup is aware of this requirement many developers have and it supplies a special procedure to get a hook at installation time.
Modify
configure.zcml
in yourpox.policy
package:<configure ... xmlns:genericsetup= "http://namespaces.zope.org/genericsetup" > ... <genericsetup:importStep name="various" title="pox Policy: miscellaneous import steps" description=" " handler="pox.policy.setuphandlers.setupVarious" > <!-- <depends name="other step's name"/> --> </genericsetup:importStep> ... </configure>
This will make GenericSetup call the specified
handler
after all of the dependent import steps (none in our example, that's why we have commented it) had run.Create a
setupVarious
method (the abovehandler
) in thesetuphandlers.py
file inside thepox.policy
package:from zope.app.component.hooks import getSite from Products.CMFCore.utils import getToolByName def setupVarious(context): if context.readDataFile('pox.policy_various.txt') is None: return portal = getSite() # perform custom operations
Create an empty flag file for the setup handler: In the
profiles/default
folder, add thepox.policy_various.txt
file (read by thesetupVarious
method) to tell GenericSetup whether to run this step or not.Note
When an import step has been run once, it will be run every time GenericSetup is called, even from other products. As the
readDataFile
method is called in the installing product context, if the flag file is not found, the step handler won't be run. That's why it is important to use unique names for these flag files.Reinstall the policy product if needed.