On Thu, 2010-11-04 at 17:24 +0100, Will Hardy wrote:
> I've attached a simple patch to the ticket [2] and would be happy to
> write tests and documentation if this approach is enough to overcome
> the "wontfix". Have I overlooked something?
I think the devil is in the details. If we go for a simple
implementation like this, the ugliness moves to trying to document it.
The basic objection I have is that all the builtin filters become
unreliable. It's difficult to come up with examples that don't
ridiculously sound contrived, but I'll try.
Suppose I am outputting RTF text. I have an escape function like this:
def rtfescape(value):
return value.replace('\\', '\\\\')
.replace('{','\\{')
.replace('}', '\\}')
i.e. backslashes and curly braces need escaping.
Suppose I have an input string "Joe's string". I should be able to mark
this as safe - it doesn't need escaping either for HTML or RTF. Or leave
it unmarked - it should make no difference.
Suppose also I have a template that uses 'addslashes' (for the sake of
argument, because I'm writing a RTF document that shows what the
'addslashes' filter does). That filter is marked 'is_safe', because it
only introduces slashes, which are not dangerous characters for HTML.
But they *are* dangerous for RTF.
Logically I would expect the following 3 to produce the same output:
1) I use mark_safe on my safe input string and use addslashes to add
the slashes
Template("{{ val|addslashes }}").render(
Context({'val': mark_safe("Joe's string")},
autoescape=rtfescape)
)
2) I don't use mark_safe on my safe input string and use addslashes to
add the slashes
Template("{{ val|addslashes }}").render(
Context({'val': "Joe's string"},
autoescape=rtfescape)
)
3) I manually 'apply' addslashes.
Template("{{ val }}").render(
Context({'val': "Joe\\'s string"},
autoescape=rtfescape)
)
But these do not produce the same output - 1 is different from 2 and 3,
and is not what I intend.
I know this still seems pretty contrived, but it is certainly possible
that people will want to use 'safe' or 'mark_safe' in conjunction with
custom escaping — I can think of plenty of examples of wanting to do
this with RTF, with custom filters or template tags or other code that
outputs RTF. And it would appear to work most of the time. But it would
break at some points, so when it comes to documenting this, you would
have to say something like:
If you use this functionality, please note that all of the builtin
filters may be subtly broken with respect to escaping, depending on
what your escaping function does, if you ever use 'safe' in your
templates or 'mark_safe' in your code.
With that caveat, I'm not convinced this is still a beautiful patch! As
Chris and I seem to have a difference of opinion about this, what do
other people think?
(BTW, the patch needs to be extended to alter DebugVariableNode,
otherwise it produces different output with DEBUG=True)
Luke
--
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.
