I must admit to being conflicted on this project.
I'd love to see the measurements and profiling involved in establishing how
much "faster" Jinja2 is, mostly to see where DTL could do with some love...
However, I don't believe for most people their templates represent enough
of a time cost to make this project worth it. Certainly, in every project
I'm involved in, it's typically the actual work that takes most of the
time. Add caching loaders and fragment caching, and, well...
For people where it is, Django already supports pluggable template engines
through Loaders... which also solves the "how to distinguish" problem...
--
Curtis
On 25 February 2014 09:43, Christopher Medrela <chris.medr...@gmail.com>wrote:
> I've made some benchmarks. The results are:
>
> jinja2 empty for 0.028 s
> jinja2 include 1.094 s
> django empty for 0.435 s
> django include 2.134 s
>
> Where "empty for" is an empty loop repeated 50 times:
>
> {% for i in range_ %} {% endfor %}
>
> And include is a similar template where the loop body includes another
> template
> (which is empty) inside for loop:
>
> {% for i in range_ %}{% include "i" %}{% endfor %}
>
> The full code is available here: http://pastebin.com/DWjE1axV
>
> Note that including is only 1.5x faster in Jinja2 compared to Django.
> Surprisingly, the main speedup is in executing for loop (19x), not it's
> body.
>
> On Friday, February 21, 2014 11:07:30 PM UTC+1, Kevin Christopher Henry
> wrote:
>>
>> Hi Christopher,
>>
>>
>>> ... checks the template extension and dispatch to
>>> corresponding function from `django.dtl` or `jinja2`.
>>>
>>
>> The mechanism for distinguishing the two kinds of template needs to be
>> more flexible. For example, let's say I want to override a third-party
>> template with my own Jinja template. In that case I need to use the same
>> name (.html and all), but I want it to be processed by Jinja. The way
>> django-jinja solves this is with a setting that provides a regular
>> expression to determine which template names get processed by Jinja. That
>> may not be the best way (I can imagine that regular expression getting
>> hairy with a lot of "or" clauses), but just looking at file extensions
>> isn't enough.
>>
>
> Unfortunately, you're right. So I will follow Aymeric Augustin's idea: at
> the
> beginning of every template there will be "{# syntax: django #}" or "{#
> syntax:
> jinja2 #}". If the template lacks such declaration, django template is
> assumed.
>
> I don't have a comment on the merits of your approach to inheriting from
>> DTL templates, but personally this is not something I've ever needed to do.
>> I'm sure there are use cases for this, that's just my experience.
>>
>> By contrast, something that I very often want to do is use third-party
>> Django template tags in my Jinja2 templates. Right now there's just no way
>> to do that (that I know of). So, if you're taking requests, please solve
>> that problem. :-) And if you're forced to prioritize, I think that would be
>> more useful than being able to inherit from DTL templates.
>>
>
> What kind of support do you except for third-party template tags? Suppose,
> that
> `cycle` tag is not builtin. Would it be acceptable to write sth like that:
>
> dtl cycle '1' '2' as rows
>
> It could be quite easily implemented as a Jinja2 extensions. Of course, I
> guess
> that you'd prefer this style:
>
> cycle '1' '2' as rows
>
> Unfortunately, it cannot be done easily. Each of template tags should map
> to a
> new Jinja2 extension. But the list of extensions must be given to
> `Environment`
> constructor and cannot be changed (at least this is what documentation
> says).
> What can we do?
>
> 1) We can tamper with Jinja2. Maybe it is possible to change list of
> extensions
> after environment creation? I will investigate it.
>
> 2) We need to know all template tags before rendering first template. All
> tags
> will be available in all templates. The drawback is that you have no
> modules
> that you can `load` when desired.
>
> BTW, what about built-in template tags? Are there any issues?
>
>> --
> 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/ecf638ce-5811-4234-bd40-964178763090%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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/CAG_XiSDfQObcPB9oEzUCuMqLGcZC-qOQvd4UpN0oMvUEzyxgpg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
