[FIX] versions and class names in doc
authorXavier Morel <xmo@openerp.com>
Tue, 2 Oct 2012 13:50:53 +0000 (15:50 +0200)
committerXavier Morel <xmo@openerp.com>
Tue, 2 Oct 2012 13:50:53 +0000 (15:50 +0200)
bzr revid: xmo@openerp.com-20121002135053-0br6kzif8tmarltp

doc/changelog-6.2.rst [deleted file]
doc/changelog-7.0.rst [new file with mode: 0644]
doc/conf.py
doc/index.rst
doc/rpc.rst

diff --git a/doc/changelog-6.2.rst b/doc/changelog-6.2.rst
deleted file mode 100644 (file)
index 48d79bf..0000000
+++ /dev/null
@@ -1,108 +0,0 @@
-API changes from OpenERP Web 6.1 to 6.2
-=======================================
-
-DataSet -> Model
-----------------
-
-The 6.1 ``DataSet`` API has been deprecated in favor of the smaller
-and more orthogonal :doc:`Model </rpc>` API, which more closely
-matches the API in OpenERP Web's Python side and in OpenObject addons
-and removes most stateful behavior of DataSet.
-
-Migration guide
-~~~~~~~~~~~~~~~
-
-* Actual arbitrary RPC calls can just be remapped on a
-  :js:class:`~openerp.web.Model` instance:
-
-  .. code-block:: javascript
-
-      dataset.call(method, args)
-
-  or
-
-  .. code-block:: javascript
-
-      dataset.call_and_eval(method, args)
-
-  can be replaced by calls to :js:func:`openerp.web.Model.call`:
-
-  .. code-block:: javascript
-
-      model.call(method, args)
-
-  If callbacks are passed directly to the older methods, they need to
-  be added to the new one via ``.then()``.
-
-  .. note::
-
-      The ``context_index`` and ``domain_index`` features were not
-      ported, context and domain now need to be passed in "in full",
-      they won't be automatically filled with the user's current
-      context.
-
-* Shorcut methods (``name_get``, ``name_search``, ``unlink``,
-  ``write``, ...) should be ported to
-  :js:func:`openerp.web.Model.call`, using the server's original
-  signature. On the other hand, the non-shortcut equivalents can now
-  use keyword arguments (see :js:func:`~openerp.web.Model.call`'s
-  signature for details)
-
-* ``read_slice``, which allowed a single round-trip to perform a
-  search and a read, should be reimplemented via
-  :js:class:`~openerp.web.Query` objects (see:
-  :js:func:`~openerp.web.Model.query`) for clearer and simpler
-  code. ``read_index`` should be replaced by a
-  :js:class:`~openerp.web.Query` as well, combining
-  :js:func:`~openerp.web.Query.offset` and
-  :js:func:`~openerp.web.Query.first`.
-
-Rationale
-~~~~~~~~~
-
-Renaming
-
-    The name *DataSet* exists in the CS community consciousness, and
-    (as its name implies) it's a set of data (often fetched from a
-    database, maybe lazily). OpenERP Web's dataset behaves very
-    differently as it does not store (much) data (only a bunch of ids
-    and just enough state to break things). The name "Model" matches
-    the one used on the Python side for the task of building an RPC
-    proxy to OpenERP objects.
-
-API simplification
-
-    ``DataSet`` has a number of methods which serve as little more
-    than shortcuts, or are there due to domain and context evaluation
-    issues in 6.1.
-
-    The shortcuts really add little value, and OpenERP Web 6.2 embeds
-    a restricted Python evaluator (in javascript) meaning most of the
-    context and domain parsing & evaluation can be moved to the
-    javascript code and does not require cooperative RPC bridging.
-
-DataGroup -> also Model
------------------------
-
-Alongside the deprecation of ``DataSet`` for
-:js:class:`~openerp.web.Model`, OpenERP Web 6.2 also deprecates
-``DataGroup`` and its subtypes in favor of a single method on
-:js:class:`~openerp.web.Query`:
-:js:func:`~openerp.web.Query.group_by`.
-
-Migration guide
-~~~~~~~~~~~~~~~
-
-Rationale
-~~~~~~~~~
-
-While the ``DataGroup`` API worked (mostly), it is quite odd and
-alien-looking, a bit too Smalltalk-inspired (behaves like a
-self-contained flow-control structure for reasons which may or may not
-have been good).
-
-Because it is heavily related to ``DataSet`` (as it *yields*
-``DataSet`` objects), deprecating ``DataSet`` automatically deprecates
-``DataGroup`` (if we want to stay consistent), which is a good time to
-make the API more imperative and look more like what most developers
-are used to.
diff --git a/doc/changelog-7.0.rst b/doc/changelog-7.0.rst
new file mode 100644 (file)
index 0000000..00d0236
--- /dev/null
@@ -0,0 +1,108 @@
+API changes from OpenERP Web 6.1 to 7.0
+=======================================
+
+DataSet -> Model
+----------------
+
+The 6.1 ``DataSet`` API has been deprecated in favor of the smaller
+and more orthogonal :doc:`Model </rpc>` API, which more closely
+matches the API in OpenERP Web's Python side and in OpenObject addons
+and removes most stateful behavior of DataSet.
+
+Migration guide
+~~~~~~~~~~~~~~~
+
+* Actual arbitrary RPC calls can just be remapped on a
+  :js:class:`~openerp.web.Model` instance:
+
+  .. code-block:: javascript
+
+      dataset.call(method, args)
+
+  or
+
+  .. code-block:: javascript
+
+      dataset.call_and_eval(method, args)
+
+  can be replaced by calls to :js:func:`openerp.web.Model.call`:
+
+  .. code-block:: javascript
+
+      model.call(method, args)
+
+  If callbacks are passed directly to the older methods, they need to
+  be added to the new one via ``.then()``.
+
+  .. note::
+
+      The ``context_index`` and ``domain_index`` features were not
+      ported, context and domain now need to be passed in "in full",
+      they won't be automatically filled with the user's current
+      context.
+
+* Shorcut methods (``name_get``, ``name_search``, ``unlink``,
+  ``write``, ...) should be ported to
+  :js:func:`openerp.web.Model.call`, using the server's original
+  signature. On the other hand, the non-shortcut equivalents can now
+  use keyword arguments (see :js:func:`~openerp.web.Model.call`'s
+  signature for details)
+
+* ``read_slice``, which allowed a single round-trip to perform a
+  search and a read, should be reimplemented via
+  :js:class:`~openerp.web.Query` objects (see:
+  :js:func:`~openerp.web.Model.query`) for clearer and simpler
+  code. ``read_index`` should be replaced by a
+  :js:class:`~openerp.web.Query` as well, combining
+  :js:func:`~openerp.web.Query.offset` and
+  :js:func:`~openerp.web.Query.first`.
+
+Rationale
+~~~~~~~~~
+
+Renaming
+
+    The name *DataSet* exists in the CS community consciousness, and
+    (as its name implies) it's a set of data (often fetched from a
+    database, maybe lazily). OpenERP Web's dataset behaves very
+    differently as it does not store (much) data (only a bunch of ids
+    and just enough state to break things). The name "Model" matches
+    the one used on the Python side for the task of building an RPC
+    proxy to OpenERP objects.
+
+API simplification
+
+    ``DataSet`` has a number of methods which serve as little more
+    than shortcuts, or are there due to domain and context evaluation
+    issues in 6.1.
+
+    The shortcuts really add little value, and OpenERP Web 6.2 embeds
+    a restricted Python evaluator (in javascript) meaning most of the
+    context and domain parsing & evaluation can be moved to the
+    javascript code and does not require cooperative RPC bridging.
+
+DataGroup -> also Model
+-----------------------
+
+Alongside the deprecation of ``DataSet`` for
+:js:class:`~openerp.web.Model`, OpenERP Web 7.0 also deprecates
+``DataGroup`` and its subtypes in favor of a single method on
+:js:class:`~openerp.web.Query`:
+:js:func:`~openerp.web.Query.group_by`.
+
+Migration guide
+~~~~~~~~~~~~~~~
+
+Rationale
+~~~~~~~~~
+
+While the ``DataGroup`` API worked (mostly), it is quite odd and
+alien-looking, a bit too Smalltalk-inspired (behaves like a
+self-contained flow-control structure for reasons which may or may not
+have been good).
+
+Because it is heavily related to ``DataSet`` (as it *yields*
+``DataSet`` objects), deprecating ``DataSet`` automatically deprecates
+``DataGroup`` (if we want to stay consistent), which is a good time to
+make the API more imperative and look more like what most developers
+are used to.
index a5ff6be..83fc969 100644 (file)
@@ -50,9 +50,9 @@ copyright = u'2012, OpenERP s.a.'
 # built documents.
 #
 # The short X.Y version.
