[Zope-dev] PythonLibraries Product

[Tres Seaver]

On Wed, 2003-09-10 at 23:46, Evan Simpson wrote:
> Tres Seaver wrote:
> > 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.
> 
> Agreed.
> 
> > For the filesystem representation:  what if we just have two files for
> > templates with libraries:  'foo.html' and 'foo.html.py'?
> 
> Eh.  I think filesytem representations should handle this sort of thing 
> much more generally.  Assuming that the Zope object's ID is 'foo.html', 
> there should be a text file of that name (encoded with quote_plus, which 
> makes no difference in this case), and a directory named 'foo.html,'. 
> Inside of this directory, there would be a 'library.py' (in this 
> particular case), along with files such as 'properties' and 'proxies'.


Hmm, I'm thinking about this for the CMF.  In CMF 1.3.x, a template
which has a cache manager, or a title, puts those values in a simple
'name=value'-formatted file, with extension '.properties'.  Permission
mappings go in a separate file, with extension '.security'.  So, the
filesystem-based template 'foo_view' might have as many as three files
associated with it:

  - 'foo_view.pt'

  - 'foo_view.pt.properties'

  - 'foo_view.pt.security'

CMF 1.4 unified the two files into a single, '.ini'-formatted one:

  - 'foo_view.pt'

  - 'foo_view.pt.metadata'

It feels more natural to me just to add another file:

  - 'foo_view.pt.py'

This is especially nice for many CMF skin templates (those which contain
forms), because I can probably *remove* the separate template which
serves as the "POST-target" for the form!  Instead, such templates will
post *to themselves*, and use the bound library to do the validation /
updates.  In this case, we go from:

  - 'foo_edit_form.pt'

  - 'foo_edit.py'

to:

  - 'foo_edit_form.pt'

  - 'foo_edit_form.pt.py'

> 
> > And there is yet another argument for the bound library:  it shows how
> > unnecessary, as well has how evil, that <script> tag hack is.
> 
> Yep :-)
> 
> 
> > Refactoring a "one-off" template-cum-library will be simple, too:
> 
> Cool!
> 
> > I would vote for having the bound library's names inserted into the
> > 'template' TALES namespace, BTW.
> 
> Tricky -- right now, that's just the template object itself.  I'd just 
> introduce a builtin 'library' variable, and probably dump the function 
> names into the global namespace as well.

+1, then.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com