Hi Luke,

> First, you depend only on the name of the function - so one that shadows
> a builtin filter won't be treated correctly (as you noted on the
> ticket).

This is true, I really hated this bit. The only thing that might work
is "libraryname.filtername" if it's possible to identify exactly which
filter was meant at runtime (the libraryname would be the same as that
used in {% load %} ). Even then it's functionality could depend on
the installed apps, which is just wrong.

> Second, when you are defining an autoescape function you have to know
> all the filters it will ever be used with. This is just as ugly a
> constraint as the problem it is trying to fix.

Not quite. The 'proper' way to do this is to have the filter define a
matching "autoescape context". The whitelist is only really there for
convenience, to let you use filters from other contexts (ie the
default django ones, external ones), without writing new ones.

If you wrote the filter, you can define the "autoescape context". If
you only wrote the escape function, you can define the whitelist. If
you wrote neither and they are for different "autoescape contexts",
you can use the "|safe" filter in the template.

> Third, although we can fix the filters in your 'group 2', you can't fix
> 3rd party filters like this. If we don't fix them, we still have caveats
> that we have to add to the docs - "Be aware that any filters/tag not
> bundled with Django may be broken with respect to autoescape" etc.

This is true, I don't see any way around this.

> Overall, with this addition, the whole thing actually gets harder to
> understand and document, and just feels like a hack. That kind of thing
> is acceptable to fix existing bugs, but not for new features IMO.

Agreed. I'll leave the ticket be for now, I don't really want to
distract anyone from 1.3 work. If I can think of a cleaner way of
doing this, I'll have another look at it after 1.3 is out.

Cheers and thanks for your time,

Will

-- 
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.

Reply via email to