Opened 17 years ago
Closed 17 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 , 17 years ago
comment:2 by , 17 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 , 17 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? :)