relative path in {% extends "...base.html" %} like relative import

926 views
Skip to first unread message

Vitaly Bogomolov

unread,
Mar 18, 2016, 12:43:29 PM3/18/16
to Django developers (Contributions to Django itself)
Hi, All.

For django.template.backends.django.DjangoTemplates (filesystem and app_directories) it can be very useful. This can be implemented?

WBR, Vitaly.

Collin Anderson

unread,
Mar 20, 2016, 12:57:41 PM3/20/16
to django-d...@googlegroups.com
Hmm... I suppose the closest alternative we have would be to store the base template name in a variable and pass it in from the view.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ccb20872-b91c-493b-b9f6-b4a28170cb99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Florian Apolloner

unread,
Mar 20, 2016, 2:45:37 PM3/20/16
to Django developers (Contributions to Django itself)
On Sunday, March 20, 2016 at 5:57:41 PM UTC+1, Collin Anderson wrote:
Hmm... I suppose the closest alternative we have would be to store the base template name in a variable and pass it in from the view.

Either way, I fail to see how that feature would be really useful.

Vitaly Bogomolov

unread,
Mar 21, 2016, 3:25:46 AM3/21/16
to Django developers (Contributions to Django itself)
 
Hmm... I suppose the closest alternative we have would be to store the base template name in a variable and pass it in from the view.

If code for support template inheritance lives in views, it's not convenient.

Here is code, that implement this feature for Django 1.4/1.9:

But this extension disable the useful rule 'extends must be first tag in template', and that make me unhappy. :)
If Django core team approve my proposal, i can make pool request.

Vitaly Bogomolov

unread,
Mar 21, 2016, 3:35:38 AM3/21/16
to Django developers (Contributions to Django itself)

Either way, I fail to see how that feature would be really useful.

I was need a refactor for large hierarchy of django templates. Moving branches inside hierarchy is simple, if inheritance uses relative paths.

Florian Apolloner

unread,
Mar 21, 2016, 4:47:49 AM3/21/16
to Django developers (Contributions to Django itself)


On Monday, March 21, 2016 at 8:25:46 AM UTC+1, Vitaly Bogomolov wrote:
Here is code, that implement this feature for Django 1.4/1.9:

Since we are (usually) talking about paths, I would prefer "./base.html" and "../base.html", if at all. Mimicking python import paths here seems counter intuitive to me. If the changes against core Django are relatively minimal and a nice patch with tests were put up, I would not stand in the way of merging.

Cheers,
Florian

Tim Graham

unread,
Mar 21, 2016, 12:24:22 PM3/21/16
to Django developers (Contributions to Django itself)
There are backwards-compatibility concerns as a leading dot can no longer be used in a template name, though if developers are following the advice about template namespacing it wouldn't be a problem.

Still, I am not sure if the Django Template Language should evolve new features like this. Is there any prior art in Jinja2? I couldn't find any based on this answer: http://stackoverflow.com/questions/2180247/does-the-jinja2-templating-language-have-the-concept-of-here-current-director

I see you created a pull request: https://github.com/django/django/pull/6318

Vitaly Bogomolov

unread,
Mar 21, 2016, 1:18:50 PM3/21/16
to Django developers (Contributions to Django itself)
There are backwards-compatibility concerns as a leading dot can no longer be used in a template name, though if developers are following the advice about template namespacing it wouldn't be a problem.

Mimicking for python import paths it's just my proposal. If this violate some guidelines, any syntax can be implemented. I'm put a comment to code, where it can be done. You can make it yourself or notify me, what Django team prefer.
 

Still, I am not sure if the Django Template Language should evolve new features like this. Is there any prior art in Jinja2? I couldn't find any based on this answer: http://stackoverflow.com/questions/2180247/does-the-jinja2-templating-language-have-the-concept-of-here-current-director

I see you created a pull request: https://github.com/django/django/pull/6318

fuh, 'All checks have passed' :)

Vitaly Bogomolov

unread,
Mar 22, 2016, 7:12:12 AM3/22/16
to Django developers (Contributions to Django itself)
I see you created a pull request: https://github.com/django/django/pull/6318


Syntax for relative path was changed from ... to ./../

Vitaly Bogomolov

