To better detail the "in the model" idea: An additional field type would be added, extending CharField, called say "HTMLSafeField". It would strip/escape/convert/reject invalid strings both when being set and when being read. Otherwise it would behave just like a CharField.
The key is not to think of it as an escaping mechanism; simply as a data validity check. And there is ample precedence for this in Django. What are EmailFields, PhoneNumberFields and SlugFields if not simply CharFields that match a regex? "Intro" users who are not able to grok XSS can simply be told to always use HTMLSafeFields instead of CharFields. Converting existing apps would be simple model-only search-and-replace exercises. Folks who don't like wrapper tags around all variables in templates will be appeased. (as will those who don't want "escape=on" tags at the top of every template) And I (and my like-minded kin) who think both "breaking every template==bad" and "magic behind the scenes==worse" will not vomit at the addition. Likewise XMLSafeField, JavascriptSafeField, MustMatchUserRegexField, etc. would be logical extensions. The biggest downside is if you want valid HTML data stored for one output type and escaped for another. But this is not a scenario I've ever seen in the real world, and regardless is easily worked around with simply returning to CharFields for that one attribute. (and manually escaping of course) What do you think? -- Derek --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
