On Monday, December 9, 2013 5:18:16 PM UTC+1, Goinnn wrote: > > 2013/12/9 Florian Apolloner <f.apo...@gmail.com <javascript:>> > >> On Monday, December 9, 2013 12:43:04 PM UTC+1, Goinnn wrote: >>> >>> 1. Efficiency: If this new solution slows the compilation/find/render >>> template, I dislike it >>> >> >> Lots of "ifs" which are not really worth discussing before we run actual >> benchmarks; also I think that it won't be slower since currently template >> resolving will iterate through all loaders anyways… >> > Unai said it: "Now, the tricky part is to identify a template uniquely. I > went for hashing but, as Apollo13 said on IRC, that's just too > expensive"... >
I also said that it "just doesn't feel right" :) But I'd wait for a patch before we start discussing it's theoretical performance implications. 2. This solution will complicate the template development. e.g. if a > application overwrite the "admin/change_form.html" template and a > developer wants to update this template, he will have to search this > template in every app. >> >> >> That is already the case, you can't know that 'admin/change_form.html' >> will be in the admin app. >> > > … two applications can not overwrite the 'admin/change_form.html' > template. … > And that's not the behavior normal template loading guarantees, so it would be very very odd to change it for the edgecase of self referencing templates. So I'll argue again, that your suggestion is the one making the behavior more unexpected. It is very very unusual for me, I don't understand why you do this. I > always have TEMPLATE_DIRS set for the common templates: base.html, > 404.html, 500.html and to overwrite the reusable app templates. > That's okay, there are many people for whom it's not unusual. Why we do it? Simply cause there is no reason to special case common templates or overrides; just put them in an app named like your project and put them on top of INSTALLED_APPS. The benefits are (among other things): You can also have project management commands, static files and templatetags/filters without having to change a few other variables like STATICFILES_DIRS. Think about it for a while and I guess you'll see the merits too. Cheers, Florian -- 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/f59206d7-0797-483a-bf4a-6d2a94956b97%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
