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 <[email protected]> > 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. >> > 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 [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/CALNyWLG2t9VtT-9iATb945GfDbGiVXvc2J3QJt3jV_9%2Bd9uwQw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
