> > I've thought about this a bit more; lots of good points have been
> > raised. What I'd like to do would be to add a new tag that takes
> > care of auto-escaping variables used within it. Something like::
> >
> > {% autoescape %}
> > Any {{ variables }} used within this {{ block }
Am 03.03.2006 um 18:53 schrieb Jacob Kaplan-Moss:
> Hey folks --
>
> I've thought about this a bit more; lots of good points have been
> raised. What I'd like to do would be to add a new tag that takes
> care of auto-escaping variables used within it. Something like::
>
> {% autoescape %}
Sounds good, but I just don't like the name. How about "escape", or
"escapeblock"?
And how about...
{% autoescape except "br,p,table" %}
?
On 3/3/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> Hey folks --
>
> I've thought about this a bit more; lots of good points have been
> rais
Max Battcher wrote:
> > the standard solution is to use a wrapper for strings that you
> > *don't* want escaped. see e.g. the section on "HTML templates"
> > on this page:
>
> The other problem is that not everyone wants the same escape. For
> instance, there are those of us that {% load markup
Hey folks --
I've thought about this a bit more; lots of good points have been
raised. What I'd like to do would be to add a new tag that takes
care of auto-escaping variables used within it. Something like::
{% autoescape %}
Any {{ variables }} used within this {{ block }}
Max Battcher wrote:
> On 3/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Jacob Kaplan-Moss wrote:
>>
>>> Why not do it for all variables? At times you want to pass chunks of
>>> HTML into a template that get displayed raw. I don't think the
>>> behavior you suggest should be default, but
On 3/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Jacob Kaplan-Moss wrote:
>
> > Why not do it for all variables? At times you want to pass chunks of
> > HTML into a template that get displayed raw. I don't think the
> > behavior you suggest should be default, but do you have any ideas
Jacob Kaplan-Moss wrote:
> Why not do it for all variables? At times you want to pass chunks of
> HTML into a template that get displayed raw. I don't think the
> behavior you suggest should be default, but do you have any ideas on
> how to make it optional?
the standard solution is to use a wr
Jacob Kaplan-Moss wrote:
> The problem in the admin was fixed in [1982]: http://
> code.djangoproject.com/changeset/1982;
thanks (and sorry--I'll start using the svn then)
> in your own templates you'll
> want to use the "escape" filter (http://www.djangoproject.com/
> documentation/templates/#
Gábor Farkas wrote:
> Jacob Kaplan-Moss wrote:
>> On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote:
>>> Now, did I miss something and is this already fixed? Should this be
>>> treated differently? How do other people handle this?
>>
>> The problem in the admin was fixed in [1982]: http://
>> cod
Jacob Kaplan-Moss wrote:
> On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote:
>> Now, did I miss something and is this already fixed? Should this be
>> treated differently? How do other people handle this?
>
> The problem in the admin was fixed in [1982]: http://
> code.djangoproject.com/changes
On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote:
> Now, did I miss something and is this already fixed? Should this be
> treated differently? How do other people handle this?
The problem in the admin was fixed in [1982]: http://
code.djangoproject.com/changeset/1982; in your own templates you'
Hi,
the behaviour of django for fields that contain html markup ("<" ...)
is wrong, at least in version 0.91.
First, the admin pages do not html escape these. There might be
corner cases when this is intended, but it seems very dangerous.
Second, regarding Template, I think the default not t
13 matches
Mail list logo
