Proposal: Add some extensibility / decoupling features to Django templates
119 views
Skip to first unread message
Yo-Yo Ma
Jun 23, 2012, 8:17:28 PM6/23/12
to django-d...@googlegroups.com
I'll start with an example:
Using Jinja2, I can create an environment which is pretty secure (no access to anything but built-ins and objects explicitly marked "safe"), and provide a loader who's templates are loaded from the database (e.g., ``request.client.template_set.all()``), and customize all this for a single request (Since I can simply instantiate an ``Environment`` per request with a custom ``Loader`` which has access to only the ``request.client`` templates). I can also customize the extensions on a per-request basis (that's sort of analogous to customizing template tag/filter built-ins), in order to limit or add to the type of tools that clients have access to.
Using Django templates, I'm left with simply running my clients' sites portion of the app under a different settings file. This *almost* cuts it too (since I can use a different URL conf which includes different template.add_to_builtins() calls, etc.), but it doesn't give me all the things that I need, like the ability to instantiate the loader with a queryset of templates for the ``request.client``, etc.
"Why don't you just use Jinja2 then?"
The Django core team is a pretty intelligent team, and the philosophy behind the style of tags / filters / lack of logic in Django templates is far superior to Jinja2. I simply want a more Jinja2-ish Python API for using Django templates.
My Proposal (abstract explanation, btw, I'd be happy to help architect / write code):
Without changing any of the existing functionality or settings in Django, refactor the template system to use an ``Environment`` class (something akin to Jinja2's ``Environment``) which takes a list of loaders, and a number of other arguments. Then, instantiate this class, using the provided settings, and use it for all the default functionality (the admin, render_to_response, CBV template access, etc.). This would allow developers to make their own ``Environment`` instance with different arguments, request-specific or otherwise, and without having to do a lot of evil things.
Thanks
Fellow Djangonaut
Using Jinja2, I can create an environment which is pretty secure (no access to anything but built-ins and objects explicitly marked "safe"), and provide a loader who's templates are loaded from the database (e.g., ``request.client.template_set.all()``), and customize all this for a single request (Since I can simply instantiate an ``Environment`` per request with a custom ``Loader`` which has access to only the ``request.client`` templates). I can also customize the extensions on a per-request basis (that's sort of analogous to customizing template tag/filter built-ins), in order to limit or add to the type of tools that clients have access to.
Using Django templates, I'm left with simply running my clients' sites portion of the app under a different settings file. This *almost* cuts it too (since I can use a different URL conf which includes different template.add_to_builtins() calls, etc.), but it doesn't give me all the things that I need, like the ability to instantiate the loader with a queryset of templates for the ``request.client``, etc.
"Why don't you just use Jinja2 then?"
The Django core team is a pretty intelligent team, and the philosophy behind the style of tags / filters / lack of logic in Django templates is far superior to Jinja2. I simply want a more Jinja2-ish Python API for using Django templates.
My Proposal (abstract explanation, btw, I'd be happy to help architect / write code):
Without changing any of the existing functionality or settings in Django, refactor the template system to use an ``Environment`` class (something akin to Jinja2's ``Environment``) which takes a list of loaders, and a number of other arguments. Then, instantiate this class, using the provided settings, and use it for all the default functionality (the admin, render_to_response, CBV template access, etc.). This would allow developers to make their own ``Environment`` instance with different arguments, request-specific or otherwise, and without having to do a lot of evil things.
Thanks
Fellow Djangonaut
Jacob Kaplan-Moss
Jun 24, 2012, 5:50:42 PM6/24/12
to django-d...@googlegroups.com
On Sat, Jun 23, 2012 at 7:17 PM, Yo-Yo Ma <baxters...@gmail.com> wrote:
> Without changing any of the existing functionality or settings in Django,
> refactor the template system to use an ``Environment`` class (something akin
> to Jinja2's ``Environment``) which takes a list of loaders, and a number of
> other arguments. Then, instantiate this class, using the provided settings,
> and use it for all the default functionality (the admin, render_to_response,
> CBV template access, etc.). This would allow developers to make their own
> ``Environment`` instance with different arguments, request-specific or
> otherwise, and without having to do a lot of evil things.
Sounds great - I'd love to see a patch!
> Without changing any of the existing functionality or settings in Django,
> refactor the template system to use an ``Environment`` class (something akin
> to Jinja2's ``Environment``) which takes a list of loaders, and a number of
> other arguments. Then, instantiate this class, using the provided settings,
> and use it for all the default functionality (the admin, render_to_response,
> CBV template access, etc.). This would allow developers to make their own
> ``Environment`` instance with different arguments, request-specific or
> otherwise, and without having to do a lot of evil things.
Jacob
Alex Gaynor
Jun 24, 2012, 6:02:05 PM6/24/12
to django-d...@googlegroups.com
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
This is a good idea, I think there's even a ticket (probably, but not definitely filed by either myself or Carl Meyer) on this!
Alex
--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
ptone
Jun 27, 2012, 5:21:11 PM6/27/12
to django-d...@googlegroups.com
On Sunday, June 24, 2012 3:02:05 PM UTC-7, Alex_Gaynor wrote:
On Sun, Jun 24, 2012 at 2:50 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
On Sat, Jun 23, 2012 at 7:17 PM, Yo-Yo Ma <baxters...@gmail.com> wrote:Sounds great - I'd love to see a patch!
> Without changing any of the existing functionality or settings in Django,
> refactor the template system to use an ``Environment`` class (something akin
> to Jinja2's ``Environment``) which takes a list of loaders, and a number of
> other arguments. Then, instantiate this class, using the provided settings,
> and use it for all the default functionality (the admin, render_to_response,
> CBV template access, etc.). This would allow developers to make their own
> ``Environment`` instance with different arguments, request-specific or
> otherwise, and without having to do a lot of evil things.
Jacob
--
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+unsubscribe@googlegroups.com.
This is a good idea, I think there's even a ticket (probably, but not definitely filed by either myself or Carl Meyer) on this!Alex
Indeed there is:
-Preston
Reply all
Reply to author
Forward
0 new messages