On 11/17/07, Ivan Sagalaev <[EMAIL PROTECTED]> 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.
I'm also just getting started on learning this, but feel like I've got a reasonably good understanding from the docs and a bit of looking at the code, so I'll take a stab at answering. 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? >From reading the doc, I got the impression that is_safe is for filters that don't mark_safe their output, but that also do not do anything to introduce anything "unsafe" in their output. Therefore, if they are given a safe string on input, their output will be automatically marked safe. Setting is_safe to True for a filter that always mark_safe's its output appears to be a no-op -- the framework will call mark_safe a 2nd time on something that has already been marked safe, which is harmless. However, there are a few filters in defaultfilters.py that do in fact always return mark_safe'd output but also have is_safe set to True. I don't understand what that accomplishes so perhaps I am missing something here. 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. But they are not returning strings, they are returning ints (or lists, or whatever). If is_safe was set to True for these filters, then their output would automatically be marked safe whenever they were called with safe input, meaning whatever they were returning would be turned into a (safe) string, changing the type of their output. is_safe=True is for filters that return strings, not numbers or whatever else. 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? You said "dealing with user content", so you have in your mind that input your filter is given must be escaped. What if you were writing a filter that could operate on either user-generated (untrusted) input that does need to be escaped or trusted input that may contain HTML and should not be escaped? That's what needs_autoescape is for. It's for filters that are going to mark_safe their output but need to know whether or not their input should be escaped as they process it. They're producing something that will be exempt from further escaping, so they need to know the current autoescape setting in order to determine whether their input should be escaped as it is incorporated into their output, because this is that last chance for getting it escaped. > [snip] > > 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? Because yes, I > think it will return safe output given a safe string. What will break if > I didn't (my experiments so far show that nothing breaks). Should I also > ask for autoescape parameter and how am I supposed to use it? As I mentioned above, I don't believe it is necessary to set is_safe to True for a filter that mark_safe's it output, but I might be missing something there. As for whether you need to ask for autoescape -- is there any use case for your filter where its input could contain HTML that should not be escaped? If so, then you should ask for autoescape and only escape the input you are given if autoescape is on. Anyway, that's my take on it. Malcolm can correct where I've gotten things wrong. Cheers, Karen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
