Florian, I know that the benefits of this solution. But I see the detriments too. I think that if we allow that a app template overwrite with self-reference another app template the template development will be a chaos. I thought alot about it
2013/12/9 Florian Apolloner <f.apollo...@gmail.com> > 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 <f.apo...@gmail.com> >>> >>>> 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. >> > For me this is a peculiar solution, but now I see the merits of it, thanks you! And of course if you only use the app_directories loader, the current solution does not work for you. Best regards, -- Pablo Martín -- 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/CALNyWLG2t9VtT-9iATb945GfDbGiVXvc2J3QJt3jV_9%2Bd9uwQw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
