summaryrefslogtreecommitdiff
path: root/doc/source/guides
diff options
context:
space:
mode:
authorOpenerp Online <online@openerp.com>2012-03-05 13:40:16 +0100
committerOpenerp Online <online@openerp.com>2012-03-05 13:40:16 +0100
commit0c8e11643f84afddec07f21b6f7fc2b981fb2706 (patch)
tree73e29a0f5409688fdcc513b488c169dba2febdfd /doc/source/guides
parentba3193dd4d5aa2a138899c2ac55b3e7fa7768256 (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.rst92
-rw-r--r--doc/source/guides/sidebar-protocol.rst78
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
-