Hi Tres!

Tres Seaver wrote:

yuppie 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 approach:

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

Reply via email to