openerp-dev-web team mailing list archive

[Daniel Watkins <daniel@xxxxxxxxxxxxxxxxxxxx>]

Daniel Watkins has proposed merging lp:~daniel-thewatkins/openobject-client-web/proto61-doc-fixes into lp:~openerp-dev/openobject-client-web/trunk-proto61 with lp:~daniel-thewatkins/openobject-client-web/proto61-fix-simplified-interface as a prerequisite.

Requested reviews:
  OpenERP R&D Team (openerp-dev)

For more details, see:
https://code.launchpad.net/~daniel-thewatkins/openobject-client-web/proto61-doc-fixes/+merge/57833

A number of doc fixes.  Easy to do when tired on the train.

Apparently I failed to branch from trunk when making the changes (see the "tired on train" comment), so I've added the dependency on my other branch.
-- 
https://code.launchpad.net/~daniel-thewatkins/openobject-client-web/proto61-doc-fixes/+merge/57833
Your team OpenERP R&D Team is requested to review the proposed merge of lp:~daniel-thewatkins/openobject-client-web/proto61-doc-fixes into lp:~openerp-dev/openobject-client-web/trunk-proto61.

=== modified file 'doc/source/development.rst'
--- doc/source/development.rst	2011-03-28 19:48:09 +0000
+++ doc/source/development.rst	2011-04-15 09:42:38 +0000
@@ -55,7 +55,7 @@
   Event triggered after a user asked for a search. The search view
   fires this event after collecting all input data (contexts, domains
   and group_by contexts). Note that the search view does *not* merge
-  those (or therwise evaluate them), they are returned as provided by
+  those (or otherwise evaluate them), they are returned as provided by
   the various inputs within the view.
 
 ``on_clear``
@@ -71,7 +71,7 @@
 an informal protocol and an abstract type that can be inherited from.
 
 Inputs are widgets which can contain user data (a char widget for
-instance, or a selection box). They are able of action and of
+instance, or a selection box). They are capable of action and of
 reaction:
 
 .. _views-search-registration:
@@ -93,9 +93,9 @@
   * Return a context (an object), this is the "normal" response if the
     input holds a value.
 
-  * Return a falsy value (generally ``null``). This value indicates
-    the input does not contain any value and will not take part in the
-    research.
+  * Return a value that evaluates as false (generally ``null``). This
+    value indicates the input does not contain any value and will not
+    affect the results of the search.
 
   * Raise :js:class:`openerp.base.search.Invalid` to indicate that it
     holds a value but this value can not be used in the search
@@ -104,7 +104,7 @@
     the search process.
 
     :js:class:`~openerp.base.search.Invalid` takes three mandatory
-    arguments: an indentifier (a name for instance), the invalid value
+    arguments: an identifier (a name for instance), the invalid value,
     and a validation message indicating the issue.
 
 ``get_domain``
@@ -114,11 +114,11 @@
 
 The :js:class:`openerp.base.search.Input` type implements registration
 on its own, but its implementations of ``get_context`` and
-``get_domain`` simply raise errors and *have* to be overridden.
+``get_domain`` simply raise errors and *must* be overridden.
 
 One last action is for filters, as an activation order has to be kept
-on them for some controls (establish the correct grouping sequence for
-instance).
+on them for some controls (to establish the correct grouping sequence,
+for instance).
 
 To that end, filters can call
 :js:func:`openerp.base.Search.do_toggle_filter`, providing themselves
@@ -137,7 +137,7 @@
 
 The search view has a pretty simple and linear life cycle, in three main steps:
 
-:js:class:`init <openerp.base.SearchView>`
+:js:class:`~openerp.base.SearchView.init`
 
   Nothing interesting happens here
 
@@ -211,7 +211,7 @@
   Gives the widget the opportunity to unbind its events, remove itself
   from the DOM and perform any other cleanup task it may have.
 
