diff options
| author | Openerp Online <online@openerp.com> | 2012-03-05 13:40:16 +0100 |
|---|---|---|
| committer | Openerp Online <online@openerp.com> | 2012-03-05 13:40:16 +0100 |
| commit | 0c8e11643f84afddec07f21b6f7fc2b981fb2706 (patch) | |
| tree | 73e29a0f5409688fdcc513b488c169dba2febdfd /doc/source/guides | |
| parent | ba3193dd4d5aa2a138899c2ac55b3e7fa7768256 (diff) | |
[DOC] use a flat (i.e. no source/ directory) structure.
bzr revid: online@openerp.com-20120305124016-d25rncl3q2qcem31
Diffstat (limited to 'doc/source/guides')
| -rw-r--r-- | doc/source/guides/client-action.rst | 92 | ||||
| -rw-r--r-- | doc/source/guides/sidebar-protocol.rst | 78 |
2 files changed, 0 insertions, 170 deletions
diff --git a/doc/source/guides/client-action.rst b/doc/source/guides/client-action.rst deleted file mode 100644 index 2e1177371a2..00000000000 --- a/doc/source/guides/client-action.rst +++ /dev/null @@ -1,92 +0,0 @@ -Creating a new client action -============================ - -Client actions are the client-side of OpenERP's "Server Actions": instead of -allowing for semi-arbitrary code to be executed in the server, they allow -for execution of client-customized code. - -On the server side, a client action is an action of type ``ir.actions.client``, -which has (at most) two properties: a mandatory ``tag``, which is an arbitrary -string by which the client will identify the action, and an optional ``params`` -which is simply a map of keys and values sent to the client as-is (this way, -client actions can be made generic and reused in multiple contexts). - -General Structure ------------------ - -In the OpenERP Web code, a client action only requires two pieces of -information: - -* Mapping the action's ``tag`` to an OpenERP Web object - -* The OpenERP Web object itself, which must inherit from - :js:class:`openerp.web.Widget` - -Our example will be the actual code for the widgets client action (a client -action displaying a ``res.widget`` object, used in the homepage dashboard of -the web client): - -.. code-block:: javascript - - // Registers the object 'openerp.web_dashboard.Widget' to the client - // action tag 'board.home.widgets' - openerp.web.client_actions.add( - 'board.home.widgets', 'openerp.web_dashboard.Widget'); - // This object inherits from View, but only Widget is required - openerp.web_dashboard.Widget = openerp.web.View.extend({ - template: 'HomeWidget' - }); - -At this point, the generic ``Widget`` lifecycle takes over, the template is -rendered, inserted in the client DOM, bound on the object's ``$element`` -property and the object is started. - -If the client action takes parameters, these parameters are passed in as a -second positional parameter to the constructor: - -.. code-block:: javascript - - init: function (parent, params) { - // execute the Widget's init - this._super(parent); - // board.home.widgets only takes a single param, the identifier of the - // res.widget object it should display. Store it for later - this.widget_id = params.widget_id; - } - -More complex initialization (DOM manipulations, RPC requests, ...) should be -performed in the ``start()`` method. - -.. note:: - As required by ``Widget``'s contract, if ``start`` executes any - asynchronous code it should return a ``$.Deferred`` so callers know when - it's ready for interaction. - - Although generally speaking client actions are not really interacted with. - -.. code-block:: javascript - - start: function () { - return $.when( - this._super(), - // Simply read the res.widget object this action should display - new openerp.web.DataSet(this, 'res.widget').read_ids( - [this.widget_id], ['title'], this.on_widget_loaded)); - } - -The client action can then behave exactly as it wishes to within its root -(``this.$element``). In this case, it performs further renderings once its -widget's content is retrieved: - -.. code-block:: javascript - - on_widget_loaded: function (widgets) { - var widget = widgets[0]; - var url = _.sprintf( - '/web_dashboard/widgets/content?session_id=%s&widget_id=%d', - this.session.session_id, widget.id); - this.$element.html(QWeb.render('HomeWidget.content', { - widget: widget, - url: url - })); - } diff --git a/doc/source/guides/sidebar-protocol.rst b/doc/source/guides/sidebar-protocol.rst deleted file mode 100644 index 83626c32fc3..00000000000 --- a/doc/source/guides/sidebar-protocol.rst +++ /dev/null @@ -1,78 +0,0 @@ -Adding a sidebar to a view -========================== - -Initialization --------------- - -Each view has the responsibility to create its sidebar (or not) if and only if -the ``sidebar`` flag is set in its options. - -In that case, it should use the ``sidebar_id`` value (from its options) to -initialize the sidebar at the right position in the DOM: - -.. code-block:: javascript - - if (this.options.sidebar && this.options.sidebar_id) { - this.sidebar = new openerp.web.Sidebar(this, this.options.sidebar_id); - this.sidebar.start(); - } - -Because the sidebar is an old-style widget, it must be started after being -initialized. - -Sidebar communication protocol ------------------------------- - -In order to behave correctly, a sidebar needs informations from its parent -view. - -This information is extracted via a very basic protocol consisting of a -property and two methods: - -.. js:attribute:: dataset - - the view's dataset, used to fetch the currently active model and provide it - to remote action handlers as part of the basic context - -.. js:function:: get_selected_ids() - - Used to query the parent view for the set of currently available record - identifiers. Used to setup the basic context's ``active_id`` and - ``active_ids`` keys. - - .. warning:: - - :js:func:`get_selected_ids` must return at least one id - - :returns: an array of at least one id - :rtype: Array<Number> - -.. js:function:: sidebar_context() - - Queries the view for additional context data to provide to the sidebar. - - :js:class:`~openerp.base.View` provides a default NOOP implementation, - which simply resolves to an empty object. - - :returns: a promise yielding an object on success, this object is mergeed - into the sidebar's own context - :rtype: $.Deferred<Object> - -Programmatic folding and unfolding ----------------------------------- - -The sidebar object starts folded. It provides three methods to handle its -folding status: - -.. js:function:: do_toggle - - Toggles the status of the sidebar - -.. js:function:: do_fold - - Forces the sidebar closed if it's currently open - -.. js:function:: do_unfold - - Forces the sidebar open if it's currently closed - |
