On 18 juin, 00:14, Eric <[EMAIL PROTECTED]> wrote:
> This isn't a bug but it's something that might need to be documented
> to prevent folks from doing something that may hurt them later:
>
(snip)
>
>     repr_node = ReprNode("obj")
>
>     for i in range(10):
>         repr_node.render(context)
>
> Can you tell what the problem?  We're calling the render method
> on the same instance of the Node.
>
> Let's peek under the covers and look at ReprNode's definition::
>
>     class ReprNode(template.Node):
>         def __init__(self, obj)
>             self.obj = obj
>
>         def render(self, context):
>             self.obj = template.resolve_variable(self.obj, context)
>             return str(self.obj)
>
>         def do_repr(parser, token):
>             tag_name, obj = token.split_contents()
>             return ReprNode(obj)
>
> Now look at what's going on.  self.obj is assumed to be the name of
> the
> variable in the context.  That's fine when render is called once.
> When render
> called a second time, self.obj is now the actual value of obj from the
> context.

This is exactly what you asked for. The cure is obvious : *don't*
rebind self.obj in render().

>
> I made the assumption that render() is only called once.

Wrong assumption. The mere fact that the context is passed to the
render method and not to the initialiser should be a good enough
indication that the same node instance can be rendered many times with
different contexts. If this wasn't the case, you wouldn't need a Node
class  - a plain function would be enough.

>  You don't
> realize that inside a for tag, the render method is called
> repeatedly.

It would be very unoptimal to reparse the for block content,
reinstanciate new Nodes and call their render method on every
iteration.

>  This can cause tons of issues.  If it wasn't a huge
> design change, TemplateTag should probably be Static classes.

What's a "Static" class ???

> I don't know if this is technically a bug in the Django templating
> system,

It isn't, obviously.

> bad design,

Neither.

> bad documentation,

I wouldn't call it "bad". Now everything can be improved, and since
explicit is better than implicit, it might be worth adding a note
explaining that point.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to