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.
Risposte:
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_termtipo 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. Sebbene in teoria si possa usare un tipo di contenuto per eseguire questa funzionalità (con forse un campo di riferimento nodo), un termine di tassonomia non deve necessariamente fare la stessa cosa di un nodo, quindi non ha molto senso farlo. Lo stesso si può dire per gli usered taxonomy_vocabularyentità tipi.
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 ciò di cui hai bisogno, o è solo una grande quantità 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 sentire ciò che qualcuno direttamente coinvolto nello sviluppo del core Drupal ha da dire al riguardo.
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 dare ai tuoi editor i diritti di modifica / visualizza questi nodi e spera che nessuna vista / ricerca li visualizzi sul mondo esterno. È piuttosto ingombrante e sarebbe più facile trattare con le entità.
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 Contentperché usernessuna delle precedenti ha senso, mentre d'altra parte è usernecessario disporre di una 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 un'introduzione alle entità , ma purtroppo in realtà non risponde alla tua domanda.
Penso che tutto riguardi il 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à:
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.
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 autonomi in una singola tabella, hai meno preoccupazioni e possibilità di corruzione dei dati.
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 vorrai 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 Commerce dove i prodotti sono tipi di entità. Fondamentalmente le entità consentono agli sviluppatori di estendere Drupal in modo mai previsto dai progettisti originali di Drupal.
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 quindi in un post sul blog scegliere tra uno di essi"
Entità vs contenuto
Entità ha fasci di entità che hanno campi
Il contenuto è un tipo di entità. Così,
Il contenuto ha pacchetti di contenuti (articolo, pagina) che hanno campi (corpo, immagine dell'articolo)
Se sei programmatore, scegli sicuramente il percorso per creare la tua Entità, ma per i costruttori di siti potrebbe non essere il percorso migliore da percorrere. Ancora una volta per i costruttori di siti c'è un'interfaccia utente per la creazione di Entity http://drupal.org/project/eck