Merge lp:~oddbloke/openobject-client-web/proto61-doc-fixes into lp:~openerp-dev/openobject-client-web/trunk-proto61

Proposed by Dan Watkins
Status: Merged
Approved by: Xavier (Open ERP)
Approved revision: 4765
Merged at revision: 4757
Proposed branch: lp:~oddbloke/openobject-client-web/proto61-doc-fixes
Merge into: lp:~openerp-dev/openobject-client-web/trunk-proto61
Prerequisite: lp:~oddbloke/openobject-client-web/proto61-fix-simplified-interface
Diff against target: 171 lines (+45/-23)
3 files modified
doc/source/development.rst (+14/-13)
doc/source/project.rst (+3/-3)
openerpweb/openerpweb.py (+28/-7)
To merge this branch: bzr merge lp:~oddbloke/openobject-client-web/proto61-doc-fixes
Reviewer Review Type Date Requested Status
Xavier (Open ERP) (community) Approve
Review via email: mp+57833@code.launchpad.net

This proposal supersedes a proposal from 2011-04-14.

Description of the change

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.

To post a comment you must log in.
Revision history for this message
Xavier (Open ERP) (xmo-deactivatedaccount) wrote :

Looks good to me (one more typo missed: in the second-to-last diff, doc/source/project.rst {-65,7 +65,7}, ``directiveg`` should probably be ``directive``, that seems to be where the missing ``g`` of ``docstrin`` ended up)

review: Approve
Revision history for this message
Xavier (Open ERP) (xmo-deactivatedaccount) wrote :