-  Event if the widget does not do anything itself, it is responsible
+  Even if the widget does not do anything itself, it is responsible
   for shutting down its children.
 
 An abstract type is available and can be inherited from, to simplify
@@ -232,7 +232,8 @@
   <views-search-registration>`.
 
   If inherited from, descendant classes should not call its
-  implementations of ``get_context`` and ``get_domain``.
+  implementations of :js:func:`~openerp.base.search.Input.get_context`
+  and :js:func:`~openerp.base.search.Input.get_domain`.
 
 * :js:class:`openerp.base.search.Field` is used to implement more
   "field" widgets (which allow the user to input potentially complex
@@ -251,7 +252,7 @@
     :js:func:`~openerp.base.search.Widget.make_id`.
 
   * It sets up a basic (overridable)
-    :js:attr:`~opererp.base.search.Field.template` attribute, combined
+    :js:attr:`~openerp.base.search.Field.template` attribute, combined
     with the previous tasks, this makes subclasses of
     :js:class:`~openerp.base.search.Field` render themselves "for
     free".

=== modified file 'doc/source/project.rst'
--- doc/source/project.rst	2011-04-12 20:06:46 +0000
+++ doc/source/project.rst	2011-04-15 09:42:38 +0000
@@ -31,7 +31,7 @@
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The meat and most important part of all documentation. Should be
-written in plain english, using reStructuredText_ and taking advantage
+written in plain English, using reStructuredText_ and taking advantage
 of `Sphinx's extensions`_, especially `cross-references`_.
 
 Python API Documentation
@@ -65,7 +65,7 @@
   and ``__new__``), using the `info fields`_  as well.
 
 * Attributes (class and instance) should be documented in their
-  class's docstrin via the ``.. attribute::`` directiveg, following
+  class's docstring via the ``.. attribute::`` directiveg, following
   the class's own documentation.
 
 * The relation between modules and module-level attributes is similar:
@@ -220,7 +220,7 @@
 Release notes
 +++++++++++++
 
-.. [#] because Python is the default domain, the ``py:`` markup prefix
+.. [#] Because Python is the default domain, the ``py:`` markup prefix
        is optional and should be left out.
 
 .. [#] Resig's Class still uses prototypes under the hood, it doesn't

=== modified file 'openerpweb/openerpweb.py'
--- openerpweb/openerpweb.py	2011-04-13 12:50:42 +0000
+++ openerpweb/openerpweb.py	2011-04-15 09:42:38 +0000
@@ -289,13 +289,34 @@
     * the json string is passed as a form parameter named "request"
     * method is currently ignored
 
-    Sucessful request:
-    --> {"jsonrpc": "2.0", "method": "call", "params": {"session_id": "SID", "context": {}, "arg1": "val1" }, "id": null}
-    <-- {"jsonrpc": "2.0", "result": { "res1": "val1" }, "id": null}
-
-    Request producing a error:
-    --> {"jsonrpc": "2.0", "method": "call", "params": {"session_id": "SID", "context": {}, "arg1": "val1" }, "id": null}
-    <-- {"jsonrpc": "2.0", "error": {"code": 1, "message": "End user error message.", "data": {"code": "codestring", "debug": "traceback" } }, "id": null}
+    Sucessful request::
+
+      --> {"jsonrpc": "2.0",
+           "method": "call",
+           "params": {"session_id": "SID",
+                      "context": {},
+                      "arg1": "val1" },
+           "id": null}
+
+      <-- {"jsonrpc": "2.0",
+           "result": { "res1": "val1" },
+           "id": null}
+
+    Request producing a error::
+
+      --> {"jsonrpc": "2.0",
+           "method": "call",
+           "params": {"session_id": "SID",
+                      "context": {},
+                      "arg1": "val1" },
+           "id": null}
+
+      <-- {"jsonrpc": "2.0",
+           "error": {"code": 1,
+                     "message": "End user error message.",
+                     "data": {"code": "codestring",
+                              "debug": "traceback" } },
+           "id": null}
 
     """