Malcolm Tredinnick wrote: > When a variable is evaluated in a context in a template, it is > considered to be either "safe" or not (Simon used the term "escaped", > but that seemed less universally true than "safe").
As long as we're discussing terminology, might as well enumerate the situations where we'd want the terms to be applicable: Sources: 1. Ordinary string, not intended to have HTML in it, but may have &s or <s 2. HTML code string (obviously contains markup) Actions taken: A. String is output without processing B. String is output by substituting entity references for special characters Examples: 1A: We'd use this if our template was for a text/plain document, or some other non-HTML non-XML document. 1B: The normal case for strings as the content of an HTML page. 2A: This is the case we use when the string contains markup, say the output from textile. 2B: This is the case when we're outputting an HTML-formatted RSS feed, or outputting the content for a textarea that's used for editing HTML. As far as the terms "safe" and "unsafe" go, they really only describe 1B, and make very little sense for 1A and 2B. "escaped" and "raw"/"unescaped" apply in all four, as they're stating that the string has passed through an "escaping" process. The names for the string classes are a different situation again; e.g. a SafeString is not really safe, but will be made so -- the name UnescapedString isn't much better. RawString? Andrew --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