Ended up transplanting the commits to a new branch as fme is still reviewing the code in fix-simplified-interface.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'doc/source/development.rst'
2--- doc/source/development.rst 2011-03-28 19:48:09 +0000
3+++ doc/source/development.rst 2011-04-15 09:42:38 +0000
4@@ -55,7 +55,7 @@
5 Event triggered after a user asked for a search. The search view
6 fires this event after collecting all input data (contexts, domains
7 and group_by contexts). Note that the search view does *not* merge
8- those (or therwise evaluate them), they are returned as provided by
9+ those (or otherwise evaluate them), they are returned as provided by
10 the various inputs within the view.
11
12 ``on_clear``
13@@ -71,7 +71,7 @@
14 an informal protocol and an abstract type that can be inherited from.
15
16 Inputs are widgets which can contain user data (a char widget for
17-instance, or a selection box). They are able of action and of
18+instance, or a selection box). They are capable of action and of
19 reaction:
20
21 .. _views-search-registration:
22@@ -93,9 +93,9 @@
23 * Return a context (an object), this is the "normal" response if the
24 input holds a value.
25
26- * Return a falsy value (generally ``null``). This value indicates
27- the input does not contain any value and will not take part in the
28- research.
29+ * Return a value that evaluates as false (generally ``null``). This
30+ value indicates the input does not contain any value and will not
31+ affect the results of the search.
32
33 * Raise :js:class:`openerp.base.search.Invalid` to indicate that it
34 holds a value but this value can not be used in the search
35@@ -104,7 +104,7 @@
36 the search process.
37
38 :js:class:`~openerp.base.search.Invalid` takes three mandatory
39- arguments: an indentifier (a name for instance), the invalid value
40+ arguments: an identifier (a name for instance), the invalid value,
41 and a validation message indicating the issue.
42
43 ``get_domain``
44@@ -114,11 +114,11 @@
45
46 The :js:class:`openerp.base.search.Input` type implements registration
47 on its own, but its implementations of ``get_context`` and
48-``get_domain`` simply raise errors and *have* to be overridden.
49+``get_domain`` simply raise errors and *must* be overridden.
50
51 One last action is for filters, as an activation order has to be kept
52-on them for some controls (establish the correct grouping sequence for
53-instance).
54+on them for some controls (to establish the correct grouping sequence,
55+for instance).
56
57 To that end, filters can call
58 :js:func:`openerp.base.Search.do_toggle_filter`, providing themselves
59@@ -137,7 +137,7 @@
60
61 The search view has a pretty simple and linear life cycle, in three main steps:
62
63-:js:class:`init <openerp.base.SearchView>`
64+:js:class:`~openerp.base.SearchView.init`
65
66 Nothing interesting happens here
67
68@@ -211,7 +211,7 @@
69 Gives the widget the opportunity to unbind its events, remove itself
70 from the DOM and perform any other cleanup task it may have.
71
72- Event if the widget does not do anything itself, it is responsible
73+ Even if the widget does not do anything itself, it is responsible
74 for shutting down its children.
75
76 An abstract type is available and can be inherited from, to simplify
77@@ -232,7 +232,8 @@
78 <views-search-registration>`.
79
80 If inherited from, descendant classes should not call its
81- implementations of ``get_context`` and ``get_domain``.
82+ implementations of :js:func:`~openerp.base.search.Input.get_context`
83+ and :js:func:`~openerp.base.search.Input.get_domain`.
84
85 * :js:class:`openerp.base.search.Field` is used to implement more
86 "field" widgets (which allow the user to input potentially complex
87@@ -251,7 +252,7 @@
88 :js:func:`~openerp.base.search.Widget.make_id`.
89
90 * It sets up a basic (overridable)
91- :js:attr:`~opererp.base.search.Field.template` attribute, combined
92+ :js:attr:`~openerp.base.search.Field.template` attribute, combined
93 with the previous tasks, this makes subclasses of
94 :js:class:`~openerp.base.search.Field` render themselves "for
95 free".
96
97=== modified file 'doc/source/project.rst'
98--- doc/source/project.rst 2011-04-12 20:06:46 +0000
99+++ doc/source/project.rst 2011-04-15 09:42:38 +0000
100@@ -31,7 +31,7 @@
101 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
102
103 The meat and most important part of all documentation. Should be
104-written in plain english, using reStructuredText_ and taking advantage
105+written in plain English, using reStructuredText_ and taking advantage
106 of `Sphinx's extensions`_, especially `cross-references`_.
107
108 Python API Documentation
109@@ -65,7 +65,7 @@
110 and ``__new__``), using the `info fields`_ as well.
111
112 * Attributes (class and instance) should be documented in their
113- class's docstrin via the ``.. attribute::`` directiveg, following
114+ class's docstring via the ``.. attribute::`` directiveg, following
115 the class's own documentation.
116
117 * The relation between modules and module-level attributes is similar:
118@@ -220,7 +220,7 @@
119 Release notes
120 +++++++++++++
121
122-.. [#] because Python is the default domain, the ``py:`` markup prefix
123+.. [#] Because Python is the default domain, the ``py:`` markup prefix
124 is optional and should be left out.
125
126 .. [#] Resig's Class still uses prototypes under the hood, it doesn't
127
128=== modified file 'openerpweb/openerpweb.py'
129--- openerpweb/openerpweb.py 2011-04-13 12:50:42 +0000
130+++ openerpweb/openerpweb.py 2011-04-15 09:42:38 +0000
131@@ -289,13 +289,34 @@
132 * the json string is passed as a form parameter named "request"
133 * method is currently ignored
134
135- Sucessful request:
136- --> {"jsonrpc": "2.0", "method": "call", "params": {"session_id": "SID", "context": {}, "arg1": "val1" }, "id": null}
137- <-- {"jsonrpc": "2.0", "result": { "res1": "val1" }, "id": null}
138-
139- Request producing a error:
140- --> {"jsonrpc": "2.0", "method": "call", "params": {"session_id": "SID", "context": {}, "arg1": "val1" }, "id": null}
141- <-- {"jsonrpc": "2.0", "error": {"code": 1, "message": "End user error message.", "data": {"code": "codestring", "debug": "traceback" } }, "id": null}
142+ Sucessful request::
143+
144+ --> {"jsonrpc": "2.0",
145+ "method": "call",
146+ "params": {"session_id": "SID",
147+ "context": {},
148+ "arg1": "val1" },
149+ "id": null}
150+
151+ <-- {"jsonrpc": "2.0",
152+ "result": { "res1": "val1" },
153+ "id": null}
154+
155+ Request producing a error::
156+
157+ --> {"jsonrpc": "2.0",
158+ "method": "call",
159+ "params": {"session_id": "SID",
160+ "context": {},
161+ "arg1": "val1" },
162+ "id": null}
163+
164+ <-- {"jsonrpc": "2.0",
165+ "error": {"code": 1,
166+ "message": "End user error message.",
167+ "data": {"code": "codestring",
168+ "debug": "traceback" } },
169+ "id": null}
170
171 """
172

Subscribers

People subscribed via source and target branches