[FIX] *: RST cleanup

RST cleanup to comply with the RST guidelines. This is required so we
can use "make test", as there are currently hundreds of errors. For now,
it is unusable because of the oldest code in this repo.

closes odoo/documentation#3568

Signed-off-by: Castillo Jonathan (jcs) <jcs@odoo.com>

content/developer/reference/frontend/javascript_reference.rst

@@ -1,11 +1,10 @@
-
 .. highlight:: javascript
 
 .. default-domain:: js
 
-=====================
+====================
 Javascript Reference
-=====================
+====================
 
 This document presents the Odoo Javascript framework. This
 framework is not a large application in term of lines of code, but it is quite
@@ -15,7 +14,7 @@ records in the database.  It is even possible to use the web client to modify
 the interface of the web client.
 
 Overview
-=========
+========
 
 The Javascript framework is designed to work with three main use cases:
 
@@ -53,7 +52,7 @@ action manager) actually creates and destroys many sub components. The state is
 highly dynamic, and each widget could be destroyed at any time.
 
 Overview of web client JS code
--------------------------------------
+------------------------------
 
 Here, we give a very quick overview on the web client code, in
 the *web/static/src/js* addon. Note that it is deliberately not exhaustive.
@@ -105,7 +104,7 @@ are a few things you can try to solve the issue:
 
 
 Loading Javascript Code
-========================
+=======================
 
 Large applications are usually broken up into smaller files, that need to be
 connected together.  Some file may need to use some part of code defined in
@@ -146,8 +145,6 @@ not the primary way to write javascript code.
 .. note::
     Native javascript modules are the primary way to define javascript code.
 
-
-
 Class System
 ============
 
@@ -204,7 +201,6 @@ framework will secretly rebind a special method: *_super* to the currently
 called method.  This allows us to use *this._super* whenever we need to call a
 parent method.
 
-
 .. code-block:: javascript
 
     var Animal = require('web.Animal');
@@ -248,7 +244,6 @@ of them in the new class.
 In this example, the *Hamster* class is a subclass of Animal, but it also mix
 the DanceMixin in.
 
-
 Patching an existing class
 --------------------------
 
@@ -273,7 +268,6 @@ the way Odoo is structured, it is sometimes necessary in one addon to modify
 the behavior of a widget/class defined in another addon.  Note that it will
 modify all instances of the class, even if they have already been created.
 
-
 Widgets
 =======
 
@@ -524,7 +518,6 @@ Widget API
     :param Element element: a DOM element or jQuery object to set as
                             the widget's DOM root
 
-
 Inserting a widget in the DOM
 -----------------------------
 
@@ -558,7 +551,7 @@ and are charged with three tasks:
 * starting the widget, and returning the result of starting it
 
 Widget Guidelines
-----------------------
+-----------------
 
 * Identifiers (``id`` attribute) should be avoided. In generic applications
   and modules, ``id`` limits the re-usability of components and tends to make
@@ -668,7 +661,6 @@ in order to make the web client slightly lighter.  In that case, we can use the
 With this, the *Counter* widget will load the xmlDependencies files in its
 *willStart* method, so the template will be ready when the rendering is performed.
 
-
 Event system
 ============
 
@@ -760,9 +752,8 @@ The previous example can be updated to use the custom event system:
 
     ... this.trigger_up('valuechange', {value: someValue});
 
-
 Registries
-===========
+==========
 
 A common need in the Odoo ecosystem is to extend/change the behaviour of the
 base system from the outside (by installing an application, i.e. a different
@@ -799,7 +790,6 @@ action registry
   action.  In version 11, each value should simply be a subclass of *Widget*.
   However, in version 12, the values are required to be *AbstractAction*.
 
-
 Communication between widgets
 =============================
 
@@ -867,7 +857,6 @@ Cross component
           },
       });
 
-
     In this example, we use the bus exported by *web.core*, but this is not
     required. A bus could be created for a specific purpose.
 
@@ -884,7 +873,7 @@ events, these events bubble up to a service provider, which will ask a service
 to perform a task, then maybe return an answer.
 
 Service
---------
+-------
 
 A service is an instance of the *AbstractService* class.  It basically only has
 a name and a few methods.  Its job is to perform some work, typically something
@@ -916,7 +905,6 @@ dispatch the custom events.  In the *backend* (web client), this is done by the
 main web client instance. Note that the code for the service provider comes from
 the *ServiceProviderMixin*.
 
-
 Widget
 ------
 
@@ -975,7 +963,7 @@ may need to directly call a controller (available on some route).
     });
 
 Notifications
-==============
+=============
 
 The Odoo framework has a standard way to communicate various information to the
 user: notifications, which are displayed on the top right of the user interface.
@@ -1010,9 +998,9 @@ The notification system in Odoo is designed with the following components:
 
 - an helper function in *ServiceMixin*: *displayNotification*
 
-
 Displaying a notification
 -------------------------
+
 The most common way to display a notification is by using the method that come
 from the *ServiceMixin*:
 
@@ -1102,7 +1090,6 @@ the class variable SystrayMenu.items.
 
     SystrayMenu.Items.push(MySystrayWidget);
 
-
 Ordering
 --------
 
@@ -1116,7 +1103,6 @@ left).
 
     MySystrayWidget.prototype.sequence = 100;
 
-
 Translation management
 ======================
 
@@ -1211,7 +1197,7 @@ client for everyone), and for data which is required early in the initialization
 process.
 
 Views
-======
+=====
 
 The word 'view' has more than one meaning. This section is about the design of
 the javascript code of the views, not the structure of the *arch* or anything
@@ -1220,7 +1206,6 @@ else.
 In 2017, Odoo replaced the previous view code with a new architecture.  The
 main need was to separate the rendering logic from the model logic.
 
-
 Views (in a generic sense) are now described with  4 pieces: a View, a
 Controller, a Renderer and a Model.  The API of these 4 pieces is described in
 the AbstractView, AbstractController, AbstractRenderer and AbstractModel classes.
@@ -2094,6 +2079,7 @@ reference (FieldReference)
 
 Widgets
 -------
+
 week_days (WeekDays)
   This field displays a list of checkboxes for week days, 1 checkbox for each day
   and allow the user to select a subset of the choices.
@@ -2166,7 +2152,6 @@ Registering the client action:
           <field name="tag">my-custom-action</field>
       </record>
 
-
 Using the control panel
 -----------------------