Templates are the entry point for the CubicWeb view system. As seen in Discovering possible views, there are two kinds of views: the templatable and non-templatable.
Non-templatable views are standalone. They are responsible for all the details such as setting a proper content type (or mime type), the proper document headers, namespaces, etc. Examples are pure xml views such as RSS or Semantic Web views (SIOC, DOAP, FOAF, Linked Data, etc.), and views which generate binary files (pdf, excel files, etc.)
To notice that a view is not templatable, you just have to set the view’s class attribute templatable to False. In this case, it should set the content_type class attribute to the correct MIME type. By default, it is text/xhtml. Additionally, if your view generate a binary file, you have to set the view’s class attribute binary to True too.
Templatable views are not concerned with such pesky details. They leave it to the template. Conversely, the template’s main job is to:
Look at cubicweb.web.views.basetemplates and you will find the base templates used to generate (X)HTML for your application. The most important template there is TheMainTemplate.
A page is composed as indicated on the schema below :
The sections dispatches specific views:
header: the rendering of the header is delegated to the htmlheader view, whose default implementation can be found in basetemplates.py and which does the following things:
- inject the favicon if there is one
- call and display a link to an rss component if there is one available
it also sets up the page title, and fills the actual header section with top-level components, using the header view, which:
- tries to display a logo, the name of the application and the breadcrumbs
- provides a login status area
- provides a login box (hiden by default)
left column: this is filled with all selectable boxes matching the left context (there is also a right column but nowadays it is seldom used due to bad usability)
contentcol: this is the central column; it is filled with:
- the rqlinput view (hidden by default)
- the applmessages component
- the contentheader view which in turns dispatches all available content navigation components having the navtop context (this is used to navigate through entities implementing the IPrevNext interface)
- the view that was given as input to the template’s call method, also dealing with pagination concerns
- the contentfooter
footer: adds all footer actions
How and why a view object is given to the main template is explained in the Publisher chapter.
You can overload some methods of the TheMainTemplate, in order to fulfil your needs. There are also some attributes and methods which can be defined on a view to modify the base template behaviour:
You can also modify certain aspects of the main template of a page when building an url or setting these parameters in the req.form:
There are also the following other standard templates: