Reinout van Rees wrote:
Often, the client wants us to change some of the plone templates. When
that is a large-scale replace/rebuild of the main_template, ok. But what
I see most often in our practice is a small tweak here and there. An
added textual explanation to a form. Adding a dropdown to the search
box. In most of the cases, the majority of the template remains intact.
Then a new plone release arrives. Has anything changed in the templates
we've adapted? Do the changes conflict? Do we need to adapt some more?
At least, that are the questions I'm confronted with.
The reason? Quite simply copying the templates to a customizing
product's skin directory and modifying them there. At least, that's the
practice I'm using myself. It strikes me as sub-obtimal.
How do you all handle this?
I just did some braintorming and came up with the following rough idea:
* Have some directory with diffs to the original plone template.
* Have a small script copy the original plone templates and apply the
diffs.
* If there's a .metadata file, copy that right along.
* Check the page template for validity (i18ndude is a great validator)
* With a new plone release you can easily spot the templates that have
conflicting patches.
Just brainstorming :-)
I wrote a product once that, instead of creating FSPageTemplates from
whole files created them based on a patch. It works, but I discovered
quickly that when Plone does (biggish) upgrades, usually the patches
won't apply cleanly. Certainly it didn't work for our 2.0->2.5 jump.
http://rhaptos.org/cgi-bin/viewcvs.cgi/DifferenceEngine/trunk/
It also has a simple "patchlib" that uses the system patch command,
since Python has a difflib but no way to go the other way round. So it's
pretty much Unix-only, though I suppose you can get 'patch' on Windows
in a few ways.
But, like I said, I don't think it's practical. Maybe it could be with a
little more work, but I think it's easier to:
1) insist that any change to a template from somewhere else be noted
in a comment on that template
2) on upgrade, reapply those changes, if necessary
It's annoying, but not too hard. I wrote a little script to more quickly
gather the information I needed for this:
http://rhaptos.org/cgi-bin/viewcvs.cgi/devsets/plone25/updiff?view=auto
Give it the file you want to upgrade, and it creates:
X.diff - what you changed between the orig file and the customized one
X.stock - the new stock file
X.new - same as above, but meant to be modified
X.old - the stock file from the old version
X.patch - if possible, X.diff applied to X.new
Generally, if X.patch is successful (it hardly ever was, for me) then cp
X.patch to X and check in. After making sure it was right, of course.
Otherwise, apply the changes in X.diff to X.new, referring to the
comments and other reference files if necessary, and then cp X.new to X
and check in.
The metadata files need the same treatment, by the way. They can change.
Also, if a file moves between the old version and the new (like all the
stuff in plone_login now) then you have to do a lot of this by hand.
Not super-advanced, but it worked. Requires a lot of edit buffers, though.
--jcc
--
"Building Websites with Plone"
http://plonebook.packtpub.com
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
