Hi! > 1. Efficiency: If this new solution slows the compilation/find/render > template, I dislike it
Well, if there is no self-referenced inheritance, no extra code (except for the very same self-referenced inheritance check) is executed, so there is that. If self-referenced inheritance is found, it enters a loop loading every template with the *same path*. So, apart of loading the referenced templates and parsing them, there's no extra cost that I can think of. Of course, we will have to wait until I finish the implementation and benchmarks are ran. > 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. He does not know what application is > overwriting this template... With the current solution [1] if you > overwrite the "admin/change_form.html" template this only (the most > common usecase) will be in a place, this will be in the template > project directory. If I understand you correctly, you are saying that if an app extends an other app's template and the users want to extend this very same template, they don't know what app they are extending. Well, that depends on the order of apps in the ``INSTALLED_APPS`` setting. This order is preserved when inheriting. The same happens with ``TEMPLATE_DIRS``, its order is preserved. BTW, the same would happen with our loader-skipping solution from before and with any non self-referenced extension: if the user extends a template, the template which is extended is the first template that the app loader finds iterating over the ``INSTALLED_APPS`` setting. Naturally, I don't think the overuse of this feature (A --> B --> C --> D) would be recommendable but I couldn't imagine anyone doing that. Sorry for keep you waiting, busy week :-/ Best wishes, Unai Zalakain
signature.asc
Description: PGP signature
