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.
