Hi Chris and Russ,
On 02/08/2014 05:11 PM, Russell Keith-Magee wrote:
>
> On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela
> <chris.medr...@gmail.com <mailto:chris.medr...@gmail.com>> wrote:
>
> Why not switching to Jinja2? I thought that somebody else proposed
> this idea
> but I couldn't find any discussion; so, please, point me to the
> discussion if
> the idea was discussed, otherwise let's discuss it!
>
> It's been proposed in jest, and it's been accepted in jest as well :-)
> However, I don't think there's been a serious proposal to this effect.
I've proposed it before, and not in jest. Though perhaps not fully
seriously either, as full seriousness would mean supplying a patch.
> The pros are obvious: 1) fast templates, 2) less code to maintain,
> 3) lot's of
> companies use Jinja2 (because of slowness of default template
> system) and
> builtin support for Jinja2 would be beneficial for them (thing about
> integrating Jinja2 with settings like TEMPLATE_DEBUG).
>
> Now the cons. First of all, one of the design decision is that
> Django has no
> dependencies. We can overwhelm it by "static linking" -- I mean
> copying Jinja2
> code into Django. At the first glance, it may look like a horrible
> idea, but
> think about it in a different way. If we don't switch to Jinja2, we
> have to
> maintain entire template system and fix every bug as well as
> implement new
> features. If we switch, Jinja2 developers can do this job for us. We
> only need
> to forward tickets to Jinja2 developers and update the static linkage.
>
> We're unlikely to vendor a copy of Jinja2. If we went down this road,
> we'd be much more likely to look at using dependencies defined in setup.py.
I agree.
> The second big problem is that switching is a big change and backward
> compatibility matters. We will need to support both the deprecated
> Django
> template system and the new one. However, it doesn't mean double
> work -- we
> don't need to implement new features for the deprecated system, only
> bug fixes
> will be required. Also note, that a lot of companies uses Jinja2 and
> switching
> from third-package Jinja2 to Jinja2-builtin-Django isn't an enormous
> change at
> all.
>
>
> Untrue. It *can* be a *very* big change. One of the biggest problems is
> backwards compatibility for custom template tags. There are a lot of
> these out there in the wild, and the way Django defines custom template
> tags is one of the major reasons that a bytecode approach to Django
> templates is difficult.
Yes. For this reason I think that any deprecation of DTL would need to
be very slow, if it was deprecated at all. Perhaps it could be moved
into an external project for continued use by legacy projects with large
bodies of custom template tag code.
> I'd like to hear your opinion. Feel free to comment!
>
>
> Personally, I'm -0 on this proposal as described.
>
> Although Jinja2 and Django template share a common base syntax, Jinja2
> includes a bunch of features that I'm not wild about. Django's templates
> are *deliberately* hobbled to prevent the injection of business logic
> into templates. Jinja2 template allow for function calls, array
> subscripting, and all sorts of other programming language structures.
> I'm not saying these things are inherently bad; I'm saying there's a
> reason why Django hasn't included them, and I'm not wild about the idea
> of switching to a default template language that allows them.
I don't buy this argument, for a number of reasons:
1) On the wider spectrum of Python templating languages, Django and
Jinja2's design philosophies are quite similar. Jinja2 does have a few
syntactic constructs that make it more powerful (which make it more
pleasant to work with, IMO), but over-emphasizing these is a case of the
narcissism of small differences. I would be opposed to switching to a
template language with a fundamentally different philosophy (i.e. one
that allows large blocks of pure Python code in templates, or one that
is tied to XML syntax), but I consider Jinja2 a strictly superior
implementation of essentially the same design philosophy as DTL.
2) DTL is indeed hobbled compared to Jinja2, but if the goal of this
hobbling is to "prevent the injection of business logic into templates",
it is a failure, and couldn't be otherwise, because the premise is
flawed. If a template developer has no interest in maintaining a clear
distinction between business logic and presentation logic, DTL gives
them far more than enough rope to hang themselves with; heck, all you
need is a functional {% if %} and you can easily put tons of business
logic into templates (and I've seen plenty of DTL-using projects that do
so.) Having worked on many projects using DTL and many using Jinja2, I
have observed no correlation between the template language used and the
amount of business logic that ends up in templates.
3) Not all logic is business logic. Presentation of data can also
require logic (sometimes non-trivial logic), and often this logic
belongs in the templates. DTL forces you to make choices between doing
presentation-related data transformation in view code (ick) or
implementing custom tags (using an API that is far too difficult and
low-level, resulting in a proliferation of confusingly similar built-in
decorators and third-party projects to attempt to paper over it with a
reasonable API) for simple things that would be more concise and
readable if done directly in the template. And when you do need to do
something in Python code, Jinja2's API for that could hardly be simpler
(define a Python function, make it available in the template context,
and call it), in stark contrast to DTL.
I also think Jinja macros result in clearer and more maintainable
template partials compared to using Django includes for the same
purpose, because macros are explicit about the context variables they
require. (The closest equivalent in Django is an inclusion tag, but
these are harder to work with than macros because the relevant
information to understand the inclusion tag is split up between a
snippet of Python code in one place and a template in another place.)
But mostly, I think the rendering speed alone is enough reason to switch
(given that we have good evidence from Armin's GSoC that getting DTL to
a comparable rendering speed while maintaining backwards compatibility
may not be possible). It's a problem that we are unable to do things
that would otherwise be no-brainers (e.g. rendering form widgets using
templates rather than by concatenating strings of HTML in Python code)
because our default templating language is too slow.
> I'd be a more supportive of two different spins on this project idea:
>
> 1) Try to pick up where the 2012 GSoC project left off, and continue
> the work to byte code compile Django's templates. However, this project
> is unlikely to get off the ground without a concrete proposal to get
> around the problems encountered the first time around.
I think this is unlikely to be successful, and not worth a second GSoC's
worth of effort when Jinja2 is already available.
> 2) Work on the internals of Django to decouple the template engine, so
> that (a), Django's template language is a standalone in the same way
> that Jinja2 is, and/or (b) there's a clean interface so that it's
> possible to define a clean Jinja2 module that you can drop into your
> Django stack.
>
> A good solution for (2) would set the groundwork for a *long term*
> transition to Jinja2 templates, but would also allow long term backwards
> compatibility, as the Django template language could be maintained long
> term, even if it is dropped as an officially supported option by Django
> itself.
This is basically the same approach that I would favor, although I would
immediately make Jinja2 the "blessed" option (i.e. the one used in the
tutorial and featured in the documentation), with DTL maintained (in or
out of core) only for backwards-compatibility for legacy projects.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/52F925A7.8000508%40oddbird.net.
For more options, visit https://groups.google.com/groups/opt_out.
