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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
