Tres Seaver wrote:
So the use cases for these DeltaProfiles are very limited. Using XSLT
would allow us to unify DeltaProfiles and ExtensionProfiles, providing
an automated way for creating ExtensionProfiles.
The major use case for "deltas" (no matter whether they do XSLT
transforms or apply patches) is to permit re-applying local changes
after an upgrade. They aren't likely to be satisfactory as a mode for
distributing add-ons, I think.
I agree that creating ExtensionProfiles for add-ons will never be a
completely automated process. But it would be easier to polish a
generated profile than writing ExtensionProfiles from scratch.
More important is that ExtensionProfiles can be applied to a profile,
not just to a site. If that is not the case your use case (re-applying
local changes after an upgrade) will not work.
I hope this example illustrates the problem:
Step 1: A Site is created using a base profile and some extensions.
Step 2: The site is customized TTW.
Step 3: An additional ExtensionProfile is applied.
Step 4: The site is further customized TTW.
Step 5: Now we want to upgrade the used profiles.
How would you create the necessary DeltaProfile? AFAICS this only works
if we are able to create an uncustomized version of the profile
combination used in that site. At no point you can create this
uncustomized profile with a snapshot. And right now the only tool we
have for combing profiles is the site itself.
So we either have to implement a machinery that allows to apply the
existing ExtensionProfile format to base profiles directly or we have to
switch to a new format for ExtensionProfiles. That new format should use
a generic format like XSLT or diff.
Diffs are not made for manual editing and break easily if the base
profiles are changed / updated.
I would definitely like to break the requirement that extensions have to
displace (even temporarily) the tool's import profile. I would also
like to work out how we might safely revert the application of an
extension, as well as tracking dependencies among them. I am *not*
sanguine about using XSLT as the primary mechanism for describing an
While I still believe XSLT would be the most powerful solution it is not
a necessary part of my plan. My initial posting described an alternative
If we split up the profile files in small pieces we can use layers and
just override the pieces we want to change. This is not as fine grained
as diffs or XSLT, but in exchange much simpler.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests