On 3/22/07, Tres Seaver <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
> I'm not clear on when a product is deemed an add-on product and when
> its not. Are the basic cmf types for Document, Image, etc add on
> products? Are ATContentypes add on products for plone? Are products
> that just add skin layers addon products?
A "baseline" profile lays down the *entire* site configuration:
CMFDefault's 'default' profile, the Plone 'default', a notional
"Plone4Artists Jazz Portal", one, etc. It controls horizontal and
vertical, and can include types, skins, workflows, etc.
A developer registes a base profile for a "site type" (an interface),
with the expectation that the user will select that profile when
creating the site.
Extension profiles are *not* intended to control the whole site:
rather, they are expected to inject / add objects to an existing site.
After importing one or more extension profiles, the new site's effective
profile could be thought of as "baseline + extension(s)."
To answer your specific questions:
- There is no separate profile for installing CMFDefault's types:
they are included only in one or more baseline profiles.
- ATContentTypes does not ship with an7 extension profile; however,
the default Plone base profile includes types from it.
- A product which included only skins for an existing site type (e.g.,
Plone), would ship as an extension profile, if the intent was to
let people reskin any Plone site. If you wanted people to be able
to install an already-reskinned Plone site, then you would create
an export containing the full Plone baseline plus your new skins,
and then register the export as a base profile.
> If I create a CMFSite product that requires say ATVocabularyManager,
> should ATVocabularyManager's extension profile (if it had one) be
> folded into my base profile, or added through applying the extension
If it is essential to your site, then you would fold it in, most likely
by building the site out interactively with the ATV-less base, importing
the ATV extension, and then exporting the merged profile.
If ATV is not an essential part of your site, then leave it out.
> Is there a way to add extension profiles and lock them so they
> effectively become part of an unchangeable base profile state? (but
> see questions further down).
Extensions which have been imported modify the persistent profile state;
exporting that state gives you the "locked down" merge.
Right. I thought that might be the intention. It depends a lot on all
the export steps working well. It would be nice to know in an export
profile just what contributed to it ... but I presume that depends on
only using extension profiles to build out your site profile as you
>>> The GenericSetup way to do this would be transforming profiles, not
>>> sites. Unfortunately implementing this kind of extension profile depends
>>> on good diffs. Delta profiles based on unified diffs will not work for
>>> this use case, they are not flexible enough. A solution might be the XML
>>> diffs Matt offered to contribute:
>> I don't yet understand how such diffs would be represented, much less
>> implemented. I do agree that the current line-oriented diff format is
>> probably too fragile to use as the basis for a DeltaProfile,
>> particularly if we continue to generate export XML using ZPT (an etree /
>> objectify model would likely produce more normalized output).
> I don't either at the moment.
> At the moment it is more a conceptual algebra. For example, a usecase
> Site 1 has product A, B, and C as part of its base profile and the
> developer wants to remove product B. If you have a version of the
> extension profile that you based your folding in of B in the first
> place, and you have that profile available (and the same for A and C -
> since they may share steps) and a diff mechanism, then you could
> figure out the transformation required to get back to a site profile
> without B. The algebra in this case would be something like:
> newsiteprofile = currentsiteprofile - B +
> If however a, b, and c, were applied as extension profiles and did not
> infect directly the siteprofile resident on the fs for that site
> product, then you could have instead:
> newsiteprofile = orginalbaseprofile + A + C + localmods
> where originalbase was the site profile with no add ons (whatever they
> are defined to be), and A, B, C, and localmods are all versioned.
> But this all may just be a byproduct of the current state of things in
> the wild where:
> 1) it is hard to figure out what is different between two profiles
> (most often when exporting profiles after quickinstalling products(in
> plone) that have no extension profile and hoping the diff will give
> you hints on what that product's extension profile might look like)
> 2) so many products don't come with extension profiles.
> I want to build something that could help with both of these, so in
> effect, the only algebra you ever really need is of the form:
> newsiteprofile = orginalbaseprofile + A + C + localmod
> And it wouldn't matter if that was created and merged into a single
> resident base profile, or generated dynamically. But all of this
> assumes that you still apply a product's extension profile in the
> clear at some point and then make your local mods seperately.
At this point, on the branch we created at the sprint, we began the work
of tracking the imported baseline and extensions, using (for the moment)
the logfiles created during import. We would like to capture more
state, but decided to finish with "working but ugly" rather than leave
the design on the whiteboard.
Cool. That's worth looking at.
I'm still not sure how such an "algebraic" approach would work, given
that local modifications are potentially arbitrarily complex.
I only see it being not complex if you can dissect out the original
base and then any extension profiles applied or local modifications of
the base profile. You could do this by way of good practice with
I am seeing an algebra not being very necessary; it seemed to only be
in the context of 1) comparing an exported profile to a previous base
profile to see what a product or products installed with
quickinstaller contributed to the new profile, and then to see why in
most instances it didn't work (usually because their Install.py does
some crazy things that just don't get captured in an export of state).
2) comparing the base profile of say a new plone version to your
current site profile and trying to work out what you should change -
for example perhaps one of the products you installed at one time made
a change to a particular step - it ends up being a 3 way diff.
Still, some canonical serialized form of profiles would be useful for
being able to still play with unified diffs. Which was very much my
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests