it-swarm.it

Quando è appropriato creare un'entità anziché aggiungere un nuovo tipo di contenuto?

Qual è il vantaggio della creazione di nuovi tipi di entità rispetto alla semplice creazione di un nuovo tipo di contenuto?

Sembra un po 'eccessivo eseguire tutta la codifica personalizzata necessaria per creare una nuova entità quando tutte le funzionalità CRUD e Views sono già integrate nei tipi di contenuto.

86
revolt

Non si tratta tanto di ciò che i benefici sono, ma piuttosto di ciò che è appropriato per una situazione particolare come hai detto. Puoi rappresentare praticamente qualsiasi cosa con un nodo e per il 99% delle situazioni (come ho scoperto almeno) non dovrai implementare tipi di entità personalizzati.

Penso sempre al taxonomy_term tipo di entità come un buon esempio del perché non tutto dovrebbe essere un nodo/tipo di contenuto:

Un termine di tassonomia è essenzialmente per raggruppare entità diverse e come tale non richiede la stessa funzionalità di un nodo. Mentre potresti teoricamente usi un tipo di contenuto per eseguire questa funzionalità (con forse un campo di riferimento al nodo), un termine di tassonomia non ha bisogno di fare la stessa cosa di un nodo, quindi non lo fa davvero senso di farlo. Lo stesso si può dire per user e taxonomy_vocabulary tipi di entità.

Quindi un termine di tassonomia viene creato come entità separata ed è programmato per fare solo ciò di cui ha bisogno, pur ottenendo i vantaggi di poter avere campi collegati, ecc.

Penso che la semplice risposta sia che quando un nodo/tipo di contenuto non fa quello che ti serve, o è solo una quantità enorme di overkill/overhead per un beneficio molto piccolo, allora dovresti scegliere di scrivere un'entità personalizzata.

Questo si basa solo sulla mia esperienza personale; Sarei interessato a sapere cosa qualcuno ha direttamente coinvolto in Drupal core development ha dovuto dire al riguardo.

66
Clive

Una regola empirica molto semplice che utilizzo è se i tuoi contenuti devono essere visualizzati pubblicamente da soli. In tal caso, scegli nodo, se non scegli un'entità. Entityforms ora ti consente di creare un'interfaccia per compilare le tue entità.

Ad esempio, su un sito Web realizzato con D6 costruiamo un tipo di contenuto pubblicitario (con il suo campo immagine, data di inizio/fine visualizzazione ...), ma poi devi renderlo non pubblicato per impostazione predefinita e dai ai tuoi editor i diritti di modificare/visualizzare questi nodi e speriamo che nessuna vista/ricerca li visualizzi sul mondo esterno. È piuttosto ingombrante e sarebbe più facile trattare con le entità.

16
tostinni

Un'entità rappresenta un caso d'uso specifico .

Credo che il merito di questa semplice definizione vada a Fago , ma sono troppo pigro per trovare un riferimento.

Potremmo usare Content (aka Nodes) per tutti i casi d'uso se lo volessimo, ma spesso non ha senso.

Content ha un autore e impostazioni sia per i commenti che per la posizione del menu.

Users, rappresentano un caso d'uso abbastanza diverso da Content perché su un user nessuna delle precedenti ha senso, mentre d'altra parte un user deve avere un'e-mail e una password.

Taxonomy terms si distinguono perché hanno la funzionalità integrata da disporre in una gerarchia, anche circolare.

Se il tuo caso d'uso è abbastanza simile a un'entità esistente, procedi con tale entità. Se la tua entità è governata da regole significativamente diverse da quelle esistenti, creane una nuova.

C'è anche An Introduction to Entities , ma sfortunatamente non risponde davvero alla tua domanda.

12
Letharion

Penso che sia tutto basato sul contesto, un nodo è ampiamente utilizzato per i contenuti, quindi sarebbe blog, articoli, domande frequenti, ecc. Mentre l'utente per profili come personale, clienti ecc. Esempio di quando potresti creare una nuova entità:

  • Forum
  • Progetto (in termini di gestione del progetto)
  • Modulo
  • Biglietto di supporto
  • Gruppo

Mentre potresti usare un nodo per qualcosa come un ticket di supporto, potrebbe non essere il modello migliore e le impostazioni predefinite ... Spero che sia d'aiuto.

5
WestieUK

Le entità possono essere create con un sovraccarico minore rispetto ai nodi poiché non devono disporre di tutte le funzionalità pesanti delle entità.

Significa anche che l'archiviazione può essere più semplice: puoi crearli per acquisire tutte le informazioni in una semplice query senza JOIN, se lo desideri. Tutti i campi in un solo tavolo ordinato.

Questo può essere un grande vantaggio se si dispone di molte funzioni che devono eseguire query sulle entità e si stanno aggiornando molte entità contemporaneamente con query UPDATE sul database. Se puoi assicurarti che i dati siano relativamente indipendenti in una singola tabella, hai meno preoccupazioni e possibilità di corruzione dei dati.

1
James

Un tipo di contenuto è progettato per essere contenuto del sito. Cioè, ogni tipo di contenuto è progettato per essere pubblicato e visualizzato sul sito. Ad esempio, un articolo (pronto all'uso) è progettato per essere visualizzato nella prima pagina.

Ora, supponiamo che tu voglia creare qualcosa come un modulo di domanda di lavoro o appartamento. Ovviamente, non vorresti pubblicare la domanda di lavoro di qualcuno sul tuo sito web. Inoltre, cosa succede se si desidera creare un elenco di contatti cliente/lead? Vorresti correre il rischio che queste informazioni possano essere pubblicate per errore sul tuo sito web? Personalmente, non lo farei.

Quindi, il modulo modulo entità che è discusso sopra. Ti consente di creare un tipo di entità che non è progettato per essere contenuto. Tuttavia, questi tipi di entità sono disponibili per qualsiasi modulo che supporti entità come regole, viste e gruppi organici per citarne solo alcuni.

E poi entri in Drupal Commercio in cui i prodotti sono tipi di entità. Fondamentalmente le entità consentono agli sviluppatori di estendere Drupal in modo mai previsto dall'originale Drupal designer.

0
Den Solis

Questo è soggetto a discussione e alla fine devi prendere le tue decisioni come sviluppatore.

Scelgo le entità rispetto ai nodi ogni volta che i dati non dovrebbero essere disponibili al pubblico con il proprio URL. I nodi ottengono per impostazione predefinita un alias URL, lo stato pubblicato, un titolo, i metatag, ... mentre le entità ottengono semplicemente un record nel database.

"Voglio essere in grado di aggiungere quanti più banner con il testo possibile e poi in un post sul blog scegliere tra uno di essi"

  • Il tipo di contenuto sarebbe "Blog"
  • L'entità personalizzata sarebbe "Articolo banner"
0