Re: Proposal: Let Context handle template loading (#7815)

[Malcolm Tredinnick]

On Wed, 2008-09-24 at 16:34 +0200, Johannes Dollinger wrote:
[...]
> tpl.render(Context({}, loader=PrefixLoader(['a', 'b', 'c'])))
> }}}
> 
> This would fix #2949, #3544, #4278, #6834, and #7931. But it's a  
> backwards incompatible change: If you rely on compile time side  
> effects (e.g. {% load %}) in included templates, that will break.
> 
> Opinions?

-1 from me, since it's backwards incompatible. It looks like most of
those feature requests (or at least the ones that are worth doing --
it's not clear that things like #3944 are worth it) can be done without
backwards incompatible behavioural changes.

The template context is the static rendering context, not the
compiling/loading context and it feels like this is blurring that
boundary.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Let Context handle template loading (#7815)

[Johannes Dollinger]

I should have made this more accessible ..

http://code.djangoproject.com/ticket/2949
"I want to be able to set the path to a directory that contains the  
templates I want to render at runtime. [...] The basic thing I'm  
looking for is to be able to load a template from a specific,  
arbitrary path and then tags like extends and include should load  
templates from the same directory."

http://code.djangoproject.com/ticket/3544
"Fix {% include %} to allow recursive includes" - ConstantIncludeNode  
is the problem.

http://code.djangoproject.com/ticket/4278
"get_template should accept a dirs argument" - `dirs` kwargs could  
still be useful, but `render_to_*(... , dirs=)` could be handled with  
a custom `loader` for `context_instance`.

http://code.djangoproject.com/ticket/6834
"Add support for templates to be loaded from dynamically-selected  
directories" - a more focused version of #2949.

http://code.djangoproject.com/ticket/7931
"Debug mode causes template includes to be parsed regardless of if  
tags" - yet again, ConstantIncludeNode is the problem.

--
Out of scope for now but mentionable: This could be used for simple  
marcos if Context allowed external population of its cache:

{% sub "braces.sub" %}
 {% templatetag openbrace %} {{ content }} {% templatetag  
closebrace %}
{% endsub %}

{% include "braces.sub" %}
or with #7817:
{% include "braces.sub" with foo as content %}


Am 24.09.2008 um 16:34 schrieb Johannes Dollinger:

>
> #7815[1]:
>
> * Adds a loader kwarg to Context which should be something with a
> get_template(name) function. Default would be django.template.loader.
> * Provides get_template() and select_template() methods on Context.
> These are used in {% include %}, {% extends %} and inclusion_tag.
> * Caches templates in Context.
> * Removes ConstantIncludeNode since caching provides the same
> benefits and it causes problems with recursive includes.
>
> An example:
> {{{
> # emulate select_template for include/extends:
> class PrefixLoader:
>  def __init__(self, prefix_list):
>  self.prefix_list = prefix_list
>  def get_template(name):
>  from django.template.loader import select_template
>  return select_template(['%s/%s' % (prefix, name) for prefix
> in self.prefix_list])
>
> tpl.render(Context({}, loader=PrefixLoader(['a', 'b', 'c'])))
> }}}
>
> This would fix #2949, #3544, #4278, #6834, and #7931. But it's a
> backwards incompatible change: If you rely on compile time side
> effects (e.g. {% load %}) in included templates, that will break.
>
> Opinions?
>
> [1] http://code.djangoproject.com/ticket/7815
>
>
> >



--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---

Proposal: Let Context handle template loading (#7815)

[Johannes Dollinger]

#7815[1]:

* Adds a loader kwarg to Context which should be something with a  
get_template(name) function. Default would be django.template.loader.
* Provides get_template() and select_template() methods on Context.  
These are used in {% include %}, {% extends %} and inclusion_tag.
* Caches templates in Context.
* Removes ConstantIncludeNode since caching provides the same  
benefits and it causes problems with recursive includes.

An example:
{{{
# emulate select_template for include/extends:
class PrefixLoader:
 def __init__(self, prefix_list):
 self.prefix_list = prefix_list
 def get_template(name):
 from django.template.loader import select_template
 return select_template(['%s/%s' % (prefix, name) for prefix  
in self.prefix_list])

tpl.render(Context({}, loader=PrefixLoader(['a', 'b', 'c'])))
}}}

This would fix #2949, #3544, #4278, #6834, and #7931. But it's a  
backwards incompatible change: If you rely on compile time side  
effects (e.g. {% load %}) in included templates, that will break.

Opinions?

[1] http://code.djangoproject.com/ticket/7815


--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---