[Twisted-web] Alternative to <nevow:attr>
matt at pollenation.net
Wed Oct 20 03:26:36 MDT 2004
On Tue, 2004-10-19 at 23:06 +0200, Andrew Bennetts wrote:
> On Tue, Oct 19, 2004 at 12:10:37PM -0700, David Reid wrote:
> > On Tue, 2004-10-19 at 02:51, Andrew Bennetts wrote:
> > > TAL does allow this, in two ways (that I know of):
> > >
> > > First, there's the hackish way:
> > They're both hackish ways in my opinion, and the latter
> > Another alternative is for the alternative syntax to not even support
> > such behavior, and only be for the general case which would look
> > something like this:
> > <a nevow:attributes="href=link alt=label"><nevow:slot name="label"
> > /></a>
> > (Looks an aweful lot like mg's attr.tac example, doesn't it?)
> mg's attr.tac has this in the template:
> <ul nevow:data="links" nevow:render="sequence">
> <li nevow:pattern="item" nevow:render="link"><a href="#" nevow:render="attribute href=link,alt=label"><nevow:slot name="label">label</nevow:slot></a></li>
> I don't see what this does that is different to:
I think that was David's point, they're basically doing the same thing
with a different syntax.
> <ul tal:repeat="linkinfo context/links">
> <li><a href="#" tal:attributes="href linkinfo/link; label linkinfo/label"/></li>
> Although I don't totally understand why mg's attr.tac has a nevow:slot tag
> for label and not link, as far as I can tell the ZPT I give here is
> equivalent in concept. Explanations and/or corrections welcome!
The attribute renderer in attr.tac example updates updates from values
in slots, i.e. href is set to the href slot and alt (yeah, it should be
label;-)) is set to the label slot. The slot *inside* the <a>...</a> is
actually nothing to do with the attribute renderer but ensures that the
label also appears inside the element.
I don't know ZPT well enough to know if your example does exactly the
same (I can't see how it could) but that really doesn't matter for this
I should point out that most of the time, I use the <n:attr ...
><n:slot ...></n:attr> syntax because it's always there and it's more
flexible. I wrote the attr.tac more as an example of how one might
implement something like this using a renderer although it does have the
benefit of being compact for really simple stuff.
> Of course, my ZPT examples requires that the code would require there to be
> a linkinfo class, e.g.
> class LinkInfo:
> def __init__(self, link, label):
> self.link = link
> self.label = label
> And context/links would just be a list of these. I don't see this as being
> any more complex than what attr.tac does, though.
This is probably the right way with Nevow too. The difference with Nevow
is that Nevow refuses to look inside objects it doesn't understand by
default so it would never use getattr unless explicitly told to.
You can tell Nevow how to look inside objects by registering a
inevow.IContainer adapter. We've talked about providing a IContainer
adapter that does getattr magic in Nevow but it would be up to the
developer to register the adapter for specific types.
> If nothing else, I hope this discussion can serve as the basis for a "Nevow for
> ZPT users" tutorial.
I guess I should learn ZPT properly sometime, just to get another angle
on all this.
/ \__ Matt Goodall, Pollenation Internet Ltd
\__/ \ w: http://www.pollenation.net
__/ \__/ e: matt at pollenation.net
/ \__/ \ t: +44 (0)113 2252500
/ \ Any views expressed are my own and do not necessarily
\__/ reflect the views of my employer.
More information about the Twisted-web