diff options
Diffstat (limited to 'doc/reference/javascript.rst')
| -rw-r--r-- | doc/reference/javascript.rst | 110 |
1 files changed, 55 insertions, 55 deletions
diff --git a/doc/reference/javascript.rst b/doc/reference/javascript.rst index 342d8484b67..2a1e2b3a018 100644 --- a/doc/reference/javascript.rst +++ b/doc/reference/javascript.rst @@ -457,8 +457,8 @@ with three differences: :func:`~Model.query` is a shortcut for a builder-style interface to searches (``search`` + ``read`` in Odoo RPC terms). It -returns a :class:`~openerp.web.Query` object which is immutable but -allows building new :class:`~openerp.web.Query` instances from the +returns a :class:`~odoo.web.Query` object which is immutable but +allows building new :class:`~odoo.web.Query` instances from the first one, adding new properties or modifiying the parent object's:: Users.query(['name', 'login', 'user_email', 'signature']) @@ -469,8 +469,8 @@ first one, adding new properties or modifiying the parent object's:: }); The query is only actually performed when calling one of the query -serialization methods, :func:`~openerp.web.Query.all` and -:func:`~openerp.web.Query.first`. These methods will perform a new +serialization methods, :func:`~odoo.web.Query.all` and +:func:`~odoo.web.Query.first`. These methods will perform a new RPC call every time they are called. For that reason, it's actually possible to keep "intermediate" queries @@ -499,38 +499,38 @@ around and use them differently/add new specifications on them. :param Array<String> fields: list of fields to fetch during the search - :returns: a :class:`~openerp.web.Query` object + :returns: a :class:`~odoo.web.Query` object representing the search to perform -.. class:: openerp.web.Query(fields) +.. class:: odoo.web.Query(fields) The first set of methods is the "fetching" methods. They perform RPC queries using the internal data of the object they're called on. - .. function:: openerp.web.Query.all() + .. function:: odoo.web.Query.all() - Fetches the result of the current :class:`~openerp.web.Query` object's + Fetches the result of the current :class:`~odoo.web.Query` object's search. :rtype: Deferred<Array<>> - .. function:: openerp.web.Query.first() + .. function:: odoo.web.Query.first() Fetches the **first** result of the current - :class:`~openerp.web.Query`, or ``null`` if the current - :class:`~openerp.web.Query` does have any result. + :class:`~odoo.web.Query`, or ``null`` if the current + :class:`~odoo.web.Query` does have any result. :rtype: Deferred<Object | null> - .. function:: openerp.web.Query.count() + .. function:: odoo.web.Query.count() Fetches the number of records the current - :class:`~openerp.web.Query` would retrieve. + :class:`~odoo.web.Query` would retrieve. :rtype: Deferred<Number> - .. function:: openerp.web.Query.group_by(grouping...) + .. function:: odoo.web.Query.group_by(grouping...) Fetches the groups for the query, using the first specified grouping parameter @@ -539,18 +539,18 @@ around and use them differently/add new specifications on them. asked of the server. Grouping can actually be an array or varargs. - :rtype: Deferred<Array<openerp.web.QueryGroup>> | null + :rtype: Deferred<Array<odoo.web.QueryGroup>> | null The second set of methods is the "mutator" methods, they create a - **new** :class:`~openerp.web.Query` object with the relevant + **new** :class:`~odoo.web.Query` object with the relevant (internal) attribute either augmented or replaced. - .. function:: openerp.web.Query.context(ctx) + .. function:: odoo.web.Query.context(ctx) Adds the provided ``ctx`` to the query, on top of any existing context - .. function:: openerp.web.Query.filter(domain) + .. function:: odoo.web.Query.filter(domain) Adds the provided domain to the query, this domain is ``AND``-ed to the existing query domain. @@ -560,12 +560,12 @@ around and use them differently/add new specifications on them. Sets the provided offset on the query. The new offset *replaces* the old one. - .. function:: openerp.web.Query.limit(limit) + .. function:: odoo.web.Query.limit(limit) Sets the provided limit on the query. The new limit *replaces* the old one. - .. function:: openerp.web.Query.order_by(fields…) + .. function:: odoo.web.Query.order_by(fields…) Overrides the model's natural order with the provided field specifications. Behaves much like Django's :py:meth:`QuerySet.order_by @@ -589,11 +589,11 @@ Aggregation (grouping) Odoo has powerful grouping capacities, but they are kind-of strange in that they're recursive, and level n+1 relies on data provided directly by the grouping at level n. As a result, while -:py:meth:`openerp.models.Model.read_group` works it's not a very intuitive +:py:meth:`odoo.models.Model.read_group` works it's not a very intuitive API. -Odoo Web eschews direct calls to :py:meth:`~openerp.models.Model.read_group` -in favor of calling a method of :class:`~openerp.web.Query`, :py:meth:`much +Odoo Web eschews direct calls to :py:meth:`~odoo.models.Model.read_group` +in favor of calling a method of :class:`~odoo.web.Query`, :py:meth:`much in the way it is one in SQLAlchemy <sqlalchemy.orm.query.Query.group_by>` [#terminal]_:: @@ -634,12 +634,12 @@ regular query for records): } }); -The result of a (successful) :func:`~openerp.web.Query.group_by` is -an array of :class:`~openerp.web.QueryGroup`: +The result of a (successful) :func:`~odoo.web.Query.group_by` is +an array of :class:`~odoo.web.QueryGroup`: -.. class:: openerp.web.QueryGroup +.. class:: odoo.web.QueryGroup - .. function:: openerp.web.QueryGroup.get(key) + .. function:: odoo.web.QueryGroup.get(key) returns the group's attribute ``key``. Known attributes are: @@ -652,16 +652,16 @@ an array of :class:`~openerp.web.QueryGroup`: ``aggregates`` a {field: value} mapping of aggregations for the group - .. function:: openerp.web.QueryGroup.query([fields...]) + .. function:: odoo.web.QueryGroup.query([fields...]) equivalent to :func:`Model.query` but pre-filtered to only include the records within this group. Returns a - :class:`~openerp.web.Query` which can be further manipulated as + :class:`~odoo.web.Query` which can be further manipulated as usual. - .. function:: openerp.web.QueryGroup.subgroups() + .. function:: odoo.web.QueryGroup.subgroups() - returns a deferred to an array of :class:`~openerp.web.QueryGroup` + returns a deferred to an array of :class:`~odoo.web.QueryGroup` below this one Low-level API: RPC calls to Python side @@ -720,7 +720,7 @@ It has also some disadvantages: that one needs to be careful. This is obviously a very large change and will require everyone to -adopt new habits. For example, the variable openerp does not exist +adopt new habits. For example, the variable odoo does not exist anymore. The new way of doing things is to import explicitely the module you need, and declaring explicitely the objects you export. Here is a simple example:: @@ -790,7 +790,7 @@ Here is a description of the current file structure: * ``web.Widget`` contains the widget class * ``web.Model`` is an abstraction over ``web.ajax`` to make calls to the server model methods - * ``web.session`` is the former ``openerp.session`` + * ``web.session`` is the former ``odoo.session`` * ``web.utils`` for useful code snippets * ``web.time`` for every time-related generic functions * the ``views/`` folder contains all view definitions @@ -807,8 +807,8 @@ The ``js/`` folder also contains some important files: The two other files are ``tour.js`` for the tours and ``compatibility.js``. The latter file is a compatibility layer bridging the old system to the new module system. This is where every module names are exported to the -global variable ``openerp``. In theory, our addons should work without -ever using the variable ``openerp``, and the compatibility module can be +global variable ``odoo``. In theory, our addons should work without +ever using the variable ``odoo``, and the compatibility module can be disabled safely. Javascript conventions @@ -888,19 +888,19 @@ and allow running all of its (0 so far) tests: The next step is to create a test case:: - openerp.testing.section('basic section', function (test) { + odoo.testing.section('basic section', function (test) { test('my first test', function () { ok(false, "this test has run"); }); }); -All testing helpers and structures live in the ``openerp.testing`` -module. Odoo tests live in a :func:`~openerp.testing.section`, +All testing helpers and structures live in the ``odoo.testing`` +module. Odoo tests live in a :func:`~odoo.testing.section`, which is itself part of a module. The first argument to a section is the name of the section, the second one is the section body. -:func:`test <openerp.testing.case>`, provided by the -:func:`~openerp.testing.section` to the callback, is used to +:func:`test <odoo.testing.case>`, provided by the +:func:`~odoo.testing.section` to the callback, is used to register a given test case which will be run whenever the test runner actually does its job. Odoo Web test case use standard `QUnit assertions`_ within them. @@ -995,7 +995,7 @@ test module: :: // src/js/demo.js - openerp.web_tests_demo = function (instance) { + odoo.web_tests_demo = function (instance) { instance.web_tests_demo = { value_true: true, SomeType: instance.web.Class.extend({ @@ -1022,7 +1022,7 @@ DOM Scratchpad As in the wider client, arbitrarily accessing document content is strongly discouraged during tests. But DOM access is still needed to -e.g. fully initialize :class:`widgets <~openerp.Widget>` before +e.g. fully initialize :class:`widgets <~odoo.Widget>` before testing them. Thus, a test case gets a DOM scratchpad as its second positional @@ -1054,7 +1054,7 @@ To avoid the corresponding processing costs, by default templates are not loaded into QWeb. If you need to render e.g. widgets making use of QWeb templates, you can request their loading through the :attr:`~TestOptions.templates` option to the :func:`test case -function <openerp.testing.case>`. +function <odoo.testing.case>`. This will automatically load all relevant templates in the instance's qweb before running the test case: @@ -1161,7 +1161,7 @@ To enable mock RPC, set the :attr:`rpc option <TestOptions.rpc>` to * If it matches the pattern ``model:method`` (if it contains a colon, essentially) the call will set up the mocking of an RPC call straight to the Odoo server (through XMLRPC) as - performed via e.g. :func:`openerp.web.Model.call`. + performed via e.g. :func:`odoo.web.Model.call`. In that case, ``handler`` should be a function taking two arguments ``args`` and ``kwargs``, matching the corresponding @@ -1209,7 +1209,7 @@ To enable mock RPC, set the :attr:`rpc option <TestOptions.rpc>` to }); // widget needs that or it blows up - instance.webclient = {toggle_bars: openerp.testing.noop}; + instance.webclient = {toggle_bars: odoo.testing.noop}; var dbm = new instance.web.DatabaseManager({}); return dbm.appendTo($s).then(function () { ok(fetched_dbs, "should have fetched databases"); @@ -1228,7 +1228,7 @@ To enable mock RPC, set the :attr:`rpc option <TestOptions.rpc>` to Testing API ----------- -.. function:: openerp.testing.section(name[, options], body) +.. function:: odoo.testing.section(name[, options], body) A test section, serves as shared namespace for related tests (for constants or values to only set up once). The ``body`` function @@ -1240,9 +1240,9 @@ Testing API :param String name: :param TestOptions options: :param body: - :type body: Function<:func:`~openerp.testing.case`, void> + :type body: Function<:func:`~odoo.testing.case`, void> -.. function:: openerp.testing.case(name[, options], callback) +.. function:: odoo.testing.case(name[, options], callback) Registers a test case callback in the test runner, the callback will only be run once the runner is started (or maybe not at all, @@ -1256,16 +1256,16 @@ Testing API .. class:: TestOptions the various options which can be passed to - :func:`~openerp.testing.section` or - :func:`~openerp.testing.case`. Except for + :func:`~odoo.testing.section` or + :func:`~odoo.testing.case`. Except for :attr:`~TestOptions.setup` and :attr:`~TestOptions.teardown`, an option on - :func:`~openerp.testing.case` will overwrite the corresponding - option on :func:`~openerp.testing.section` so + :func:`~odoo.testing.case` will overwrite the corresponding + option on :func:`~odoo.testing.section` so e.g. :attr:`~TestOptions.rpc` can be set for a - :func:`~openerp.testing.section` and then differently set for - some :func:`~openerp.testing.case` of that - :func:`~openerp.testing.section` + :func:`~odoo.testing.section` and then differently set for + some :func:`~odoo.testing.case` of that + :func:`~odoo.testing.section` .. attribute:: TestOptions.asserts |