This is an old revision of the document!
Table of Contents
Django templates in NAV
In the future NAV should mainly use Django templates, falling back to cheetah on old subsystems.
Django systems
Something smart here
Context processors
Some features of the templates, such as debug, version number and account/user info and preferences requires context processors.
Currently these context processors are: debug, account and nav_version.
Debug
Provides a SQL debug table at the bottom of every Django page if the DEBUG setting is set to true.
Account_processor
Provides the account object for the current user, a flag telling if he/she is an admin, messages for the user and the custom links found in the navbar (includes quick links).
nav_version
Returns the version number from nav.web.buildconf
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.
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
