Comparison with ZPT [Was: [Twisted-web] Sub-tag level templating in Nevow: possible?]

Andrew Bennetts andrew-twisted at puzzling.org
Sun Oct 10 15:29:14 MDT 2004


On Sun, Oct 10, 2004 at 09:57:26PM +0100, Matt Goodall wrote:
[...]
> 
> Yes, this is what slots are for ...
> 
> Your template should look something like this:
> 
>         <a href="#" n:render="category"><n:attr name="href"><n:slot
>         name="link"/></n:attr>Category: <n:slot name="name"/></a>

Pardon me for hijacking the discussion like this when I barely know
Nevow, and have relatively limited knowledge of Zope Page Templates (ZPT)...

This looks much more verbose than the ZPT way of setting attributes:

    <a tal:attributes="href context/link">Category: <span 
    tal:replace="context/name" /></a>

[The tal:replace isn't relevant to setting the attribute, I'm just doing
that for completeness sake with the Nevow example].

Here "context/link" could be an TALES expression, of course.

Multiple attributes can be set with, e.g.:

    <a tal:attributes="href foo; class bar">...</a>

> The "contract" between the HTML template and the render method is to
> provide (at least) the two slots 'link' and 'name'. Your renderer should
> therefore look something:
> 
>         def render_category(self, ctx, data):
>             ctx.tag.fillSlots('link', data)
>             ctx.tag.fillSlots('name', data)
>             return ctx.tag
> 
> As you can see, the render method provides the information but has no
> idea how it is used; the template expects the slots to be filled but it
> can do anything it wants with the information.

In Zope 3, the contract is specified by an interface.  Somewhere, usually in
ZCML, you declare what interfaces are allowed to be accessed on what content
types when rendering (or publishing in general, I guess).  You can also
define view classes (which are adapters that adapt a request and a context)
if you want to define display logic that doesn't belong with your business
logic (such as helper methods for generating HTML, or form processing), and
again the contract here is controlled by interfaces.

This is a very nice model -- interfaces are designed to be contracts, after
all.  

I mention all this because I suspect that in many ways ZPT and Nevow are 
quite similar, and it would be good if they could cross-pollinate,
particularly if it helps users of one shift to the other.  The easier it is
for ZPT users to play with Nevow, the better :)

So, I guess this suggests two questions:
  - is it possible to make the attribute-setting syntax in Nevow nicer by
    borrowing ZPT's syntax for it?
  - is it possible to use interfaces to define contracts between templates
    and renders in Nevow? (so as to make it easier for people to shift from
    the Zope 3 model and back)

-Andrew.




More information about the Twisted-web mailing list