[Twisted-web] Re: new nevow know-how needs...;-)

[Alex Martelli]

James Y Knight wrote:
   ...
> I just totally changed how this worked today. I'll describe what *now*
> happens, which is different from what used to happen:
> 
> def data_foo(context, data):
>    return 4
> def render_foo(context, data):
>    return context.tag['Hi: '+data]
> span(data=data_foo, renderer=render_foo)
> 
> This will first call data_foo, returning '4'. data_foo's context will
> be the context of the span (context.tag is the span tag), without its
> IData remembered yet (thus, the data argument will be whatever the
> containing data is, in most cases, the rend.Page instance.
> 
> Then, render_foo will be called, with the tag's context, again, but now
> with the result of data_foo's result (4) as 'data'.
> Thus, this will result in the string "<span>Hi: 4</span>".

Wonderful!  This new behavior, as you describe it, perfectly matches my
intuition about "what _should_ happen".


> Now, take another example:
> number = 0
> def data_count(context, data):
>    global number
>    number = number + 1
>    return number
> 
> span(data=data_count)[str, ' ', str, ' ', str], ' ',
> span(data=data_count)[str, ' ', str, ' ', str]
> 
> This will result in the string "<span>1 1 1</span> <span>2 2 2</span>".

One more thing that feels just right -- two "calls" (data directives that
mention data_count), two "executions" (actual calls to the function).


> Note that returning deferreds from the data_ is now supported. In

Again, wonderful!  I'll be able to dismantle my pesky "fake renderers"
that basically dealt with data being intrinsically deferred.

> detail, the way this works:
> nevow.flat.flatstan.TagRenderer calls (quite paraphrased)
> "context.remember(convertToData(data, context), IData)" when it first
> sees a tag, right before it calls the function specified by the render=
> attribute.
> 
> convertToData causes functions to be called, 'directive' statements to
> be looked up, and deferreds to be handled. Then, when the actual
> rendering function is called, it does context.locate(IData), which
> finds the previously remembered data, and passes it directly (no
> further fiddling is done!) to the data argument of the renderer.

Superb.  Feels simple, direct, and predictable.


> If you use a directive('name') form in a data=, this causes the current
> data to be adapted to IContainer before calling .get on it. There are
> currently adapters for dict, list, and tuple for this.

Hmmm, yes, I had to write an adapter to IContainer for my application's
"business object" class just to redirect data lookups back to the resource,
because this kind of thing just seemed to happen "when it felt like it":-).

> Thus,
> def data_foo(context, data):
>    return defer.succeed({'foo':1, 'bar':2})
> 
> span(data=data_foo)[span(data=directive('foo'))[str],
> span(data=directive('bar')[str]]
> 
> Should work as expected, and call data_foo *once*, and produce
> "<span><span>1</span><span>2</span></span>".
> 
> Hope this helps,
> James

Sure does!  Thanks James.  The one aspect that's still a bit obscure to
me is, how is this distinction between "data=data_foo" (where I want to
use function or method named data_foo as the data supplier) and
"data=directive('bar')" (where I want the IContainer adaptation and
call to .get) distinguished, _when the HTML comes from an on-disk
template, rather than from a stan expression in my code_?  My application
is thoroughly based on on-disk templates -- I don't code much stan stuff
at all, except basically for quick and dirty prototyping of stuff that's
destined to move to an on-disk template soon anyway.  So, won't every
HTML construct coming from a template of some form such as:

<span nevow:data="bar">
    etc, etc
</span>

end up "compiled" into a "span(data=directive('bar'))[etc, etc]" anyway,
leading me right back into subtle issues of "WHERE is this 'bar'
going to be looked up, depending on phase of the moon etc"...?  Or are
there two different ways I should code that '<span nevow:data="bar">' in
the on-disk template depending on whether I mean one thing or the other?

Anyway, if I understand correctly, I'll now get this "new behavior" with
just a cvs up on the (stand-alone) Nevow CVS, which I intend to do at
once, so I can experiment.  But, if I can get some explanation of how
things are designed to work, this might help.  Perhaps as small a change
as "if the current IData remembrance is not adaptable to IContainer [and
perhaps also if it is, but its .get raises?], just back off to 'external'
IData remembrances until a satisfactory one is found" would be sufficient
for my purposes, and -- if you can confirm there's no other solution that
better matches the current intent of the code -- I could experiment with
that kind of approach.


Thanks again,

Alex