-version = '6.1'
+version = '7.0'
 # The full version, including alpha/beta/rc tags.
-release = '6.1'
+release = '7.0'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
index 2598ab7..4aa9dcd 100644 (file)
@@ -11,7 +11,7 @@ Contents:
 .. toctree::
     :maxdepth: 1
 
-    changelog-6.2
+    changelog-7.0
 
     async
     rpc
index d083f87..4787978 100644 (file)
@@ -137,7 +137,7 @@ 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.Group>> | null
+       :rtype: Deferred<Array<openerp.web.QueryGroup>> | null
 
     The second set of methods is the "mutator" methods, they create a
     **new** :js:class:`~openerp.web.Query` object with the relevant
@@ -189,7 +189,7 @@ in that they're recursive, and level n+1 relies on data provided
 directly by the grouping at level n. As a result, while ``read_group``
 works it's not a very intuitive API.
 
-OpenERP Web 6.2 eschews direct calls to ``read_group`` in favor of
+OpenERP Web 7.0 eschews direct calls to ``read_group`` in favor of
 calling a method of :js:class:`~openerp.web.Query`, `much in the way
 it is one in SQLAlchemy
 <http://docs.sqlalchemy.org/en/latest/orm/query.html#sqlalchemy.orm.query.Query.group_by>`_ [#]_:
@@ -238,7 +238,7 @@ regular query for records):
       });
 
 The result of a (successful) :js:func:`~openerp.web.Query.group_by` is
-an array of :js:class:`~openerp.web.data.Group`.
+an array of :js:class:`~openerp.web.QueryGroup`.
 
 Low-level API: RPC calls to Python side
 ---------------------------------------