Simon Willison wrote:
> 
> On 19 Jun 2006, at 21:00, [EMAIL PROTECTED] wrote:
> 
>> anyway, i suppose i will wait for you to elaborate on your  
>> reasoning in
>> the wiki this evening.  :)
> 
> I've written up a proposal for how we can implement auto escaping  
> while hopefully keeping most people happy:
> 
> http://code.djangoproject.com/wiki/AutoEscaping

I like much of this stuff.

Here some further ideas:

I don't like the {% endautoescape %} just to print a unescaped variable.
Maybe the idea of the python string type prefix would help here and
would allow further improvments to be implemented nicely (thinking about
unicode problems...)

{{r#somevariable}} or {{r:somevariable}}

Even the last one looks strange at first, but is logical under the idea
that r ist just like any other function and generates a escapedstr out
of a string, or escapedunicodestring out of a unicode

2. Currently the autoescape, or better escape in general escapes <>, etc.
But what if you have some different type of output, then you have to do
everything by hand or write other filters, but could be messy.

{% escape_type tex|cvs|something... %}

would set a reference to the escape function of this template instance,
which is default to html. escape and autoescapestring would use this
reference instead of fixed coded escape function. This would allow to
write clean templates, with nearly no bloat in implementation.

kindly regards
  Daniel

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to