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
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 L. Drake, Jr. <fred at zope.com>
PythonLabs at Zope Corporation
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -