docs(tutorials): add cell namespace tutorial (#2287)

docs/src/joint/api/dia/Graph/constructor.html

@@ -1,15 +1,24 @@
 <p>
-                    <b>joint.dia.Graph</b> is the model holding all the cells (elements and links) of the diagram. It's a <a href="https://backbonejs.org/#Model">Backbone model</a>.
-                    The collection of all the cells is stored in the property <b><code>cells</code></b>.
-                </p><p>
-                  The graph is a powerful data model behind all JointJS diagrams. It not only provides an efficient storage
-                  for directed graphs but also offers useful algorithms for traversing the graphs.
-                </p><p>
-                  Additionally, the graph accepts an option object in its constructor function that can contain the <code>cellNamespace</code> option.
-                    This option can be used to change the default behavior of JointJS which by default reads cell model definitions from the <code>joint.shapes</code> namespace.
-                    For example, if a cell is of type <code>'myshapes.MyElement'</code>, then the graph looks up <code>joint.shapes.myshapes.MyElement</code>
-                    model when deserializing a graph from the JSON format. If the graph is instantiated as e.g. <code>var graph = new joint.dia.Graph({}, { cellNamespace: myShapesNamespace })</code>, then
-                    the graph will read the model definition from the <code>myShapesNamespace.myshapes.MyElement</code> object instead. This is useful in situations where you don't want to - for any reason -
-                  use the <code>joint.shapes</code> namespace for defining your own custom shapes. This option is often used in combination with the
-                  <code>cellNamespaceView</code> option on the <a href="#dia.Paper.prototype.options.cellViewNamespace">joint.dia.Paper</a> object.
-                </p>
+  <code>joint.dia.Graph</code> is the model holding all cells (elements and links) of the diagram. It's a 
+  <a href="https://backbonejs.org/#Model">Backbone model</a>. The collection of all the cells is stored in the property <b><code>cells</code></b>.
+</p>
+
+<p>
+  The graph is a powerful data model behind all JointJS diagrams. It not only provides efficient storage for directed graphs, but also offers useful 
+  algorithms for traversing the graphs.
+</p>
+
+<p>
+  In order for JointJS to find the correct constructor for your cell, the <code>graph</code> option <code>cellNamespace</code> must be provided in 
+  its constructor function when a graph is instantiated. Built-in shapes are usually located in the <code>joint.shapes</code> namespace, so this is 
+  a common namespace to use. It's possible to add custom shapes to this namespace, or alternatively, you may like to use a different namespace 
+  completely.
+</p>
+
+<p>
+  For example, if <code>joint.shapes</code> is provided as the value of <code>cellNamespace</code>, and a cell is of type <code>'custom.Element'</code>,
+  then the graph looks up the <code>joint.shapes.custom.Element</code> model when deserializing a graph from JSON format. If the graph is instantiated
+  as e.g. <code>const graph = new joint.dia.Graph({}, { cellNamespace: myCustomNamespace })</code>, then the <code>graph</code> will read the model
+  definition from the <code>myCustomNamespace.custom.Element</code> object instead. This option is often used in combination with the
+  <code>cellViewNamespace</code> option on the <a href="#dia.Paper.prototype.options.cellViewNamespace">joint.dia.Paper</a> object.
+</p>

docs/src/joint/api/dia/Paper/prototype/options/cellViewNamespace.html

@@ -1,7 +1,14 @@
-<code>cellViewNamespace</code> - this option can be used to change the default behavior of JointJS which by default reads cell view definitions from the <code>joint.shapes</code> namespace.
-                              For example, if a cell is of type <code>'myshapes.MyElement'</code>, then the paper looks up <code>joint.shapes.myshapes.MyElementView</code>
-                              object type when rendering the cell onto the screen. If <code>cellViewNamespace</code> is set,
-                              the paper will read the view definition from the <code>myShapesNamespace.myshapes.MyElementView</code> object instead. This is useful in situations where you - for any reason - don't want to 
-                              use the <code>joint.shapes</code> namespace for defining your own custom shapes. This option is often used in combination with
-                              <code>cellNamespace</code> option on the <a href="#dia.Graph.constructor"><code>joint.dia.Graph</code></a> object.
-
+<p>
+    <code>cellViewNamespace</code> - In order for the JointJS <code>paper</code> to read cell view definitions from the correct location, 
+    the <code>paper</code> option <code>cellViewNamespace</code> must be provided. Built-in cell view definitions are usually located in the 
+    <code>joint.shapes</code> namespace, so this is a common namespace to use. It's possible to a add custom cell view to this namespace, or 
+    alternatively, you may like to use a different namespace completely.
+</p>
+
+<p>
+    For example, if <code>joint.shapes</code> is provided as the value of <code>cellViewNamespace</code>, and a cell is of type 
+    <code>'custom.Element'</code>, then the <code>paper</code> looks up the <code>joint.shapes.custom.ElementView</code> object type when rendering the 
+    cell onto the screen. If <code>cellViewNamespace</code> is set with a value of <code>myCustomNamespace</code>, the paper will read view 
+    definitions from the <code>myCustomNamespace.custom.ElementView</code> object instead. This option is often used in combination with the
+    <code>cellNamespace</code> option on the <a href="#dia.Graph.constructor"><code>joint.dia.Graph</code></a> object.
+</p>