On Tue, May 3, 2011 at 12:33 PM, Tai Lee <[email protected]> wrote: > On May 3, 9:43 am, Russell Keith-Magee <[email protected]> > wrote: >> This stems back to the design motivation of Django's template language >> -- you shouldn't be doing math in the template. Instead, you should be >> doing your math in the view, and providing the template with a >> pre-calculated result. >> >> So, my inclination would be to say no, this doesn't have a place in >> the default list of tags. > > If it a rule that people should never do math in the template, Django > wouldn't ship with add and divisibleby filters, possibly also the > widthratio template tag.
This is one of those unfortunate situations where I find myself trying to defending history. The catch here is that the add tag was added before Django was open sourced, so it's been grandfathered in. If an add tag were to be proposed today, I suspect it would be knocked back. I'm not sure I agree about divisibleby and widthratio, though. While these tags do math, they're not literal math functions -- they're tools that are needed to sort out display issues. In the same way that view logic shouldn't be in templates, display logic shouldn't be in the view. This is a subtle distinction, but an important one. > While the use case posted elsewhere in this thread is practically > unreadable, I think there are some legitimate use cases where it is > preferable to perform some simple maths in the template (presentation > logic). > > The times when I've wished for more than slightly more maths than an > "add" filter have been when iterating through data structures in the > template and displaying as tabular data. > > It's not very nice to first iterate through these structures in the > view (which may otherwise be lazy until accessed in the template) and > add extra attributes that relate to presentation to the object before > it gets passed to the template. > > Don't get me wrong, I don't think we need advanced maths capability. > But a little more than what we have now would be useful to some > template authors. I agree - the catch is capturing the actual use cases for that math that are "display" in nature, and expressing those use cases. I don't want to just have a "subtract" filter, but if someone can make a legitimate case for the reason why subtraction (or any other math function) is necessary to solve a display issue, I could support *that*. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
