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@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
On Wed, Sep 10, 2003 at 09:50:51PM -0400, Tres Seaver wrote:
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:
sounds fine.
I would vote for having the bound library's names inserted into the 'template' TALES namespace, BTW.
+1 -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ALPHABET METROID WINO! (random hero from isometric.spaceninja.com)
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 '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 -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
--On Thursday, September 11, 2003 10:08:23 -0400 "Fred L. Drake, Jr." <fred@zope.com> wrote:
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
+1
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.
IMHO, this is the obvious and probably best choice. It's well in line with a sentiment in the the Linux file system world that the way to handle multi-piece files is to treat them as directories rather than introduce another layer of special mechanisms. The file sytem itself can them optimize their storage as part of a general small file optimization strategy. I don't think the objection to having to pack a ZPT and it's script(s) in a separate ZODB folder applies anywhere near as well to file system storage. Dan Pierson
Tres Seaver wrote:
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.
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.
Well, I'm completely convinced :-) I'm not quite sure about the metaphor for binding a library to a template yet, though. Could libraries be added to folders as first-class objects (you want to be able to share them between templates easily, no?) and "bound" to the templates using a tab on either them or the templates? Their icons would be overlaid with a visual indication of if they are bound or not. Or, could you bind them at run-time using a new tal directive? (not likely to be a popular suggestion, I know) seb
participants (5)
-
Dan L. Pierson -
Fred L. Drake, Jr. -
Paul Winkler -
seb bacon -
Tres Seaver