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

[Vitaly Bogomolov]

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]

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]

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]

 

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:

https://github.com/vb64/django.templates.relative.path

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]

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]

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:

https://github.com/vb64/django.templates.relative.path

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]

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]

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]

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

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

[Vitaly Bogomolov]

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

 

Anyone can tell me what to do next? Just wait? 

[Tim Graham]

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]

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

Ticket: https://code.djangoproject.com/ticket/26402

[Michal Petrucha]

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

[Aymeric Augustin]

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]

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]

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

Documentation:https://github.com/django/django/pull/6330/commits/0d49bf63aa8855bb8b61d198d8f08d1547de9dcb

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

[Tim Graham]

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