>
> 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
> <jorgeca...@gmail.com<javascript:>>
> 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 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.
