[Twisted-web] [Nevow] template performance

L. Daniel Burr ldanielburr at mac.com
Fri Dec 15 12:56:02 CST 2006


On Fri, 15 Dec 2006 12:34:53 -0600, Manlio Perillo  
<manlio_perillo at libero.it> wrote:
[...]
>
> The point is that in the template it should be "visible" the XHTML that  
> will result.
>
> As an example, this code:
>
>            <ul nevow:pattern="sums-container">
> 	    <nevow:slot name="elements" />
> 	  </ul>
> 	  <li nevow:pattern="sums-element">
> 	    <nevow:slot name="date" />
> 	    <nevow:slot name="value" />
> 	  </li>
>   	
>   	  <ul nevow:pattern="methods-container">
>   	    <nevow:slot name="elements" />
>   	  </ul>
>   	  <li nevow:pattern="methods-element">
>   	    <nevow:slot name="method" />
>   	    <nevow:slot name="value" />
>   	  </li>
>   	
>   	  <div>
>   	    Wallclock duration totals (seconds)
>   	    <nevow:invisible nevow:render="totalWallClock" />
>   	  </div>
>
>
> give me no clue on how the renderized page will look.
>

Sure, but that is nothing like the example I provided you.
In my example, it is clear that the header row contains
1 or more th elements, and that the tbody element will
contain 1 or more tr elements, each having 1 or more td
elements.

I agree that your example above doesn't read as clearly,
but I'm sure you can write that in a style similar to
what I used for the table example.

>
>> Moreover, you've embedded iteration logic in the Django
>> template, so if some idea of "XHTML purity" is driving you,
>> the the Django approach, while faster, is less pure.
>>
>
> Nevow has a better solution: the sequence renderer.
> But it will go away.
>

The sequence renderer is basically doing the same thing
as the code I used in the "headers" and "rows" methods.
We aren't talking about some large class/function that
is complicated to reproduce.  Adding a sequence renderer
that complies with the upcoming changes to nevow is not
going to be difficult.

Even if no direct substitute is provided, nothing is
stopping you from adding your own, or better yet, being
the person to contribute a new sequence renderer.  I think
it would be a good thing to do.

>  > [...]
>>  The most important thing is to stop thinking in terms
>> of data types (render="sequence", render="string"),
>> and just write render methods that deal with app-level
>> concepts (headers, rows).
>>  An important point to make here, is that the code I
>> provided above is based on the same code used to
>> implement the "sequence" directive, so there is really
>> nothing magical going on.
>>
>
>
> Ok, but what about reusability?
> Now for every table (in theory) I have to reimplement the sequence logic.
>

See above.  The existing sequence renderer is just a few lines of code,
not a magical entity.  Why reimplement it for each table?

> Well, I'm sure that it is possible to write generic/reusable code for  
> rendering tables.
>

Absolutely.  The code I provided in my example *is* a generic table
element, that you could stick in any page.  Just add some methods for
querying your DB and you have a reusable element, that will render
arbitrary data in tabular format.

>
>  > Hope this helps,
>
> Yes, thanks.
> I will try to use slots instead of data.
>

Slots are a good solution, because they work today, and will allow you
to switch to the context-less version of nevow when it is released,
without any major breakage.

>
> P.S.
> How tested/stable is the new(?) page module?
>

I have used page.Element in a production environment for months now.
I switched from using rend.Fragment to page.Element as soon as it was
available, and things have worked perfectly, at least for me.

>
>
> Regards  Manlio Perillo

Hope this helps,

L. Daniel Burr



More information about the Twisted-web mailing list