I'm really quite unconvinced by your arguments I'm afraid. In particular one of the strengths of the normal template loader is that it does *not* start locally - so I can use a pluggable application and override templates very easily. The normal pattern for pluggable applications is that they namespace all of their templates (say for an application called `myapp` the template paths would be `myapp/secondary_header.html`). This means these kind of name collisions are far less likely to occur - only if the app name matches. If that happens then you have all manner of issues - you'd need to be incredibly careful about relative imports everywhere etc to be able to rename the top level name of a package and not break it - I think having to update template paths as well is not the biggest issue here.
In respect to URLs, URL namespacing is already a feature in Django to allow the same URLs to be deployed multiple times and to namespace the reverses. (https://docs.djangoproject.com/en/dev/topics/http/urls/#url-namespaces) On Thursday, 30 May 2013 13:13:55 UTC+1, Jorge C. Leitão wrote: > > I must say that reading this into Russel (and other)'s replies is very >> far fetched (language as well as content), uncalled for, and seems to >> expose an assumption that the people here prefer the easy path of swatting >> suggestions with a quick "nay". I 'd say the opposite is much closer to >> the truth. > > > I'm sorry, this was a joke; not something to be taken seriously. On the > contrary, I assume people here are actually very well intended, and that's > why I feel confident enough to put the joke here. Anyway, I'm not here to > offend anyone or anything, so, I'm sorry for the sentence, I would retract > it if I could. > > I generally accept your criticisms and agree with your point of view that > it is not so strait-forward in django's spirit. Let's them try to reach > some specific points that would be worth implementing, even without the > whole idea I'm proposing. > > It seems you could achieve what you're after (at least for templates) with >> a custom template loader. A variation on the app directories loader [0] can >> impose a different search order than the default one that simply follows >> the order in INSTALLED_APPS. Am I wrong? > > > YES!! Definitely this. However, the function get_template does not accept > a directory to search. It is not possible to pass the directory of the > search to the get_template: django.templates.loader.get_template only > accepts one argument, i.e. you cannot tell which directory you want the > template to be searched from the call. The two of the 10 lines of code I > was referring to was change in that function: > > from > get_template(template_name) > ... > to > get_template(template_name*, dirs=None*) > ... > template, origin = find_template(template_name*, dirs*) > > this is compatible with the find_template function, which also has two > arguments: > > find_template(name, dirs=None) > > For consistency, this should be implemented on the other two functions: > > render_to_string > select_template > > which should also receive dirs as arguments, with default=None and > respective passing in the their calls of get_template. > > This allows the developer to actually *choose* which template it is > refering to when it uses render("secondary_header.html"), and works with > the > > app_directories.Loader because it already has a optional argument > "template_dirs". > > So, yes, this is actually one of my proposals... change these 4 or 5 lines. > > Cheers, > Jorge > > > > On Thursday, May 30, 2013 12:50:34 PM UTC+2, Yishai Beeri wrote: >> >> Hello Jorge, >> >> On Thu, 30 May 2013 12:42:20 +0300, Jorge C. Leitão <[email protected]> >> wrote: >> >> 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. >> >> >> The "a specific app rendering the template" is not phrase is not >> well-defined. Do you mean the app (in INSTALLED_APPS) that registered the >> url matched for the current request? The python module where the view >> function sits in? The python module whence the call to the template's >> render() was made? The python module which loaded the template? These can >> all be different things. Talking about "which app" makes some sense if >> you're limiting yourself to URL names - but keep in mind that templates can >> be (and often are) used outside of an HTTP request/response cycle - what's >> the "app" then? >> >> 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. >> >> How would you suggest extending a 3rd party app, then? I assume you're >> not suggesting to place my extension inside the source tree of the 3rd >> party app. >> Python's subclassing is completely disconnected from physical paths - and >> you usually have to explicitly name the class you're extending - you don't >> inherit it simply by virtue of being in a subfolder. You also give the new, >> extended class a brand new name - and at least some code needs to know that >> name in order to instantiate the right thing. >> >> 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). >> >> The same analogy applies - to extend html you name the template you're >> extending, and you give the extended version a new name. Block tags are >> simply ways to declare what can be extended, templates would be very >> unwieldy otherwise. >> >> >> 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. >> >> >> It seems you could achieve what you're after (at least for templates) >> with a custom template loader. A variation on the app directories loader >> [0] can impose a different search order than the default one that simply >> follows the order in INSTALLED_APPS. Am I wrong? >> >> >> >> 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 >> >> >> I must say that reading this into Russel (and other)'s replies is very >> far fetched (language as well as content), uncalled for, and seems to >> expose an assumption that the people here prefer the easy path of swatting >> suggestions with a quick "nay". I 'd say the opposite is much closer to >> the truth. >> >> 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 >> >> >> [0] >> https://docs.djangoproject.com/en/dev/ref/templates/api/#django.template.loaders.app_directories.Loader >> Yishai >> >> >> -- 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.
