Hi Russell Keith-Magee. Thanks for your criticisms. Let's see if I can answer some of them.
> 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? Very good question! I think this question is related with your point 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. I.e. in my poor example I was not able to explain myself on the reason for using local search. I'm sorry for the extension, but the reason is not so obvious. Consider the case where in a an app you have an header, with the website logo and stuff, which you want to be consistent within your website, and you have smaller secondary header, (secondary_header.html) which you want to populate according to a specific app rendering the template. One frequent option is to add a block tag and put your (appname_secondary_header.html) with the same block tag, and call the appname_secondary_header.html in the specific's app view. This is the standard approach in Django and works great! The problem is when you try to port this app to another website which already has that appname. Then you have to change your app's name (the directory name). However, this also means you have to change ALL the template names (or else the templates can also collide), all css, etc... you also have to change all views that call the template. Not to mention the disaster it it if the app is within a version control... This is not solved by adding a new folder on the templates directory with your app's name, because you would also have to change that+the all the views. This problem is exactly the same in urls. You set a url naming convention to be consistent with your app, you port the app to another site with conflicting names and BANG. Now, the reason why this happens is because template and url names have global scope. The solution people found out to solve this issue (C/C++, python, you name it) is to use local scope. For instance python uses namespaces, which uniquely define a name in relation to PATH or something. In Django, namespaces are ill implemented (again, which is fine for most cases!) because they are not defined in respect to a path, they are just a name chosen by the developer, which is susceptible to collision. In Python, packages are meant to be portable and the solution is: inside the package, you use a naming scheme assuming an arbitrary name of the package (directory's name). If at some moment you have to change the package name to avoid collision with other package, you just have to change the package's name and *not the content*. The names are arbitrary because the full name in relation to PATH will include the name of the package (e.g. import package.module). So, if global scope doesn't work, what should them work? The answer (given by python developers) is local scope, and Django can use exactly the same idea as python uses in subclassing: if you want to extend an app, you put a sub-app within that app. If the app extends html, then the extension is like a subclassing: your sub-app adds some functionality, while keeping other constant. In my example of the secondary header, this means that if the sub-app has a secondary header that it would like to use, then it "overloads" the parent's template and calls its own secondary header. It is a design decision on whether the developer can act on the parent to allow this or not (in C++ you use "virtual" to say the method can be overloaded, in python every method can be overloaded). So, my suggestion is *not just* about a funny way of searching. When I mean "local search", it is nothing more than a subclassing scheme, where the sub-apps are subclassing the parent app. Local means: "try to find the functionality in the class, if not found, go to the super" which python does internally. And with this you answer "f*** you this is like designing a hole new django from scratch". My claim is that I only had to change like 10 lines of code in the actual Django code, produce 2 template tags and make a small modification on the "render" shortcut (with I named local_render) to include current_app. Even if this change is far from proofed to work on all cases (which I strongly doubt), I believe this idea is an important modification that increases the overall consistency of Django framework. Russell Keith-Magee, I hope this (rather long) explanation provides in-depth justifications on why this modification is important and relevant to real problems. Cheers, Jorge On Thursday, May 30, 2013 8:17:49 AM UTC+2, Russell Keith-Magee wrote: > > > > On Wed, May 29, 2013 at 4:04 PM, Jorge C. Leitão > <jorgeca...@gmail.com<javascript:> > > 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 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.
