views.rst



banner:
banners/views.jpg


Views

Common Structure
View objects expose a number of fields, they are optional unless specified
otherwise.


name (mandatory)
only useful as a mnemonic/description of the view when looking for one in
a list of some sort
model
the model linked to the view, if applicable (it doesn't for QWeb views)
priority

client programs can request views by id, or by (model, type). For
the latter, all the views for the right type and model will be searched,
and the one with the lowest priority number will be returned (it is
the "default view").
priority also defines the order of application during :ref:`view
inheritance <reference/views/inheritance>`

arch
the description of the view's layout
groups_id
:class:`~openerp.fields.Many2many` field to the groups allowed to view/use
the current view
inherit_id
the current view's parent view, see :ref:`reference/views/inheritance`,
unset by default
mode
inheritance mode, see :ref:`reference/views/inheritance`. If
inherit_id is unset the mode can only be primary. If
inherit_id is set, extension by default but can be explicitly set
to primary

application
website feature defining togglable views. By default, views are always
applied


Inheritance

View matching

if a view is requested by (model, type), the view with the right model
and type, mode=primary and the lowest priority is matched
when a view is requested by id, if its mode is not primary its
closest parent with mode primary is matched


View resolution
Resolution generates the final arch for a requested/matched primary
view:

if the view has a parent, the parent is fully resolved then the current
view's inheritance specs are applied
if the view has no parent, its arch is used as-is
the current view's children with mode extension are looked up  and their
inheritance specs are applied depth-first (a child view is applied, then
its children, then its siblings)

The result of applying children views yields the final arch

Inheritance specs
There are three types of inheritance specs: