Quando non utilizzare un nodo Drupal?

Question

Ho recentemente creato una tabella CRUD molto semplice in cui l'utente memorizza alcuni dati. Per i dati, ho creato un nodo personalizzato. La funzionalità funziona alla grande per la creazione, la modifica e l'eliminazione dei dati nella tabella CRUD utilizzando la funzionalità di base del nodo (sono davvero sorpreso di quanto sia stato facile e veloce programmare le funzionalità di base con controlli di accesso corretti usando solo un piccolo bit di codice) ....

Poiché i dati non devono essere trattati allo stesso modo di "contenuto" come un post di blog (nessun titolo, nessun corpo, nessun annuncio, nessuna revisione, non dovrebbe apparire su? q = pagina del nodo, nessuna anteprima, nessun teaser, ecc) ... Trovo che trascorro la maggior parte del mio tempo 'spegnendo' e modificando le cose che drupal fa automaticamente per i nodi.

So che è una questione di gusti, ma dove si dovrebbe tracciare la linea su cosa dovrebbe essere trattato come un nodo e cosa non dovrebbe? In altre parole, sarebbe meglio programmare questa roba da zero senza utilizzare i nodi?

Answer 1

Utilizzando i nodi per i dati personalizzati ha abbastanza alcuni vantaggi aggiuntivi oltre facile modificare/aggiornare/cancellare la funzionalità:

• possibile categorizzazione tramite tassonomia
• implicita 'proprietà' via autore di monitoraggio
• implicita monitoraggio della creazione/tempo di modifica
• controllo di accesso di base predefinito, espandibile da una vasta selezione di moduli
• generazione di query flessibile/elenco/filtro tramite Visto
• possibili ad hoc estensioni/annotazioni tramite i campi CCK
• possibile definizione dei flussi di lavoro, azioni e simili
• un numero enorme di ganci per intercettare programmazione/regolare quasi ogni utilizzo aspetto/scenario
• commentando, il voto , rating e tonnellate di altre funzionalità fornite da tutti i moduli contribuito che lavorano su/con i nodi ...

Dato tutto questo, direi che hai bisogno di una buona ragione per non utilizzare i nodi per memorizzare i dati in Drupal. I nodi sono semplicemente gli elementi costitutivi fondamentali per quasi tutto nell'ecosistema Drupal e il sovraccarico di rimozione di alcune "caratteristiche" di default indesiderate sembra piuttosto piccolo rispetto ai guadagni.

Detto questo, un possibile motivo/argomento per gestire i dati separati dal sistema di nodi potrebbe essere se tali dati sono direttamente finalizzati all'annotazione di altri nodi (tassonomia di pensiero). Ma dato che puoi facilmente fare riferimento ai nodi da altri nodi (con molte opzioni diverse su come farlo), l'argomento non è forte.

Un altro (molto più forte) argomento sarebbe l'integrità dei dati-Drupal non è molto forte (per usare un eufemismo) riguardante normalizzato, relazionale archiviazione dei dati, l'integrità referenziale, la gestione delle transazioni e altri argomenti correlati. Se si hanno requisiti in quella direzione, non si può avere altra scelta che saltare il concetto del nodo e creare e mantenere un'isola dati separata all'interno del sistema da soli.

Answer 2

È utile pensare anche che un nodo non ha bisogno di essere pubblico. Alcuni nodi sono privati ​​/ interni e possono essere controllati ulteriormente con i controlli di accesso. Il modo in cui lo stai facendo, qualunque cosa tu stia facendo, rende tutta la scalabilità e la estende sulle tue spalle.

Probabilmente ci avvicinerei con CCK/Tassonomia a seconda di quello che stavo facendo. In questo modo, ottengo l'ulteriore vantaggio dell'integrazione dei moduli Views/Panels/etc senza scrivere alcun codice aggiuntivo.