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 ''?  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>
PythonLabs at Zope Corporation

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to