I've heard various statements that a product which sets up a site
should use a base profile. I have interpreted this as define all
types, all workflow, all toolsets, all skins etc into the profile of
that product. For example for plone, one would copy
CMFPlone/profiles/default and work from there, filling out the profile
to include other 3rd-party products that you want in your custom site.
Is this the right interpretation?
What is the argument for a site product to use a base profile?
Actually, what is a base profile? Is it not just a particular profile
that happens to have a typically replete set of import export steps
that cover the import export handlers of GS as it ships?
I would have thought a site product profile would include the following:
- an ordered set of extension profiles that are applied from an empty
- local overrides for any part of any of these extension profile that
you want to change ... i.e. a local extension profile that is applied
last (or perhaps a number of local extension profiles slotted into the
ordered list of extension profiles)
The continual merging of extension profiles from 3rd-party products
into a base profile seems to add more work where it is not necessary
(just apply the latest and greatest extension profile). This is why I
think my interpretation of what a 'base' profile for a site product is
Some of this talk about ordering dependencies and base profiles vs
extension profiles in zope-cmf and plone-core-developers (with some
bbq sprinklings) is making me wonder about how to really visualise a
base profile for a site product.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests