James states things different from what is currently in the wiki [1] I am firmly +1 on what is described there: - autoescaping can be turned off (or on) at the block level - strings can be marked to prevent them from getting escaped - views may switch autoescape off by setting an attribute on the context
Is this all out-of-date information? Best regards Niels [1] http://code.djangoproject.com/wiki/AutoEscaping#Autoescaping On Aug 3, 1:14 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
