addons/web/doc/changelog-7.0.rst

   1 API changes from OpenERP Web 6.1 to 7.0
   2 =======================================
   3
   4 Supported browsers
   5 ------------------
   6
   7 The OpenERP Web Client supports the following web browsers:
   8
   9 * Internet Explorer 9+
  10 * Google Chrome 22+
  11 * Firefox 13+
  12 * Any browser using the latest version of Chrome Frame
  13
  14 DataSet -> Model
  15 ----------------
  16
  17 The 6.1 ``DataSet`` API has been deprecated in favor of the smaller
  18 and more orthogonal :doc:`Model </rpc>` API, which more closely
  19 matches the API in OpenERP Web's Python side and in OpenObject addons
  20 and removes most stateful behavior of DataSet.
  21
  22 Migration guide
  23 ~~~~~~~~~~~~~~~
  24
  25 * Actual arbitrary RPC calls can just be remapped on a
  26   :js:class:`~openerp.web.Model` instance:
  27
  28   .. code-block:: javascript
  29
  30       dataset.call(method, args)
  31
  32   or
  33
  34   .. code-block:: javascript
  35
  36       dataset.call_and_eval(method, args)
  37
  38   can be replaced by calls to :js:func:`openerp.web.Model.call`:
  39
  40   .. code-block:: javascript
  41
  42       model.call(method, args)
  43
  44   If callbacks are passed directly to the older methods, they need to
  45   be added to the new one via ``.then()``.
  46
  47   .. note::
  48
  49       The ``context_index`` and ``domain_index`` features were not
  50       ported, context and domain now need to be passed in "in full",
  51       they won't be automatically filled with the user's current
  52       context.
  53
  54 * Shorcut methods (``name_get``, ``name_search``, ``unlink``,
  55   ``write``, ...) should be ported to
  56   :js:func:`openerp.web.Model.call`, using the server's original
  57   signature. On the other hand, the non-shortcut equivalents can now
  58   use keyword arguments (see :js:func:`~openerp.web.Model.call`'s
  59   signature for details)
  60
  61 * ``read_slice``, which allowed a single round-trip to perform a
  62   search and a read, should be reimplemented via
  63   :js:class:`~openerp.web.Query` objects (see:
  64   :js:func:`~openerp.web.Model.query`) for clearer and simpler
  65   code. ``read_index`` should be replaced by a
  66   :js:class:`~openerp.web.Query` as well, combining
  67   :js:func:`~openerp.web.Query.offset` and
  68   :js:func:`~openerp.web.Query.first`.
  69
  70 Rationale
  71 ~~~~~~~~~
  72
  73 Renaming
  74
  75     The name *DataSet* exists in the CS community consciousness, and
  76     (as its name implies) it's a set of data (often fetched from a
  77     database, maybe lazily). OpenERP Web's dataset behaves very
  78     differently as it does not store (much) data (only a bunch of ids
  79     and just enough state to break things). The name "Model" matches
  80     the one used on the Python side for the task of building an RPC
  81     proxy to OpenERP objects.
  82
  83 API simplification
  84
  85     ``DataSet`` has a number of methods which serve as little more
  86     than shortcuts, or are there due to domain and context evaluation
  87     issues in 6.1.
  88
  89     The shortcuts really add little value, and OpenERP Web 6.2 embeds
  90     a restricted Python evaluator (in javascript) meaning most of the
  91     context and domain parsing & evaluation can be moved to the
  92     javascript code and does not require cooperative RPC bridging.
  93
  94 DataGroup -> also Model
  95 -----------------------
  96
  97 Alongside the deprecation of ``DataSet`` for
  98 :js:class:`~openerp.web.Model`, OpenERP Web 7.0 removes
  99 ``DataGroup`` and its subtypes as public objects in favor of a single method on
 100 :js:class:`~openerp.web.Query`:
 101 :js:func:`~openerp.web.Query.group_by`.
 102
 103 Migration guide
 104 ~~~~~~~~~~~~~~~
 105
 106 Rationale
 107 ~~~~~~~~~
 108
 109 While the ``DataGroup`` API worked (mostly), it is quite odd and
 110 alien-looking, a bit too Smalltalk-inspired (behaves like a
 111 self-contained flow-control structure for reasons which may or may not
 112 have been good).
 113
 114 Because it is heavily related to ``DataSet`` (as it *yields*
 115 ``DataSet`` objects), deprecating ``DataSet`` automatically deprecates
 116 ``DataGroup`` (if we want to stay consistent), which is a good time to
 117 make the API more imperative and look more like what most developers
 118 are used to.
 119
 120 But as ``DataGroup`` users in 6.1 were rare (and there really was little reason
 121 to use it), it has been removed as a public API.
 122
 123