Differences

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

--- dr:classified [2010/09/17 20:24] – created fgm
+++ dr:classified [2020/11/23 17:23] (current) – external edit 127.0.0.1
@@ Line 4: / Line 4: @@
 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>
+===== Services provided by the module =====
+- 1 specific vocabulary: `classified_categories`, supplied with 2 sample terms (Wanted and For Sale)
+- 1 specific node type: `classified` equipped with
+  - a taxonomy_term_reference field pointing to the module vocabulary
+  - a body field
+- 3 blocks:
+  - recent ads (public)
+  - popular ads (public)
+  - ad stars (admin)
+- 1 Context Condition plugin
+- 1 CTools "content type" plugin to expose the `expires` pseudo field
+- 2 permissions
+  - `administer classified ads`
+  - `reset classified ads expiration`
+- 2 extra fields
+  - `expires_fs`: a form extra field allowing selection of an expiration type and optionally a manual expiration date for ad nodes
+  - `expires`: a display extra field formatting the expiration date for ad nodes
+- 1 notifications submodule: send notifications
+  - at half-life
+  - before|on expiration
+  - before|on purge
+- 3 drush commands
+  - `classified-purge` to purge expired nodes
+  - `classified-expire` to expire nodes
+  - `classified-notify` to send notifications
+- 1 custom view mode for `node`
+- 2 menu loaders
+  - notify kind
+  - taxonomy term, only accepting terms from the module vocabulary
+- 3 user tokens
+  - `[classified-ads]` themed list of user ads
+  - `[classified-ads-plain]` raw list of user ads
+  - `[classified-ads-url]` url of a user's ads list
+- 2 theme items
+  - `classified_admin_lifetimes`
+  - `classified_expires` for the `expires` extra field
+- 1 field formatter for term_reference fields, linking to the per-term ad list instead of the default term page, with an optional link title
+- node form logic
+  - handle the extra field
+  - provide fieldset-level access control for expiration type
+  - maxlength JS
+  - auto-hiding manual expiration date when irrelevant
+- node access logic
+- requirements logic
+  - detect incompatible older version
+  - detect missing Statistics module
+  - detect misconfigured Statistics module
+  - detect non-tree hierarchy in the module vocabulary
+- taxonomy change logic for terms and vocabularies
+- URL outbound rewriting logic to redirect term links to ad lists when applicable
+- Views integration logic
+  - expose virtual fields:
+    - `expires`: field, sort, filter
+    - `purge`: field
+  - 1 field handler for `purge`
+  - default views logic scanning the `views/` folder, but no views provided
+- configuration variables
+  - `classified-max-length` for the maxlength JS
+  - `classified-list-body` List display format
+  - `classified-edit-modr8` (obsolete) modr8 integration
+  - `classified-lifetime-default` default lifetime
+  - `classified-lifetime-<tid>` per-tid lifetime overrides
+  - `classified-grace` grace delay before purge
+- 100% S0 Simpletest coverage
+- pages
+  - an overview page
+  - term pages listing ads and ad counts
+  - per-user ads profile tab page
+- 7 advanced help pages
+- custom CSS
+  - specific formatting for `expires`
+  - advanced help improvements
+  - ads list custom formats
 ===== OK Paths =====