Tres Seaver writes:
Actually, the restricted case is the one which has the real win; the "free-floating" library is pretty, but not semanticaally needed. An added argument: a ZPT with its own private library becomes, in effect, a Zope3 view component; adopting such beasts will ease migration to Zope3.
And it keeps all the pieces easy to locate! +1
For the filesystem representation: what if we just have two files for templates with libraries: 'foo.html' and 'foo.html.py'? Tools will like that better than either of the approaches which try to preserve the twins as a single file:
The current Zope 3 filesystem synchronization doesn't currently support writing multiple files for a single object; every object is expected to be either file-like or directory-like. There are a few ways to approach serialization of a view that contains both a template and Python code: - Serialize it as a directory containing two files. - Serialize it as a file containing the template, and make the Python code live as an "extra", which would be written to a file in the metadata storage area (tedious to work with, but could be an otherwise normal .py file). - Change the filesystem serialization so that multiple files can be generated to represent a single object. I think this would require a substantial amount of work. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation