Hi another time,
I am tring to reply every people in this email:
Josh
I was not using django.template.loaders.cached.Loader, but the result are
very similar i.e:
App Template Num templates rendered before unify Num templates rendered
after unify AVG Time render template before unify (ms) AVG Time render
template after unify (ms)
Django admin admin/index.html 3 1 80 70
Django constance admin/constance/change_list.html 7 1 330 180
Django su su/login.html 5 3 10 5
Pavlos:
1. Yes, I wrote this email to contribute another time. Actually I am
already Django contributor[1][2]
2. I didn't share my code, because it is not a nice code. *For me it is
a teoric question. I don't want anybody have a bad opinion of this proposal
for the implementation*. But I am sharing [3] it without problems, but
please I know this solution is incomplete for many reason.
3. About your question: "I am not sure I understood anything so far. Are
you just pre-rendering {% include %} tags, so the template engine doesn't
have to do that in runtime?" Yes :-)
4. About it: "I think what you did is addressed more neatly with the
django.template.loaders.cached.Loader, as Josh Smeaton mentioned." and
"Experimenting like this, even if you end up rediscovering something that
exists" It is something different than django cache loader, of course I
know django cache loader, I fixed a problem with django cached loader [4]
five years ago :-). With django cache loader, we get django get a template
quickly. But If your view finally render 3 templates, django cached loader
will have to get 3 templates (from cache). With my proposal your view
render only 1 template (This is not 100% true, 1 + templates about
templatetags except extends and include)
Jani:
Currently you only need move the new template result to the old path of the
template. But it is only because I want. If you change this line [5] for
this other you don't need any change:
destination_name = template.origin.name
8 years ago I requested a feature related with templates, now I have a new
request :-) 8 years ago I tried resolved my proposal, now I only want
propose something :-D
I think in this change for Django :-)
REF's
1.
https://github.com/django/django/pulls?q=is%3Apr+author%3Agoinnn+is%3Aclosed
2.
https://code.djangoproject.com/query?status=assigned&status=closed&status=new&reporter=~pmartin&col=id&col=summary&col=status&col=owner&col=type&col=component&col=version&desc=1&order=id
3. https://gist.github.com/goinnn/8a42314fccdd13bcf4df256a277ec1f6 (tested
in Django 1.8 - 1.11)
4.
https://github.com/django/django/pull/1936/commits/e669bca5c8fe6d13ea745d338203cd9e7470ae6b
5.
https://gist.github.com/goinnn/8a42314fccdd13bcf4df256a277ec1f6#file-unify_templates-py-L58
6. https://code.djangoproject.com/ticket/15053
Best,
El vie., 18 ene. 2019 a las 14:11, Jani Tiainen (<rede...@gmail.com>)
escribió:
> Hi.
>
> Does this require changes to django internals or can it work as an
> external package?
>
> Also you should release it as a package so people can start using it, also
> preferably releasing it with BSD license like Django itself is. Otherwise
> there are very little chances that your solution would make to django it
> self.
>
> Improvements to rendering are always welcome, but they must come without
> too much maintenance burden.
>
> On Thu, Jan 17, 2019 at 11:02 AM J. Pablo Martín Cobos <goi...@gmail.com>
> wrote:
>
>> Hi,
>>
>> From one year ago, I am using an own command for Django templates that
>> unify them. With an example it is easy to see. If I am to render for
>> example a template call news.html like it:
>>
>> 1. news.html
>>
>> {% extends "base.html" %}
>>
>> {% block title %}
>> {% include "inc.news.title.html" %}
>> {% endblock %}
>>
>> {% block content %}
>> {% for news_item in news %}
>> <h2>{{ news_item.title }}</h2>
>> <p>{{ news_item.subtitle }}</p>
>> {% endfor %}
>> {% endblock %}
>>
>> 2. base.html
>>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "
>> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
>> <html xmlns="http://www.w3.org/1999/xhtml"; lang="{{
>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>> %}>
>> <head>
>> <title>{% block title %}{% endblock %}</title>
>> </head>
>> <body>
>> {% block content %}{% endblock %}
>> </body>
>> </html>
>>
>> 3. inc.news.title.html
>> News
>>
>> With this command I preproces every template of a settings variable and I
>> get something like this:
>>
>> news.unify.html
>>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "
>> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
>> <html xmlns="http://www.w3.org/1999/xhtml"; lang="{{
>> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
>> %}>
>> <head>
>> <title>News</title>
>> </head>
>> <body>
>> {% for news_item in news %}
>> <h2>{{ news_item.title }}</h2>
>> <p>{{ news_item.subtitle }}</p>
>> {% endfor %}
>> </body>
>> </html>
>>
>> So I have a two improves:
>>
>> 1. It is more fast. And in a real project a view can render easyly 50
>> templates
>> 2. I use news.html to develop and news.unify.html to production. So I
>> don't lose legilibility.
>>
>>
>> What do you think about "unify templates feature"? Do you know if exists
>> a similar public project in github/gitlab/bitbucket etc?
>>
>>
>> Best,
>>
>> --
>> Pablo Martín Cobos
>> Computer engineer
>> Python/Django developer
>> 652 53 37 36
>> goi...@gmail.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" 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-develop...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Jani Tiainen
>
> - Well planned is half done, and a half done has been sufficient before...
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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-develop...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAHn91odKFPEc96hbTLmuckAdhmf9LHykEvk--J%3D5vjNmyVGF5w%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAHn91odKFPEc96hbTLmuckAdhmf9LHykEvk--J%3D5vjNmyVGF5w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Juan Pablo Martín Cobos
Ingeniero informático
Desarrollador Python/Django
652 53 37 36
goi...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CALNyWLGQUj34xNUCT%3DXtSbw9Nfj_pnygZf%2BsODs5Y5MOJGqu6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
