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 [EMAIL PROTECTED]
Zope Corporation "Zope Dealers" http://www.zope.com
_______________________________________________
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 )
