On Jun 21, 3:55 pm, Luke Plant <l.plant...@cantab.net> wrote:
> On 21/06/11 20:07, Mike Samuel wrote:
> > I'd like to add contextual autoescaping to django templates.
>
> > Briefly, it would automatically pick filters for each {{variable}} by
> > looking at the context in which it appears.  So inside a <script>
> > body, it might convert a value to a valid bundle of JSON; but inside
> > the query part of a URL, it would %-encode.
>
> > You can play with a runnable example at
> >http://js-quasis-libraries-and-repl.googlecode.com/svn/trunk/index.html
> > .  Just choose one of the "Safe HTML" examples from the dropdown at
> > the top right and hit enter.  There is a detailed writeup based on
> > experience from another template language at
> >http://js-quasis-libraries-and-repl.googlecode.com/svn/trunk/safetemp...
> > .
>
> > Would anyone be interested in such a thing for Django?  If so, how
> > should I proceed?  Is there a mechanism in the templates API that
> > would allow an optional pass to analyze a bundle of templates and add
> > filters?
>
> I have a brief look, and concluded that the approach outlined is
> probably impossible for Django templates. The main reason for this is
> that the grammar of Django templates is extensible via template tags.
> This would probably make it impossible to do the static analysis
> required. There might be other problems too.

I don't think custom tags are that big a problem.  If I understand
correctly, part of the custom tags work happens at compile time, and
part at render time.

If the contextual analysis happens at compile time, after custom tags
do their compile time work, then it can make reasonable assumptions
about what happens at compile time:

  (1) That a custom tag ends in the same context it appears.  I can
probably be stricter -- a custom tag that appears in a context other
than PCDATA is an error -- and see if real code obeys that
restriction.
  (2) That a custom tags content is PCDATA unless it contains hints
saying otherwise.



> If you wanted to proceed anyway, the way to do it would be to write a
> custom template loader and have it do the pre-pass. This could be
> written as a third party library.

That sounds lovely.  So I would write a loader that wraps another
loader, and have it modify the output of that loader?

Is there a good example of a loader that does such a thing?   Some
quick searching turns up django.template.loaders.cached.Loader which
seems to delegate the work of turning bytes in storage into templates
to other loaders, but is there an example that both delegates and
transforms?


> Regards,
>
> Luke
>
> --
> "Our software is idiot proof.  If you bought it, that's proof
> you're an idiot" (Dogbert)
>
> Luke Plant ||http://lukeplant.me.uk/

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to