#5713 closed (wontfix)
Template language lacks means to display trees as nested structures
Reported by: | NickMoffitt | Owned by: | nobody |
---|---|---|---|
Component: | Template system | Version: | 0.96 |
Severity: | Keywords: | recursion | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I have a fairly simple need: to display tree-structured data as nested tags. For my example, I'll propose that what is displayed is a list of links to messages in a complicated thread structure. This is clearly a display logic problem, and is thus the province of the template system. This is also common enough of a problem that I do not feel it should be necessary to cobble together custom template tags to meet my needs.
The core problem is that the templating language does not support recursion or even the mutable structures necessary to simulate it. If I had some sort of stack that I could work with, this would be a solvable problem. I understand that this is probably good for performance reasons, and it prevents endless loops and runaways that are probably more dangerous in a template than in other places.
In the #django channel on freenode, I received many helpful proposals: Recursive loading of templates was one, although this was pointed out as being something of a performance nightmare.
Another was to serialize my data into a traversal, with tags showing indent and outdent. The trouble with this is that there's no easy way with the built-in tags and filters to do something like say "print as many </ol> tags as the value in message.outdent". To avoid completely embedding HTML in my structures, I had to make the outdent properties into lists, so that I could iterate over them in a for loop and print a closing tag each time. This is plainly bogus, but it gets the job done without needing any custom tags.
I often see people ask "why are you so reluctant to write a custom tag?" in response to questions about the template system. Perhaps the frequency of this question is a hint that the base tag and filter set need to be fleshed out a little better. in the channel someone noticed that jinja has tackled this problem using loop recursion tags.
Change History (4)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
The fact that people recommend you to write a custom tag doesn't mean this belongs in the base template system - recursion is not a common request that I've seen :)
However, it is indeed quite easy to make an inclusion tag that recurses, and it works fine. In addition, the behavior you need on each recursion step is always going to be custom, so it'd be kind of hard to make one tag that could do it nicely (though I don't know how jinja does it, they tend to go waaaay beyond what the django template language is out to do).
comment:3 by , 17 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Collin's pretty much nailed it: the requirements for recursive display are too varied for a single tag. Each situation is going to need some customisation. Writing a custom tag really is the right approach and we've made that fairly easy to do.
comment:4 by , 17 years ago
(incidentally, you can avoid the spam filter entirely by registering an account for the Django Trac: http://www.djangoproject.com/accounts/register/)
Well, finally I seem to have convinced this system that the above is not spam. This has been a uniquely frustrating experience.