Thanks for clarification! I have couple more things to iron out though...
Malcolm Tredinnick wrote:
> If we didn't have is_safe, every filter that did some kind of string
> manipulation such as input = intput + 'x' would need to end with lines
> like
>
> if isinstance(orig_input, SafeData):
> result = mark_safe(result)
> return result
>
> and they would have to remember to save the original input (or test its
> type very early).
Got it now. So if I understand correctly
- mark_safe means that filter takes full responsibility for its output
- .is_safe means that filter doesn't want to know details of its input
and thus takes responsibility only for its own additions
> Finally, auto-escaping is only appropriate for HTML text.
Yes, I've completely forgot about emails etc... :-( This now makes sense
why one might want to not escape and mark_safe output.
> However, some of your filters might still be
> useful in those sorts of sections. Imagine, for example, a filter that
> always replaced the word "and" by "&". It will need to behave
> differently in different auto-escaping contexts (use "&" in HTML
> templates, and "&" in email).
And this is a very clear example :-).
> I've rewritten most of the filtering and auto-escaping section (in
> [6692]). Have a read of it and see if it makes more sense from the point
> of view of where you were 24 hours ago. I've tried to approach it from a
> different direction, hopefully motivating things a bit more without
> getting us bogged down in unimportant details.
Yes, it really is better now! Thanks :-). There are a couple of small
points however:
> This attribute tells Django that is a safe string is passed into
your filter, the result will still be safe
I kinda think that emphasizing the safeness of input here is
distracting. I'd rather emphasize that ".is_safe" means that author
doesn't want to think of input very much and wants to let Django think
for him, and the details of how it will be done are not important. They
are still interesting though and might be noted afterwards. Something
like this (though it's a bit verbose):
This attribute tells Django that your filter works with
various input types and can only be sure that it doesn't
do any "unsafe" changes to it. Django will then decide if
the whole output needs to be escaped or not keeping track
of whether or not input was already safe.
Another thing is the example code of initial_letter_filter. I think it
can be written shorter and without lambda:
- if autoescape:
- esc = conditional_escape
- else:
- esc = lambda x: x
- result = '<strong>%s</strong>%s' % (esc(first), esc(other))
+ if autoescape:
+ first, other = conditional_escape(first), conditional_escape(other)
+ result = '<strong>%s</strong>%s' % (first, other)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
