On Mon, 17 Jul 2006 15:39:10 -0200, Manlio Perillo <[EMAIL PROTECTED]> wrote:
And what about my first solution?
http://twistedmatrix.com/pipermail/twisted-web/2006-July/002813.html
Better, although it rewrites the sequence renderer for more or less the same
functionality. Not too bad of course but could be avoided with less code and
more templates (that usually are dealt with by the designer).
The second is that IData is not for external use but rather internal
Nevow usage.
Ok, thanks for the advice.
I have read about this trick in a message in the archive.
Only one last question.
I have read the whole ml archive but I was unable to find any message
where it is explained why the context is bad.
The context has some bad points:
1) Changes the rules for passing arguments to python functions, instead of
using normal foo(a, b, c) you do ctx.remember(a, IA)... and foo(ctx), then
in foo you do IA(ctx) and so on. While this might have an advantage after
an initial analysis it isn't like that at all since you can always use
**kwargs and grab the arguments you need from kwargs, and kwargs is
standard python convention (although explicitly defining arguments is
better for most cases).
2) It is slow... each adaptation is a non-trivial function call that might
end up with multiple lookups into a tree. Of course there are
optimizations that could solve this problem but nobody dared to write them
AND test them AND merge with trunk.
3) The context is slow in a way that can hardly be optimized because for each
branch in the rendering/childlocating procedures a new context is created.
I don't have real numbers but I can presume that for each request a
minimum of 3 contexts for a mostly static page at root level and an
unlimited maximum of object creation/collection and this for _each_
request.
4) The context makes non trivial understanding what instead should be trivial
because it saves state that is reused later breaking the tracebacks.
This are the first 4 reasons that came to mind.
Ok.
But I'm searching a simple solution that is database friendly; that is,
where I can map directly database queries to data directives.
Just like everyone else does. Besides that writing a simple function like the
following:
def mapComments(comments, for_atom=False):
for comment in comments:
yield dict(rank=comment[0],
author=comment[1],
id=comment[2],
body=comment[3],
date=comment[4]
)
Will give you a dict interface over the comments rows returned from the
database without losing much performance compared to the situation without that
functions (also thanks to generators).
Also consider that it's better to put time in creating something that makes a
specific problem more generic so that an already existing tool can be used to
solve it rather than creating many different solutions to the same problem.
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