unread,
Mar 23, 2016, 3:00:52 PM3/23/16
to Django developers (Contributions to Django itself)
Syntax for relative path was changed from ... to ./../
 
Anyone can tell me what to do next? Just wait? 

Tim Graham

unread,
Mar 23, 2016, 8:07:43 PM3/23/16
to Django developers (Contributions to Django itself)
Asking again... I am not sure if the Django Template Language should evolve new features like this. Is there any prior art in Jinja2? Absent any other +1's, I guess I would be more comfortable accepting the feature if so.

The code seems too complicated. Could we reuse os.path handling from the standard library to simplify it?

Assuming the feature is accepted, at least a ticket and documentation are needed to finish the patch. See the patch review checklist:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist

Vitaly Bogomolov

unread,
Mar 24, 2016, 8:06:55 AM3/24/16
to Django developers (Contributions to Django itself)
Asking again... I am not sure if the Django Template Language should evolve new features like this. Is there any prior art in Jinja2? Absent any other +1's, I guess I would be more comfortable accepting the feature if so.

I can't say anything about Jinja2, but for existing old projects, that use DjangoTemplates, this feature will be helpful. I mean refactor for large template hierarchy.


The code seems too complicated. Could we reuse os.path handling from the standard library to simplify it?

I don't think, that os.path is applicable in this case, because template_name != file_name. In fact, this feature must work for any template loader (databases, etc), which have 'hierarchy' concept, and uses '/' as separator for levels of hierarchy.

Assuming the feature is accepted, at least a ticket and documentation are needed to finish the patch. See the patch review checklist:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist

Michal Petrucha

unread,
Mar 24, 2016, 8:13:22 AM3/24/16
to django-d...@googlegroups.com
On Thu, Mar 24, 2016 at 05:06:54AM -0700, Vitaly Bogomolov wrote:
> > The code seems too complicated. Could we reuse os.path handling from the
> > standard library to simplify it?
> >
>
> I don't think, that os.path is applicable in this case, because
> template_name != file_name. In fact, this feature must work for any
> template loader (databases, etc), which have 'hierarchy' concept, and uses
> '/' as separator for levels of hierarchy.

If the platform-dependent os.path is not suitable for this, but you
want to always perform POSIX-like path manipulations, you should just
use the posixpath module.

Cheers,

Michal
signature.asc

Aymeric Augustin

unread,
Mar 24, 2016, 8:22:56 AM3/24/16
to django-d...@googlegroups.com
On 24 Mar 2016, at 01:07, Tim Graham <timog...@gmail.com> wrote:

> Asking again... I am not sure if the Django Template Language should evolve new features like this. Is there any prior art in Jinja2? Absent any other +1's, I guess I would be more comfortable accepting the feature if so.

The feature makes sense to me. I’m surprised it wasn’t proposed earlier.

Actually, perhaps it was — did someone search the archives of this mailing list?

> The code seems too complicated. Could we reuse os.path handling from the standard library to simplify it?

Yes, the patch must contain a call to posixpath.join somewhere. This is tricky to get right, don’t reinvent the wheel!

(See ticket 26249 for an example of what happens when we implement our own path manipulations.)

--
Aymeric.


Vitaly Bogomolov

unread,
Mar 24, 2016, 1:12:02 PM3/24/16
to Django developers (Contributions to Django itself)
Yes, the patch must contain a call to posixpath.join somewhere. This is tricky to get right, don’t reinvent the wheel!

Agree, posixpath is the best solution. Forgot this module :(

Vitaly Bogomolov

unread,
Mar 25, 2016, 10:18:25 AM3/25/16
to Django developers (Contributions to Django itself)

Assuming the feature is accepted, at least a ticket and documentation are needed to finish the patch. See the patch review checklist:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist


My english not good, so i need help with proof reading and advice

Tim Graham

unread,
Mar 29, 2016, 11:43:51 AM3/29/16
to Django developers (Contributions to Django itself)
I found a couple previous discussions but no strong arguments against the feature so I'll move forward with reviewing the patch.

https://groups.google.com/d/topic/django-users/qX2ThbMk_So/discussion
https://groups.google.com/d/topic/django-users/_dUhA_IWpl8/discussion
Reply all
Reply to author
Forward
0 new messages