[Zope3-dev] Re: Downstream Users making changes.

[Paul Everitt]

Tres Seaver wrote:
> On Wed, 2003-01-22 at 07:38, Steve Alexander wrote:
> 
>>>>If you *do* make it easier to modify "closed"
>>>>software, then you *must* make resolving conflicting changes easier than
>>>>I foresee us having resources to tackle in the near term.
>>>
>>>I think this will be needed anyway. If an end user of Swishdot 
>>>customizes a template or script and I, as Swishdot author, also change 
>>>that template or script for the next release, then they need to know 
>>>that when they install the new version. It would also be nice if we 
>>>could provide something to help them resolve the conflicting changes.
>>
>>They don't need to mess with Swishdot in order to change a template or a 
>>script. They can do that in their own Zope Package / workspace / 
>>whatever, and configure things so that their changes override the ones 
>>caused by installing Swishdot.
> 
> 
> Sure, the CMF's "skin customization" allows that use case now;  the
> problem is that they when Chris *does* release a new version of
> Swishdot, the site manager who has installed and customzied an earlier
> version has no help in evaluating / merging Chris' changes with the
> customizations.  Leaving the customized version in place untouched can
> mean that the site will not have access to features or bugfixes in the
> new release.
> 
> For consulting purposes, where we expect the client to customize skins
> during a project, for instance, we have adopted a pattern to help cope
> with this problem:  each filesystem-based template or Python Script
> embeds its CVS repository info into the source;  because the CMF copies
> that information when creating the "custom" version, we can track where
> the "branch point" was.  Resolving the conflict can still be *extremely*
> tough, especially with ZPT, which tends to be "diff-unfriendly".

I've been meaning to throw out a meme on this.

It's true, many people customize the main_template and then divorce 
themselves from any future enhancements.  As another alternative for 
addressing this problem, we could look at the approach of Mozilla overlays:

   http://www.xulplanet.com/tutorials/xultu/overlay.html

In this model, your customization would only define a small change, as 
well as where in main_template to apply it.  Without touching 
main_template, or perhaps without even have access to edit it, you can 
customize it.  (This is how you get your app into the Moz menus, for 
instance, or add a toolbar.)

Another approach: pipelines.  Process main_template, takes its output, 
and get the change points from the customized version.  Only the TAL 
blocks marked as part of the customization would alter the output of 
main_template.

Both of these models would require much more regular use of the id= 
attribute (or perhaps a tal:id so we don't conflict with existing use.)

--Paul