On 8/2/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> I'm -1 for {% autoescape on %} and {% autoescape off %}.
> This is also like PHP magic_quotes!
No, it's not. PHP's magic_quotes is set at a higher level; because the
behavior will be on by default and the only mechanism to change it
will be a template tag, you don't run into the "is it on or off"
confusion that plagues PHP's magic_quotes setting -- you can safely
write a template and *know* that if you've altered the autoescape
behavior in that template, no other component can secretly "override"
you by flipping it back.
> How would it work together with template extending and including?
> To the end of current block?
> Would {{ block.super }} do autoescape?
> These questions also should be decided.
Please read the entire thread above -- autoescaping will not work at
the level of blocks; it will only work at the level of autoescaping or
not autoescaping the **entire** output of the template, meaning all
includes, all tag output and all child templates will be affected by
it. If you don't want autoescaping, simply turn it off in a base
template that all your templates inherit from, and you don't have to
worry about it.
> +1 if you add autoescape stack with {% autoescape pop %} or better {%
> noescape %} {% endnoescape %}.
I would give this a huge -1 because of the complexity it would
introduce; either the entire template should be escaped or the entire
template should not be escaped, period. Anything else is begging for
headaches as people try to guess about which parts of a template get
escaped automatically and which parts don't.
> For those who told about template-wise or total disabling autoescape -
> my idea is to add something like render_noautoescaped to
> django.shortcuts, noescape filter and autoescape middleware.
I would also be -1 on this; the sole means of control needs to be the
template system, not higher-level shortcuts, because a template author
**must** be able to assume that what's in the template is the sole and
absolute arbiter of escaping behavior. Again, anything else is begging
for headaches.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
