On Thu, 2010-11-04 at 19:06 -0700, SmileyChris wrote:
> Thanks for following up, Luke.
>
> I understand your point of view, but personally, I'm fine with an "all
> bets are off using built-in filters/tags" clause on a custom escape
> method.
> While you'd expect that addslashes would just work, I'd take the
> opposite expectation and assume that any filter / tag used would have
> to be custom built for a custom escape method.
I think that you and I probably see the problem immediately, but someone
less familiar with the template system is much more likely to be
confused and caught out. We are about level 2 on the Rusty API's Design
Manifesto [1] - you have to read the docs to see that there is a
problem, and then read the implementation of the filters (and think
quite hard) to know whether they can be used safely or not.
> Just clarifying my point of view (in that I had thought of this
> caveat).
> I too would like to know other's thoughts.
Thanks for that clarification.
It occurs to me that one technique that could improve the situation is
loading a custom template tag library that overrides the builtin filters
and tags. Such a library should be fairly straightforward to build do
'from django.template.defaultfilters import *' or equivalent, override
the ones that need fixing, and register your new filters under a new
library. But identifying the ones that need fixing for your case is
perhaps a lot of work, and it would be easiest not to bother, so I can
imagine people getting stung.
In some cases the builtin filters are actually HTML specific with
respect to what they add e.g. linebreaks, unordered_list. These are
also obvious candidates for shadowing with a custom template tag library
that does the right thing.
There also remain some usage warts. To use a different escaping, I have
to remember to pass in the autoescape function to Context *and* adjust
the template by adding a {% load whatever %} to get the filters that are
fixed for my use case. I could also easily forget the second, and find
that my template works most of the time.
Part of my reluctance is that if we started from scratch with support
for custom escaping in mind, we probably wouldn't do it this way. We
already have enough things in Django where we are stuck supporting
something due to an old design decision, and I would like to avoid
adding another wart when we have the option of just not adding it :-)
Regards,
Luke
[1] http://sweng.the-davies.net/Home/rustys-api-design-manifesto
--
"I imagine bugs and girls have a dim suspicion that nature played a
cruel trick on them, but they lack the intelligence to really
comprehend the magnitude of it." (Calvin and Hobbes)
Luke Plant || http://lukeplant.me.uk/
--
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.
