¿Cuándo no utilizar un nodo Drupal?

Question

Recientemente he creado una tabla CRUD muy simple donde el usuario almacena algunos datos. Para los datos, creé un nodo personalizado. La funcionalidad funciona muy bien para crear, editar y borrar datos en la tabla CRUD utilizando la funcionalidad básica del nodo (de hecho, me sorprende lo rápido y fácil que fue programar la funcionalidad básica con los controles de acceso adecuados con solo un poquito de código) ....

Dado que los datos no están destinados a ser tratados de la misma manera que 'contenido', como una publicación de blog (¿no debería aparecer el título, el cuerpo, los comentarios ni las revisiones? q = página de nodos, sin vistas previas, sin avances, etc.) ... Me parece que paso la mayor parte del tiempo 'desconectando' y modificando las cosas que drupal hace automáticamente para los nodos.

Sé que es una cuestión de gusto, pero ¿dónde debería trazarse la línea de lo que debería tratarse como un nodo y qué no? En otras palabras, ¿sería mejor programar esto desde cero sin usar nodos?

Answer 1

Usando los nodos para los datos personalizados tiene bastantes beneficios adicionales, además de fácil de editar/actualizar/funcionalidad de eliminación:

• posible categorización a través de la taxonomía
• implícita 'propiedad' a través de autor seguimiento
• seguimiento implícita de la creación/tiempo de modificación
• control de acceso básico de forma predeterminada, ampliable mediante una gran selección de módulos
• generación de consulta flexible/listado/filtrado a través de vistas
• posibles ad hoc extensiones/anotaciones a través de los campos CCK
• posible definición de flujos de trabajo, acciones y similares
• un gran número de ganchos para interceptar programación/ajuste casi todos el uso aspecto/escenario
• comentando, votación , calificación y un montón de otra funcionalidad proporcionada por los módulos de terceros que trabajan en/con nodos ...

Teniendo en cuenta todo esto, yo diría que necesita una muy buena razón para no nodos utilizan para almacenar datos en Drupal. Los nodos son simplemente los bloques de construcción fundamentales para casi todo en el ecosistema de Drupal, y la sobrecarga de eliminar algunas 'características' predeterminadas no deseadas parece bastante pequeña en comparación con las ganancias.

Dicho esto, una posible razón/argumento para manejar datos separados del sistema de nodos podría ser si esos datos están directamente dirigidos a anotar otros nodos (piense en taxonomía). Pero dado que puede hacer referencia fácilmente a los nodos de otros nodos (con muchas opciones diferentes sobre cómo hacerlo), el argumento no es fuerte.

Otro argumento (mucho más fuerte) sería integridad de los datos-Drupal no es muy fuerte (por decirlo suavemente) en relación con, el almacenamiento de datos relacional normalizado, integridad referencial, el tratamiento de transacciones y otros temas relacionados. Si tiene requisitos en esa dirección, es posible que no tenga más remedio que omitir el concepto de nodo y crear y mantener una isla de datos separada dentro del sistema por su cuenta.

Answer 2

Ayuda a pensar también que un nodo no necesita ser público tampoco. Algunos nodos son privados/internos y se pueden controlar aún más con controles de acceso. La forma en que lo está haciendo, sea lo que sea que esté haciendo, hace que toda la escalabilidad y la ampliación sobre sus hombros.

Probablemente lo abordaría con CCK/Taxonomía según lo que estaba haciendo. De esta forma, obtengo el beneficio adicional de la integración del módulo Vistas/Paneles/etc. sin escribir ningún código adicional.