Differences

This shows you the differences between two versions of the page.

--- dr:classified [2010/09/17 20:24] – created fgm
+++ dr:classified [2016/10/22 17:54] – Battle plan for Multiple node types fgm
@@ Line 5: / Line 5: @@
 Download or clone from http://bit.ly/cIBtcN
+===== Battle plan for multiple node types =====
+<html>
+<div class="classified-help">
+  <h4>Node types</h4>
+  <p>As per #195494, the goal is to support multiple node types.</p>
+  <ul>
+    <li>The included node type must remain for ease of use</li>
+    <li>Other existing node types must be supported</li>
+    <li>Since extra fields are per-node-type, this implies replacing the extra
+      fields by a proper field</li>
+    <li>Ad lists can therefore no longer be built by node type.</li>
+    <li>Take advantage of the change to replace custom lists by default Views</li>
+    <li>Enabled node types can either be defined by module settings, or (better ?)
+      automatically be identified by the presence of an instance of the
+      expiration field</li>
+    </ul>
+  <h4>Extra fields to Field</h4>
+  <p>The module defines two form extra fields, <code>expires_fs</code> on forms
+    and <code>expires</code> for display</p>
+  <ul>
+    <li>Kill both extra fields</li>
+    <li>Add a new Field replacing both, this means:
+      <ul>
+        <li>Done. Field is now available on Field UI only for node entities. <del>Adding field info/CRUD hooks</del></li>
+        <li>Hooks implemented. Actual logic to be done. <em>Adding a new widget to replace the form logic for <code>expires_fs</code></em></li>
+        <li>Hooks implemented. Actual logic to be done. <em>Adding a new formatter to replace the node view logic for <code>expires</code></em></li>
+        </ul>
+      </li>
+    </ul>
+    <h4>Custom lists to Views</h4>
+    <p>The module has inner knowledge of the specifics of the expiration extra
+      fields.</p>
+    <p>Lists are built either using custom built lists including it, or using
+      the new custom view mode introduced in 7.3. With multiple node types, this
+      is no longer doable so we replace these lists by taxonomy-filtered views.</p>
+    <p>With the extra field gone, its Views field handler no longer works.</p>
+    <ul>
+      <li>Replace the expiration field handler</li>
+      <li>Replace the home page list with a view. Keep the various counters.</li>
+      <li>Replace the per-term list with a view. Keep the various counters,
+        sub-category links, and breadcrumbs generation. This is likely to
+        involve attached views and/or new specific handlers.</li>
+      <li>Replace the per-user profile list with a view. Handle the empty case.</li>
+      <li>Replace the per-user rendered and raw token with two displays of a view.</li>
+      <li>Replace the per-user link token, possibly still by manual code.</li>
+      </ul>
+  <h4>Configuration</h4>
+  <ul>
+    <li>Simplify configuration: reduce the number of variables by grouping lifetimes in a single variable</li>
+    <li>Remove maxlength logic: use maxlength module instead of maintaining it here.</li>
+    </ul>
+  <h4>Custom logic</h4>
+  <p>Most of the module complexity lies in the expiration handling: automatic
+    expires generation and update. This needs to be adapted for the additional
+    complexity of a field over an extra field. Existing node form hooks and
+    handlers must be replaced by field hooks since we no longer know which forms
+    to intercept.</p>
+  <h4>i18n</h4>
+  <p>A number of users have expressed frustration at the lack of i18n support
+    in the module. Switching the extra fields to a field and the custom lists
+    to Views will help with this. New code should be i18n-compatible, so that
+    later changes can bring full i18n compliance</p>
+  <h4>Testing</h4>
+  <p>The code currently has 100% S0 test coverage. This should not go down, but
+    increase towards 100% C0.</p>
+  <ul>
+    <li>Rewrite tests to match the new code structures</li>
+    <li>Add tests for each new function/method introduced</li>
+    </ul>
+  <h4>Drupal 8</h4>
+  <p>Any significant work should take into account the directions taken by D8.
+    The move from an extra field to a normal field is in the right direction. Other significant
+    changes regard code placement outside the module file and the use of
+    autoloaded namespaced classes, one per file.</p>
+  <ul>
+    <li>Strip all non-hook code from the module file and move it to class
+      methods</li>
+    <li>Extract all logic from hook implementations to class (static) methods, leaving only the "glue" bits in the hook implementation, to ease unit testing.</li>
+    <li>Action code externalized in so doing should be considered for being made
+      usable at the admin level by exposing it as a core action, typically for
+      the user or node entities</li>
+    <li>Done: converted to <code>classloader</code>. <del>Consider using <code>xautoload</code> or <code>classloader</code>
+      to apply PSR-0, or declare classes the D7 way, manually in the info file.</del></li>
+    </ul>
+  </div>
+  </html>
 ===== OK Paths =====