On Wed, May 29, 2013 at 4:04 PM, Jorge C. Leitão <[email protected]>wrote:
> 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. > I'd turn this question back onto you -- why *should* the search start locally? What collisions are you seeing between apps that makes a global search impractical? 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. > As Shai pointed out, Django *doesn't* have any concept of a sub-app - at least, not built in. 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. > Well, no - I can see how you've managed to construct an example where local search might be useful (although I still don't concede that it couldn't be answered with global lookups). However, what I need to be convinced is to see an actual use case where this is an issue -- not a synthetic example, but a real world problem. Yours, Russ Magee %-) -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
