diff options
Diffstat (limited to 'doc/03_module_dev_03.rst')
| -rw-r--r-- | doc/03_module_dev_03.rst | 252 |
1 files changed, 130 insertions, 122 deletions
diff --git a/doc/03_module_dev_03.rst b/doc/03_module_dev_03.rst index 975ebbb3064..6091934596f 100644 --- a/doc/03_module_dev_03.rst +++ b/doc/03_module_dev_03.rst @@ -4,15 +4,24 @@ Views and Events Introduction to Views --------------------- -As all data of the program is stored in objects, as explained in the Objects section, how are these objects exposed to the user ? We will try to answer this question in this section. +As all data of the program is stored in objects, as explained in the Objects +section, how are these objects exposed to the user ? We will try to answer this +question in this section. -First of all, let's note that every resource type uses its own interface. For example, the screen to modify a partner's data is not the same as the one to modify an invoice. +First of all, let's note that every resource type uses its own interface. For +example, the screen to modify a partner's data is not the same as the one to +modify an invoice. -Then, you have to know that the OpenERP user interface is dynamic, it means that it is not described "statically" by some code, but dynamically built from XML descriptions of the client screens. +Then, you have to know that the OpenERP user interface is dynamic, it means +that it is not described "statically" by some code, but dynamically built from +XML descriptions of the client screens. From now on, we will call these screen descriptions views. -A notable characteristic of these views is that they can be edited at any moment (even during the program execution). After a modification to a displayed view has occurred, you simply need to close the tab corresponding to that 'view' and re-open it for the changes to appear. +A notable characteristic of these views is that they can be edited at any +moment (even during the program execution). After a modification to a displayed +view has occurred, you simply need to close the tab corresponding to that +'view' and re-open it for the changes to appear. Views principles ++++++++++++++++ @@ -57,90 +66,72 @@ As we can see below in the purple zone of the screen, there is also a way to dis :scale: 50 :align: center +On Change ++++++++++ -Tree views ------------ - -These views are used when we work in list mode (in order to visualize several resources at once) and in the search screen. These views are simpler than the form views and thus have less options. - -.. figure:: images/tree_view.png - :scale: 50 - :align: center - -Graph views --------------- - -A graph is a new mode of view for all views of type form. If, for example, a sale order line must be visible as list or as graph, define it like this in the action that open this sale order line. Do not set the view mode as "tree,form,graph" or "form,graph" - it must be "graph,tree" to show the graph first or "tree,graph" to show the list first. (This view mode is extra to your "form,tree" view and should have a separate menu item): - -.. code-block:: xml - - <field name="view_type">form</field> - <field name="view_mode">tree,graph</field> +The on_change attribute defines a method that is called when the content of a view field has changed. -view_type:: +This method takes at least arguments: cr, uid, ids, which are the three classical arguments and also the context dictionary. You can add parameters to the method. They must correspond to other fields defined in the view, and must also be defined in the XML with fields defined this way:: - tree = (tree with shortcuts at the left), form = (switchable view form/list) + <field name="name_of_field" on_change="name_of_method(other_field'_1_', ..., other_field'_n_')"/> -view_mode:: +The example below is from the sale order view. - tree,graph : sequences of the views when switching +You can use the 'context' keyword to access data in the context that can be used as params of the function.:: -Then, the user will be able to switch from one view to the other. Unlike forms and trees, OpenERP is not able to automatically create a view on demand for the graph type. So, you must define a view for this graph: + <field name="shop_id" on_change="onchange_shop_id(shop_id)"/> +.. code-block:: python -.. code-block:: xml + def onchange_shop_id(self, cr, uid, ids, shop_id): - <record model="ir.ui.view" id="view_order_line_graph"> - <field name="name">sale.order.line.graph</field> - <field name="model">sale.order.line</field> - <field name="type">graph</field> - <field name="arch" type="xml"> - <graph string="Sales Order Lines"> - <field name="product_id" group="True"/> - <field name="price_unit" operator="*"/> - </graph> - </field> - </record> + v={} + if shop_id: + shop=self.pool.get('sale.shop').browse(cr,uid,shop_id) + v['project_id']=shop.project_id.id + if shop.pricelist_id.id: -The graph view + v['pricelist_id']=shop.pricelist_id.id -A view of type graph is just a list of fields for the graph. + v['payment_default_id']=shop.payment_default_id.id -Graph tag -++++++++++ + return {'value':v} -The default type of the graph is a pie chart - to change it to a barchart change **<graph string="Sales Order Lines">** to **<graph string="Sales Order Lines" type="bar">** You also may change the orientation. -:Example : - -.. code-block:: xml +When editing the shop_id form field, the onchange_shop_id method of the sale_order object is called and returns a dictionary where the 'value' key contains a dictionary of the new value to use in the 'project_id', 'pricelist_id' and 'payment_default_id' fields. - <graph string="Sales Order Lines" orientation="horizontal" type="bar"> +Note that it is possible to change more than just the values of +fields. For example, it is possible to change the value of some fields +and the domain of other fields by returning a value of the form: +return {'domain': d, 'value': value} -Field tag -+++++++++ +:returns: a dictionary with any mix of the following keys: -The first field is the X axis. The second one is the Y axis and the optional third one is the Z axis for 3 dimensional graphs. You can apply a few attributes to each field/axis: + ``domain`` + A mapping of ``{field: domain}``. - * **group**: if set to true, the client will group all item of the same value for this field. For each other field, it will apply an operator - * **operator**: the operator to apply is another field is grouped. By default it's '+'. Allowed values are: + The returned domains should be set on the fields instead of the + default ones. - + +: addition - + \*: multiply - + \**: exponent - + min: minimum of the list - + max: maximum of the list + ``value`` + A mapping of ``{field: value}}``, the values will be set on the + corresponding fields and may trigger new onchanges or attrs + changes -:Defining real statistics on objects: + ``warning`` A dict with the keys ``title`` and ``message``. Both + are mandatory. Indicate that an error message should be + displayed to the user. -The easiest method to compute real statistics on objects is: - 1. Define a statistic object which is a postgresql view - 2. Create a tree view and a graph view on this object +Tree views +---------- -You can get en example in all modules of the form: report\_.... Example: report_crm. +These views are used when we work in list mode (in order to visualize several resources at once) and in the search screen. These views are simpler than the form views and thus have less options. +.. figure:: images/tree_view.png + :scale: 50 + :align: center Search views -------------- @@ -320,6 +311,82 @@ We can save this search criteria as a Shortcut or save as Filter. Filters are user specific and can be modified via the Manage Filters option in the filters drop-down. +Graph views +----------- + +A graph is a new mode of view for all views of type form. If, for example, a sale order line must be visible as list or as graph, define it like this in the action that open this sale order line. Do not set the view mode as "tree,form,graph" or "form,graph" - it must be "graph,tree" to show the graph first or "tree,graph" to show the list first. (This view mode is extra to your "form,tree" view and should have a separate menu item): + +.. code-block:: xml + + <field name="view_type">form</field> + <field name="view_mode">tree,graph</field> + +view_type:: + + tree = (tree with shortcuts at the left), form = (switchable view form/list) + +view_mode:: + + tree,graph : sequences of the views when switching + +Then, the user will be able to switch from one view to the other. Unlike forms and trees, OpenERP is not able to automatically create a view on demand for the graph type. So, you must define a view for this graph: + + +.. code-block:: xml + + <record model="ir.ui.view" id="view_order_line_graph"> + <field name="name">sale.order.line.graph</field> + <field name="model">sale.order.line</field> + <field name="type">graph</field> + <field name="arch" type="xml"> + <graph string="Sales Order Lines"> + <field name="product_id" group="True"/> + <field name="price_unit" operator="*"/> + </graph> + </field> + </record> + + +The graph view + +A view of type graph is just a list of fields for the graph. + +Graph tag +++++++++++ + +The default type of the graph is a pie chart - to change it to a barchart change **<graph string="Sales Order Lines">** to **<graph string="Sales Order Lines" type="bar">** You also may change the orientation. + +:Example : + +.. code-block:: xml + + <graph string="Sales Order Lines" orientation="horizontal" type="bar"> + +Field tag ++++++++++ + +The first field is the X axis. The second one is the Y axis and the optional third one is the Z axis for 3 dimensional graphs. You can apply a few attributes to each field/axis: + + * **group**: if set to true, the client will group all item of the same value for this field. For each other field, it will apply an operator + * **operator**: the operator to apply is another field is grouped. By default it's '+'. Allowed values are: + + + +: addition + + \*: multiply + + \**: exponent + + min: minimum of the list + + max: maximum of the list + +:Defining real statistics on objects: + +The easiest method to compute real statistics on objects is: + + 1. Define a statistic object which is a postgresql view + 2. Create a tree view and a graph view on this object + +You can get en example in all modules of the form: report\_.... Example: report_crm. + + + Calendar Views -------------- @@ -1367,62 +1434,3 @@ flexible if you define the child views separately and then specify which child view to use as part of the one2many field. -Events ------- - -On Change -+++++++++ - -The on_change attribute defines a method that is called when the content of a view field has changed. - -This method takes at least arguments: cr, uid, ids, which are the three classical arguments and also the context dictionary. You can add parameters to the method. They must correspond to other fields defined in the view, and must also be defined in the XML with fields defined this way:: - - <field name="name_of_field" on_change="name_of_method(other_field'_1_', ..., other_field'_n_')"/> - -The example below is from the sale order view. - -You can use the 'context' keyword to access data in the context that can be used as params of the function.:: - - <field name="shop_id" on_change="onchange_shop_id(shop_id)"/> - -.. code-block:: python - - def onchange_shop_id(self, cr, uid, ids, shop_id): - - v={} - if shop_id: - - shop=self.pool.get('sale.shop').browse(cr,uid,shop_id) - v['project_id']=shop.project_id.id - if shop.pricelist_id.id: - - v['pricelist_id']=shop.pricelist_id.id - - v['payment_default_id']=shop.payment_default_id.id - - return {'value':v} - - -When editing the shop_id form field, the onchange_shop_id method of the sale_order object is called and returns a dictionary where the 'value' key contains a dictionary of the new value to use in the 'project_id', 'pricelist_id' and 'payment_default_id' fields. - -Note that it is possible to change more than just the values of -fields. For example, it is possible to change the value of some fields -and the domain of other fields by returning a value of the form: -return {'domain': d, 'value': value} - -:returns: a dictionary with any mix of the following keys: - - ``domain`` - A mapping of ``{field: domain}``. - - The returned domains should be set on the fields instead of the - default ones. - - ``value`` - A mapping of ``{field: value}}``, the values will be set on the - corresponding fields and may trigger new onchanges or attrs - changes - - ``warning`` A dict with the keys ``title`` and ``message``. Both - are mandatory. Indicate that an error message should be - displayed to the user. |