editorial

archive/v0.1.14/practices.html

@@ -50,11 +50,11 @@
 <p>Data manipulation should be done in model classes, such that controllers never have entities lying around in temporarily invalid states.</p>
 <p>Mithril&#39;s design strongly encourages all entity logic to be handled in atomic model layer methods (in the sense of entity state stability).</p>
 <p>In fact, unavoidable abstraction leaks (such as network-bound asynchrony) are laid out in such a way as to make idiomatic code organization elegant, and conversely, to make it so that the abstraction leak problems themselves discourage attempts to misplace entity logic in the controller.</p>
-<p>This design decision comes from experience with DRY and <a href="http://en.wikipedia.org/wiki/Bus_factor">&quot;bus factor&quot;</a> of large, highly relational model layers.</p>
-<p>This is in stark contrast to the ActiveRecord pattern of other frameworks, where model entities are largely object representations of database entities and these entities are manipulated in controllers in an ad-hoc field-by-field fashion, and the &quot;committed&quot; via a <code>save</code> method.</p>
-<p>Because Mithril encourages all entity logic to be done in the model layer, it&#39;s idiomatic to create modules with model-level classes that deal specifically with relationship between entities, when there isn&#39;t already a model entity that can logically hold the relational business logic.</p>
+<p>This design decision comes from experience with <a href="https://en.wikipedia.org/wiki/Don%27t_repeat_yourself">DRY</a> and the <a href="http://en.wikipedia.org/wiki/Bus_factor">&quot;bus factor&quot;</a> of large, highly relational model layers.</p>
+<p>This is in stark contrast to the ActiveRecord pattern of other frameworks, where model entities are largely object representations of database entities and these entities are manipulated in controllers in an ad-hoc field-by-field fashion, and then &quot;committed&quot; via a <code>save</code> method.</p>
+<p>Because Mithril encourages all entity logic to be done in the model layer, it&#39;s idiomatic to create modules with model-level classes that deal specifically with relationships between entities, when there isn&#39;t already a model entity that can logically hold the relational business logic.</p>
 <p>Models are also responsible for centralizing tasks such as filtering of entity lists and validation routines, so that access to these methods is available across the application.</p>
-<p>DOM manipulation should be done in the view via <a href="mithril"><code>m()</code> and <code>config</code></a>. Controllers may explicitly call <a href="mithril.redraw"><code>m.redraw</code></a>, but, if possible, it&#39;s preferable to abstract this into a service which integrates w/ Mithril&#39;s auto-redrawing system (see. <a href="mithril.computation"><code>m.startComputation</code> / <code>m.endComputation</code></a>)</p>
+<p>DOM manipulation should be done in the view via <a href="mithril"><code>m()</code> and <code>config</code></a>. Controllers may explicitly call <a href="mithril.redraw"><code>m.redraw</code></a>, but, if possible, it&#39;s preferable to abstract this into a service which integrates with Mithril&#39;s auto-redrawing system (see <a href="mithril.computation"><code>m.startComputation</code> / <code>m.endComputation</code></a>).</p>
 <hr>
 <h2 id="file-separation">File Separation</h2>
 <p>The examples in this site usually conflate different MVC layers together for the sake of readability, but normally it&#39;s recommended that each layer on a module be in different files. For example:</p>
@@ -77,7 +77,7 @@ app.view = function(ctrl) {
 <p>You can use task automation tools such as GruntJS to concatenate the files back together for production.</p>
 <p>Typically, when separating MVC layers, it&#39;s common that the namespace declaration be in the model layer, since this is usually the most used dependency for the other layers.</p>
 <p>You may choose to declare the namespace in a separate file or have the build system generate it on demand, instead.</p>
-<p>You should avoid grouping classes by the MVC layer they belong to, i.e. don&#39;t create 3 files called model.js, controllers.js and views.js.</p>
+<p>You should avoid grouping classes by the MVC layer they belong to, i.e. don&#39;t create three files called model.js, controllers.js and views.js.</p>
 <p>That organization pattern needlessly ties unrelated aspects of the application together and dilutes the clarity of modules.</p>
 <hr>
 <h2 id="global-namespace-hygiene">Global Namespace Hygiene</h2>
@@ -96,7 +96,7 @@ app.view = function(ctrl) {
 <hr>
 <h2 id="usage-of-m-redraw">Usage of m.redraw</h2>
 <p><code>m.redraw</code> is a method that allows you to render a template outside the scope of Mithril&#39;s auto-redrawing system.</p>
-<p>Calling of this method while using <code>m.module</code> or <code>m.route</code> should only be done if you have recurring asynchronous view updates (i.e. something that uses setInterval).</p>
+<p>Calling this method while using <code>m.module</code> or <code>m.route</code> should only be done if you have recurring asynchronous view updates (i.e. something that uses setInterval).</p>
 <p>If you&#39;re integrating other non-recurring services (e.g. calling setTimeout), you should use <a href="mithril.computation.html"><code>m.startComputation</code> / <code>m.emdComputation</code></a> instead.</p>
 <p>This is the most potentially expensive method in Mithril and should not be used at a rate faster than the rate at which the native <code>requestAnimationFrame</code> method fires (i.e. the rate at which browsers are comfortable calling recurring rendering-intensive code). Typically, this rate is around 60 calls per second.</p>
 <p>If you call this method more often than that, Mithril may ignore calls or defer them to the next browser repaint cycle.</p>