Malcolm, first of all, I should apologies. I actually intended my letter
being 'funny' but after your answer I understand that it was just harsh
:-(. I'm sorry. And let me again express that I never stopped to wonder
how you manage to do so many great things in Django. Thank you very much!
Still I believe that my dumbness in understanding new filters is a good
use-case to work out since I understand other Django docs well. So here
goes...
Malcolm Tredinnick wrote:
> 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.
Got it. If I do SafeString('test') + 'test' the result will be a str,
not SafeData.
> 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
This is my first misunderstanding. mark_safe seems trivial enough, why
not just use it instead of .is_safe=True on a filter?
Looking at this from template/__init__.py:
if getattr(func, 'is_safe', False) and isinstance(obj, SafeData):
obj = mark_safe(new_obj)
they're essentially equivalent modulo type checking. Why doesn't
mark_safe do type checking itself?
> 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.
Uhm.. This is the second thing I'm missing. I though that {% autoescape
off %} is a backward-compat measure. So .needs_autoescape exists only
for filters that used to do non-safe output and should behave as such in
a non-autoescaped environment. And I thought that in a new era all new
filters and tags actually should *always* return safe values. No?
> I'll have one more pass at it and after that I look forwards to reading
> your patch to improve things.
I will certainly try to do this.
>> 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.
Yes, but *should* I always return a safe string? I believe in my case I
really should because I'm returning some HTML and nothing after my
filter could magically decipher it and escape parts of the string that I
didn't escape. Right?
If yes, does it mean that I should use .need_autoescape to know if my
input was already escaped manually (if autoescape is None) or I should
do it myself (is autoescape == True)?
> Remember that I've managed to achieve what you said was impossible in
> your original list of 10 things you hated about Django:
Uhm... Originally it was "'N things I don't like..." and I called it a
"hate-list" as a joke :-). And actual wording about autoescaping was
that "it's now impossible to fix the easy way so it has to be fixed the
hard way". As far as I understand this indeed was hard.
Thanks for your answer!
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
