Quand ne pas utiliser un noeud Drupal?

Question

J'ai récemment créé une table CRUD très simple où l'utilisateur stocke certaines données. Pour les données, j'ai créé un noeud personnalisé. La fonctionnalité fonctionne bien pour créer, éditer et supprimer des données dans la table CRUD en utilisant la fonctionnalité de base du nœud (je suis vraiment étonné de la rapidité et de la facilité de programmer les fonctionnalités de base avec des contrôles d'accès appropriés)

Étant donné que les données ne sont pas destinées à être traitées de la même manière que le «contenu», comme un article de blog (aucun titre, aucun corps, aucun commentaire, aucune révision, ne devrait pas apparaître? q = page de noeuds, pas de prévisualisation, pas de teasers, etc) ... Je trouve que je passe le plus clair de mon temps à 'éteindre' et à modifier les choses que drupal fait automatiquement pour les noeuds. Je sais que c'est une question de goût, mais où devrait-on tracer la ligne sur ce qui devrait être traité comme un nœud et ce qui ne devrait pas? En d'autres termes, serait-il préférable de programmer ces choses à partir de zéro sans utiliser de nœuds?

Answer 1

Utilisation de nœuds pour les données personnalisées a tout à fait quelques avantages supplémentaires en plus de modifier/mise à jour facile/fonctionnalité de suppression:

• catégorisation possible via la taxonomie
• implicite la « propriété » par l'auteur suivi
• suivi implicite de la création/temps de modification
• contrôle d'accès de base par défaut, extensible par une vaste sélection de modules
• génération de requête flexible/liste/filtrage via vues
• possibles ad hoc extensions/annotations via les champs CCK
• définition possible des flux de travail, des actions et autres
• un grand nombre de crochets pour intercepter programme/ajuster aspect presque chaque utilisation/scénario
• commentaires, vote , la notation et des tonnes d'autres fonctionnalités fournies par tous les modules ont contribué qui travaillent sur/avec des nœuds ...

Compte tenu de tout cela, je dirais que vous avez besoin d'une très bonne raison de pas nœuds d'utiliser pour stocker des données à Drupal. Les nœuds sont simplement les blocs de construction fondamentaux pour à peu près tout dans l'écosystème Drupal, et la suppression de certaines «caractéristiques» par défaut indésirables semble plutôt faible par rapport aux gains. Cela dit, une raison/un argument possible pour manipuler des données séparées du système de nœuds pourrait être que ces données visent directement à annoter d'autres nœuds (pensez à la taxonomie). Mais puisque vous pouvez facilement référencer des nœuds d'autres nœuds (avec beaucoup d'options différentes pour ce faire), l'argument n'est pas fort.

Un autre (beaucoup plus fort) argument serait l'intégrité des données-Drupal est pas très forte (pour le dire poliment) en ce qui concerne le stockage de données normalisées, relationnelle, l'intégrité référentielle, la gestion des transactions et d'autres sujets connexes. Si vous avez des besoins dans ce sens, vous n'aurez pas d'autre choix que d'ignorer le concept de nœud et de créer et gérer vous-même un îlot de données distinct dans le système.

Answer 2

Il est utile de penser également qu'un nœud n'a pas besoin d'être public non plus. Certains nœuds sont privés/internes et peuvent être contrôlés avec des contrôles d'accès. La façon dont vous le faites, quoi que vous fassiez, fait toute l'évolutivité et l'étend sur vos épaules.

Je l'aborderais probablement avec CCK/Taxonomy en fonction de ce que je faisais. De cette façon, j'ai l'avantage supplémentaire d'intégrer le module Views/Panels/etc sans écrire de code supplémentaire.