DTMLOverride Information

This product is organized for INSTANCE_HOME installation, so untar it in the appropriate Products directory. You will note that the actual name of the Product created is AA_DTMLOverride. This is so that it gets inited before any other Product (I know this works on FreeBSD, but I don't know if product init order is always alphabetical on all python/os combinations). This is because the Product hotpatches the __init__ method of App.ClassicHTMLFile, and this hotpatch needs to happen before any other Product init tries to use DTMLFile.

To use the Product, you create a file named "DTMLOverrides.txt" in the Extensions directory of your INSTANCE_HOME (which is your zope installation directory if you are not using a separate INSTANCE_HOME directory). This file consists of a series of lines containing mappings from Product DTML Method names to alternate locations for the source to those methods. Lines starting with # are considered comments.

Supposed there is a product named "AddressBook" that defines a DTML Method called "editForm". Suppose further that within the Product this method is stored in a file at the relative path "dtml/editForm.dtml". Or, to put it anther way, the DTMLFile call inside the Product looks like:

  editForm = DTMLFile('dtml/editForm',globals())

To override this method with your own version, you might copy the source file to Extensions/dtml/AddressBook/editForm.dtml, and make your modifications. Then in DTMLOverrides.txt you add the following line:

  AddressBook/dtml/editForm Extensions/dtml/AddressBook/editForm

Note that just as with DTMLFile itself, you leave off the .dtml suffix (HTMLFile hardcodes this extension, so your file has to have that extension).

Because this Product works by hot-patching DTMLFile, it is compatible with Refresh. That is, if you Refresh a Product whose DTMLMethods you've overriden, your override files will be correctly re-read. Likewise the normal "development mode" auto-refresh of the overriden DTML Methods should work correctly.

This is a proof-of-concept product. I'd very much like feedback on whether or not this is a useful feature to have in Zope. I'm also considering trying to see if it would be possible to have a ZODB option for the location of the override file. How I'm thinking this might work would be to remove the method definition from the product class entirely, so that product class instances would acquire the attribute through the normal zope acquisition process, thus enabling you to place the override methods in an appropriate place in your Zope file tree.