Code

Opened 5 years ago

Closed 5 years ago

#10219 closed (wontfix)

Template tag for declaring constants

Reported by: Daniel Pope <dan@…> Owned by: nobody
Component: Template system Version: 1.0
Severity: Keywords: constant, tag
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

I often need to reproduce the title several times in each template I write. For example most of my templates end up starting like this:

{% extends "base.html" %}
{% block title %}{{t}}{% endblock %}
{% block pagetitle %}{{t}}{% endblock %}
{% block breadcrumbs %}<li>{{t}}</li>{% endblock %}

This anti-pattern emerges from the lack of ability to pass any information up the template inheritance chain. I run into the same thing when a base template includes menus or tabs; to show which tab or menu item is selected requires that I copy-and-paste the menu code into each template, only to change which item is displayed as selected.

I think this is a bad thing for maintainability as even slight changes in base templates mean all sub-templates have to be amended. If the inherited template could pass constants to its super-template, the title could be re-used in several places and the menu could be written in one place using {% ifequal %}. For example, an appropriate syntax might look like this:

{% extends "base.html" %}
{% define TITLE t %}
{% define TAB "home" %}

All templates in the hierarchy would execute with {'TITLE': t, 'TAB': 'home'} added to the context. With multiple levels of inheritance, a template's defines would override those in its hierarchy. ('define' is used for declaring constants in C and PHP; uppercase is a widely-used convention for constants).

Attachments (0)

Change History (3)

comment:1 Changed 5 years ago by lukeplant

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

First, the idea normally is that you pass the title in as a variable to the template, which makes it easy to do just what you are wanting (simply by putting common code in the base template), unless I misunderstood.

Second, you can of course define a template tag like this yourself, there is no need to have it in core.

So, closing WONTFIX.

comment:2 Changed 5 years ago by Daniel Pope <dan@…>

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Regarding your first point: Passing the title as a template variable is obviously a workaround but it's not the "right" way to do it. It's delegating an aspect of the view to the controller, straddling the conceptual separation of the MVC model (that's MVC View, not Django view, as of course the Django view is the MVC Controller). There are immediate problems with this workaround: neither generic views, flatpages, or the 404 template pass a title variable.

Regarding your second point: You can't implement this as a standalone template tag. Unlike WithNode which does a similar thing in a local rather than global scope, ExtendsNode has a special and unique relationship with the Parser, and I believe this would also require changes to ExtendsNode and/or Parser. Without trying to implement this, I can't say for sure, but I have hacked around with the inheritance model before and it does generally require changes to django/template/__init__.py.

I hope you don't mind if I reopen this for discussion?

comment:3 Changed 5 years ago by Alex

  • Resolution set to wontfix
  • Status changed from reopened to closed

Trac is really bad for holding discussions, so I'm going to close this as wontfix again, and suggest you bring it up on the dev-list, with a specific list of issues that prevent this from being created for yourself, because as Luke points out this really isn't a design goal of the template system, although the individual limitations are things we might want to overcome.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.