User Tools

Site Tools


devel:blueprints:django_template

Django templates in NAV

In the future NAV should mainly use Django templates, falling back to cheetah on old subsystems.

Django systems

In the lib-python directory there's a base template, simply called base.html. Subsystems should extend this one (probably with their own base.html) and the base_content block in it.

base.html provides the header and footer for pages, so subsystems need only contribute the content.

Context processors

Some features of the templates, such as debug, version number and account/user info and preferences requires context processors.

Context processors are not passed to templates by default with render_to_response(), a RequestContext object must be passed to render_to_response to get them.

Without the account_processor all user specific content in templates will not work.

render_to_response(
    'path/to/template',
     {'some_context': var},
     RequestContext(request)
)
NAV context processors
debug Provides a SQL debug table at the bottom of every Django page if the DEBUG setting is set to true.
account_processor Provides account object for current user, a flag telling if he/she is and admin, messages for the user and custom navigation bar.
nav_version The version number from nav.web.buildconf
toolbar All available tools from the toolbox (not enabled by default)

Template blocks and variables

The base templates contains a number of template blocks and variables that both can be overwritten by subsystems.

Blocks
base_header The header. Doctype, HTML head section and the header parts of the html.
base_header_head The head block.
base_header_title The title of the page.
base_header_additional_head Any additional content that should go inside the head tag. Ie. extra CSS or JavaScript
base_body_start The opening body tag.
base_header_logo The NAV logo.
base_header_navbar The navigation bar with breadcrumbs, customizable navbar and quick-links.
base_header_navpath Breadcrumb path.
base_content The content of the page. This one should be overwritten by subsystems to display the content.
base_debug Output from the debug preprocessor.
base_footer The footer
Variables
title Title of the page. Appears inside base_header_title so subsystems can use either one of them.
navpath Breadcrumb path. Contains a list of tuples on the form (url, title). If url is None regular text is displayed, else you get an anchor.
navbar Users navigation bar. Supplied from account_processor.
qlink1 and qlink2 Quick link drop-downs. Supplied from account_processor.
nav_version NAV Version, supplied from nav_version context preprocessor.

Backwards compability

MainTemplate.tmpl in webfront/templates is the main cheetah template. Most other cheetah templates includes this.

Compability with Django templates are done seamless. The MainTemplate includes nav.webfront.compability.Cheetah which provides two methods called footer and header. These two methods are simply printed, and thus the header and footer appears.

MainTemplate will automatically populate the needed instance variables for the Cheetah compability class.

Additional <head> content

If a subsystem that uses Cheetah wants additional meta/CSS/JavaScript and/or other content that should go in the HTML head section to work it must appear in a subclass of one of the “additional” methods defined in the MainTemplate.

The methods are: additionalMeta, additionalCSS, additionalJavaScript, additionalHead.

Ie. if a subsystem wants to use foobar.css, it must appear in additionalCSS as such:

#def additionalCSS
<link rel="stylesheet" type="text/css" href="foobar.css" />
#end def additionalCSS
devel/blueprints/django_template.txt · Last modified: 2010/01/13 13:16 by eide