On Sat, 2007-11-17 at 20:49 +0300, Ivan Sagalaev wrote:
> Hello!
>
> I'm about to convert my apps to play well with recently introduced
> autoescaping but I have to confess that I don't get mark_safe, is_safe
> and needs_autoescaping.
>
> First, I don't get why .is_safe attribute is needed at all. If my filter
> returns any HTML I should escape it and mark_safe the result, no?
The is_safe attribute is a large time-saver when you're writing filters.
Normally, you'll just want auto-escaping behaviour to be applied
automatically and when writing a filter that doesn't add raw HTML markup
you should be able to just write the code without having to worry about
escaping. The only difficulty is when you pass a safe string into the
filter. It's very easy to end up with a result that isn't a SafeData
instance after a few string manipulations, so this isn't a trivial
issue. For many filters, the actions they perform won't remove that
safe-ness in effect, but they won't be a SafeData isntance. So Django
notes that the input was a SafeData and the function is marked is_safe
and, thus, it calls mark_safe() on the result so that you don't have to
in your filter (all other input is automatically escaped at the right
moment, since it isn't safe from further escaping).
Thus, is_safe: if True, you are are guaranteeing a safe input string
will always generate an output string that can be marked as safe (and
Django will automatically do that for you). If not True, it is up to you
to either mark the output safe manually or have it auto-escaped when
auto-escaping is in effect.
> Then, looking at default filters I see that .is_safe is set to False for
> all filters returning non-string values. Though these values are pretty
> safe for HTML when they would be converted into strings in the end.
For filters returning non-strings, is_safe is a no-op, so I just picked
a value. The reason False is better than True is because you don't even
have to bother adding is_safe to those types of filters ("absent"
defaults to False). Adding it won't harm anything, though.
> And 'needs_autoescape' escapes me absolutely... If I'm dealing with user
> content and HTML why, again, can't I escape it inside my filter's code
> and mark_safe it?
Because you wouldn't be able to write a filter that worked correctly in
both auto-escaping and non-auto-escaping environments, which is a
compulsory requirement in most cases. You don't want to escape inside
the filter if the current context doesn't have auto-escaping in effect.
The needs_autoescape attribute tells Django that your function needs to
be passed a parameter called "autoescape" that is the value of the
current auto-escaping effect (True or False).
Yes, you can ignore needs_autoescape if you're going to restrict your
filters to only working in an auto-escaping environment, but that's
highly non-portable (and certainly not an option in Django's core, for
example). Anybody distributing an application, for example, that was
designed to work with other peoples' templates and didn't allow for
auto-escaping to be either True or False at render time would have a bug
in their code.
> Anyway... Malcolm (as the main implementer), sorry, but the docs are
> written in Linux how-to style: "make these magic passes and hope for the
> best and don't try to understand the thing since you never will".
A little bit hyperbolic, even for somebody who's frustrated. It is never
the intention to say "you'll never understand this" and the current
documentation does not even come close to saying that. When writing
feedback, as welcome as it is, try to have some respect for the insane
number of hours that have gone into developing this and the amount of
nonsense it's generated. Consider, also, that documentation written by
the person doing the design and implementation offer does sometimes miss
some of the easier things because they're too easy by the time it's at a
state where the documentation is written and that person is too close to
things. This is just part of the ironing out problems phase.
Given the types of things people complain about not understanding in the
documentation (we always get requests to add things that are effectively
"warning: Python will behave as it normally does and gravity has an
effect on this planet."), if we go into all the fine details of how
things work, the effect gets lost in the implementation. So there's a
limit. Apparently you feel I've fallen short here, but it's going to be
very difficult to find the middle ground.
I'll have one more pass at it and after that I look forwards to reading
your patch to improve things.
> For example. I'm writing a filter that gets a string and wraps it's
> first letter in a <b>...</b>. I'm going to split the first letter,
> conditional_escape the letter and the rest, wrap a letter in <b>...</b>,
> concatenate and mark_safe. Now, should I stick .is_safe?
If you're always returning a safe string, then adding is_safe is a
no-op. The is_safe attribute is only a necessary consideration when you
aren't marking for manual safeness.
> Should I also
> ask for autoescape parameter and how am I supposed to use it?
If your input can contain non-safe strings, you'll need to accept it. As
to how to use it: test the value!! It tells you if autoescaping is in
effect. From the documentation:
When the filter is called, the ``autoescape`` keyword argument
will be ``True`` if auto-escaping is in effect.
> Ok, this was a bit messy but I honestly thought it should be easier :-)
Remember that I've managed to achieve what you said was impossible in
your original list of 10 things you hated about Django: auto-escaping is
implemented in a way that means that almost all code is very close to
backwards-compatible and filters and templates will work in both types
of environments, so people don't have to write two sets of filters and
two sets of templates for fragments that might be included in either
environment. The effort is required by the developer rather than the
template writer.
Regards,
Malcolm
--
Why be difficult when, with a little bit of effort, you could be
impossible.
http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
