Hi there. Django allows the possibility of putting apps within apps to improve structure of the code and increase portability. I find this absolutely genial.
However, I find this feature quite limited by 2 key issues that are not compatible with this spirit, namely template "finder" and url "resolver". Problem Both url and templates search works on a global basis, namely the search is made *globally* in the website's source, over all installed apps's templates/urls.py. I tried to convince myself that this is a good thing, but what I'm finding out that this leads to developers to have to constantly write url names and templates with the app's name prefix, which is well against the DRY principle, prone to errors, and not portable. In this two tickets 20521 <https://code.djangoproject.com/ticket/20521> and 20412 <https://code.djangoproject.com/ticket/20412> I tried (badly) to propose a solution that solves this issues, which were correctly wontfix. They are not so well though implementation speaking, but my message on both of them stands: why not consider a url/template search that starts the search *locally*? When I mean local I mean that the search FIRST considers the app where the search was called (i.e. the app that called render(request,...)), and only if it didn't found, it starts to search on the rest of the website. My point is that since django allows sub-apps, developers use them to create a directory structure of the apps. My main message is that django should use that information because the directory structure is what the developer is thinking about the relations between apps! If one app is a sub-app (child) of another (parent), probability it is because the child is not an app of global scope: only the parent needs it or the child implements a new set of views that extends the parent's ones. Proposal I now introduce an example which I use to explain my proposal. Consider the example of apps like this (each is an app with __init__, templates, urls, views, etc): main/ phase1/ phase2/ Let's say the main and each phase as a set of rules of usage, which means each phase has "views.rules" and main also has "views.rules". Moreover, because the website as a general structure, both phases extend a base template from main, where e.g. a footer has the tag {% url 'view.rules' %}. This is a stupid example, but I think you got the point: the actual url that appears on the footer should change according to the app rendering the template. Notice that the template is incorrect on purpose as it is leads to NoReverseMatch since {% url 'main.view.rules' %} should be the correct one. The design I'm proposing is the following: First, the render function (the one in shortcuts) asks what is the current app calling it, this can be for instance using inspect<http://docs.python.org/2/library/inspect.html> python's module. If e.g. the call was the view rules from main.phase2.views, then context.current_app='main.phase2'. Second, the {% url %} tag, which has access to the context, starts by searching as if the actual path on the url tag was 'main.phase2'+'view.rules': if NoReverseMatch, it tries 'main'+'view.rules', if it fails, it raises NoReverseMatch. This is naturally extensible to templates tag {% include %}, and the idea is the same: first search the templates of the sub-app, then app, until it reaches the global scope. So, the idea is that because the developer put an child_app within another parent_app, it is telling django that that child_app is part of or extends parent_app. I don't see the reason why django doesn't fulfill the developer's wish and considers child_app part of parent_app. With this, I would like to open a discussion on pros, cons, and caveats of such modification on django's design. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
