On Wed, Dec 30, 2009 at 10:25 AM, Nic Pottier <nicpott...@gmail.com> wrote: > On Dec 30, 8:55 am, Alex Gaynor <alex.gay...@gmail.com> wrote: >> I'd highly recommend watchinghttp://www.youtube.com/watch?v=tscMnoS4YU8in it >> this *exact* question >> comes up and Russ, Malcolm, and a few other people discuss the pros >> and cons of adding new template tags/filters. >> >> Alex > > Thanks, that's a useful link. The relevant portion starts at ~15:00 > for those that are interested. > > But really, the sum total of that discussion with regards to truncate > seemed to be: > 1) truncate doesn't exist because it wasn't useful in Journalism > 2) you can add it yourself > 3) we cover 80/20 > > What it explicitly doesn't say is that there is a huge cost to having > a new filter in core. > > Don't get me wrong, I absolutely agree on the 80/20 principle, and on > that a clean and simple interface is hugely valuable. (The PHP mess is > a clear counterpoint here) > > But I disagree that truncate is somehow an esoteric filter. RoR has > it, Smarty has it, as do countless others, it just isn't that > unusual.
What I haven't seen yet for this filter is a clear use case. If you're just trying to get something working quickly, then slice is fine. When you're ready to go back and do it right, then the optimal solution is to use CSS [1]. If you only want to truncate at word boundaries, then you'll just use truncate_words. What requirement does a truncate filter satisfy that these other solutions don't? [1] http://mattsnider.com/css/css-string-truncation-with-ellipsis/ Ian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
