Opened 16 years ago
Closed 16 years ago
#8951 closed (invalid)
Better support for writing more complex template tags
Reported by: | simon | Owned by: | nobody |
---|---|---|---|
Component: | Template system | Version: | 1.0 |
Severity: | Keywords: | djangocon | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Adrian and Jacob on stage at DjangoCon.
Change History (3)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Component: | Uncategorized → Template system |
---|
Exemple o required fixups on tags and filters :
I try to write something a list of objects that are complex to render, and for which I will assign some specific "credentials" in a database while enumerating.
I would be happy to use a tag to simplify the rendering of these complex objects. However, things are not happenning like I expect. At first try, I did :
{%for o in listobject%} o1={{o.id}}, o2={%tag o.id arg%} %{endfor%}
We coded (code included later) the tag using "oid=template.Variable(tok[1])" or Parser.compile_filter in the template tag, "oid.resolve(context)" in the render function.
Samething that simple_tag would have done.
However, the id of the first object of listobjects for o2, while o1 is correctly moving... This should be qualified as a bug since it is not the expected behaviour in a for loop...
I guess this is due to the fact that "for" and "endfor" are themselves tags.
The one would think about writing a filter, and to do {{o.id|filter:arg}}, the problem of this approach is that in tags, I could access "context" to retrieve objects in the context,
the filter syntax does not provide access to context and supports only one argument, that is generally a string. If I want to access the my user profile (as I actually want)
I am stucked...
I believe generally that "request", "session", "context" objects should be easily accessible from tags and filters
Currently this is not the case.
I hope explanations of this kind of need can help make the next tag system better.
Code of the buggy tag :
def buggytag(parser,token): class Node(template.Node): def __init__(self,oid,param): self.oid=oid self.param=param def render(self, context): if (type(self.oid)!=int) and (type(self.oid)!=long): self.oid=self.oid.resolve(context) o=Objects.objects.get(id=self.oid) key=foo_create_accesskey_for_key(context['request'],o) return ('('+str(oid)+')'<span id="'+self.param+'"></span>' +'<script>load_object("'+o.url+'","'+self.param+'","'+key+'");</script>') tok=token.contents.split() assert(len(tok)==3) try: oid=int((tok[1])) except: oid=parser.compile_filter(tok[1])#template.Variable.. param=tok[2] return Node(oid,param)
comment:3 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Without a specific suggestion it's hard to know what to do here. Closing in favor of some of the other tickets 'round these parts that have specific suggestions/patches.
bits[] needs to go away. Badly. Perhaps this and namespaces could be part of a ttag refactor? (and other ponies as well? :)