Just as a good example on why it's not a good idea to skip a loader: Grappelli could most likely strongly benefit from this feature and their preferred setup looks like this http://django-grappelli.readthedocs.org/en/latest/quickstart.html#setup -- Having to set TEMPLATE_DIRS to the grappelli templates just to get self referencing templates wouldn't be nice, I think we can agree on that?
On Monday, December 9, 2013 7:09:48 PM UTC+1, Florian Apolloner wrote: > > > > On Monday, December 9, 2013 5:18:16 PM UTC+1, Goinnn wrote: >> >> 2013/12/9 Florian Apolloner <[email protected]> >> >>> 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 [email protected]. To post to this group, send email to [email protected]. 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/3f3c6dd7-657e-42dd-a2d3-6773c534fe25%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
