> Reading over the discussion, I'm in the same camp as Luke. I can see > the use case, but I see a bunch of sharp edges that will end up biting > the user in unexpected ways.
Thanks for dropping by :-) I think I've managed to remove the sharp edges. The main problem in this thread is that the default filters were written in the html context and their interaction with autoescaping breaks down when a different escaping context is required. I believe the solution would be to simply declare the html filters as "unsafe" and I've uploaded a patch [1] to the ticket that would do that. I've included a detailed description of the approach on the ticket [2]. All filters appear to be correctly handled in the new approach described there. If you think this approach is sensible, I'll edit the group 2 filters to use the custom escape function (they mostly take the autoescape argument anyway). There are a small number of tests on the ticket, but if this is something that might be in core, then I'll write some more comprehensive tests and documentation. Cheers, Will [1] <http://code.djangoproject.com/attachment/ticket/14057/14057-context-parameter-2.diff> [2] <http://code.djangoproject.com/ticket/14057#comment:7> -- 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.
