[Zope-dev] PythonLibraries Product

[Tres Seaver]

Evan Simpson wrote:

> Seb Bacon wrote:
> > Could you provide a brief summary of why this is better than a
> > folder of python scripts?  Perhaps a use case which illustrates the
> > problems of the current way of doing things?
>
> It isn't *better* than a Folder of Scripts, it's *different* :-) I
> have two weak use-cases, a longstanding "I'm going to write that some
> day" itch, and some aesthetic arguments.
>
> One of the more frequently stated complaints about ZPTs is that to
> properly remove non-presentation logic and ugly little Python
> expressions from a template, you either need a pile of little Scripts,
> or a single "controller" Script that precalculates everything and
> passes it to the template.  I've settled, fairly happily, on the
> second solution.
>
> Both of these solutions suffer from the "two or more objects to
> accomplish one task" management problem.  I usually combine the
> objects in a dedicated Folder, which is still a bit awkward, and
> doesn't solve everything.  One drawback is that the individual
> components are all published, despite the fact that I only intend
> one of them to be web-addressable.  It would be very handy to attach
> the Scripts directly to the template, but the straightforward way of
> doing that means making the template a container, and opens a whole
> can of worms.  Instead, what if templates had a Library tab, and it
> worked with External Editor?  It would actually be easier to *just*
> write this, and not have independent Library objects, but generalizing
> this capability feels right to me

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.

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:

  - Embedding the Python code into an HTML/XML comment at the head or
    foot of the template in the .pt file will not let editors help with
    syntax highlighting.

  - In addition to messing up syntax highlighting, embedding the
    template as a triple-quoted string literal in the .py file feels
    *really* nasty (almost as nasty as Zope3's <script> tag).

And there is yet another argument for the bound library:  it shows how
unnecessary, as well has how evil, that <script> tag hack is.

Refactoring a "one-off" template-cum-library will be simple, too:  once
the refactored code is moved to a "real" module (even a persistent
module in Zope3!), the library can just contain
'from realmodule import usefulFunction', and the template won't need
to change.

I would vote for having the bound library's names inserted into the
'template' TALES namespace, BTW.

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