--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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.
For more options, visit https://groups.google.com/d/optout.
--
Did you try to measure the difference in time of rendering standard and your way?
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALYYG805GZFJL5b_9nortw8Sj%2Bkrx1p4xqki7C96Zd8vHeYsmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Could you please explain about it. I hadn't understood ur idea.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMsYeuFV3EV_3H%2BR0q9xi5Q6EQq6L2cLkatcvrTtSYW%3D2zRk7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Hi,
I guess the reason you wrote to this list about your unify command, is because you don't mind contributing it to the django project.
So maybe you could show the code of this command, so people can understand what improvements it can offer.
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?
--
Pavlos Georgiadis
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALNyWLFfTS72VtH5kOALqDyCNS2q%3DDn5f7cuQEcepGcz-im6AQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
-- -- Pavlos Georgiadis
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHn91odKFPEc96hbTLmuckAdhmf9LHykEvk--J%3D5vjNmyVGF5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALNyWLGJ5ZqHT%2B11YC6sHmRskR7s2u%3DAYmhpKfhd5_eautM-SA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Hi,Lets try this again.Your system could be nice if it really helps rendering speed.
But does it require changes in Django core itself, or is it completely standalone package that doesn't require changing Django itself to operate? If it requires changes in Django itself, it would be useful to describe what changes are needed and why.
Note that you can even no build custom rendering engines since Django supports those now (with default implementations for Django Templating Language and Jinja2) your system actually might fall in this category.
Even code is bad you really need to start get some momentum for your system. Otherwise it's really hard to provide any feedback for example there might be some edgecases you might not have thought of.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHn91odTc%2B6mO3F5-hv_A5kBqT9Sk_3NtLKboxSyun_tQCDpVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALNyWLGRhOCZ-1LU_5fRWJV_oB7DGBQAvSRU68cCp4r1mMdH5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Hi,You said that this doesn't require any change in Django at all.So this doesn't need to be in Django at all, it can survive as its own and that way it should be.So make your enhancement as reusable app and release it to public. Get people to use it. Fix the bugs that appears. Write a good documentation. Give the support.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHn91odm%3D%2Bw4BSw1qrKwU_h%2Bd88MZohv3mmC0kzbyS66d4rgFA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALNyWLFfP2zV_SfhYQoK%3Dr%3DV2yj_kCJ4TGnP7StjbSVRPHv0Mg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHn91oc7570VgsY%3DFcH%2BGGiqsi_AUDbZ9n%3DA0cf0PrWfh9-G%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Hi.
Unfortunately Django is already big. Every new feature requires careful consideration since it adds maintenance burden to already loaded maintainers.
So best and pretty much only way to make your feature appear in Django itself is to prove that your solution is widely adopted in everyday use and it's "winning" technology.That would practically mean that code is well written, constantly maintained and documented.You can keep showing speed test results but they really won't get you anywhere. Let the people decide is your feature good or not. Get more contributors to your feature to resolve edge cases that doesn't work yet.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHn91oc7570VgsY%3DFcH%2BGGiqsi_AUDbZ9n%3DA0cf0PrWfh9-G%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
I agree, I'd like to see a third party package too.
I'm all up for seeing improvements in template rendering speed but working code in a third party package is way more valuable than more discussion. Many of Django's major features in the past (e.g. SecurityMiddleware, Migrations) were third party packages for a long time before being merged in due to community consensus that they were a good idea.
Nice to see that it is an improvement over the cached loader, but it does seem like it would complicate things for users quite a bit as it stands - having to run another command on deployments, maybe modifying view code to load a different template name in production, and creating more files that increase the size of a deployment or use more memory.
Also I think there might be a number of edge cases that would make "unification" very hard - IIRC you can have an {% if %} around a {% block %} or at least around {{ block.super }}.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM27ai_17tPg-7hhcnC2FD_F6jOwHOEX-J3LNq%2ByURVsBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.