Mi chiedo come decidere di utilizzare il modulo tassonomia di base o il modulo di riferimento entità ?

Non ho mai usato il modulo Entity Reference prima, ma ho usato il modulo tassonomia (e alcuni moduli correlati) su 10-15 siti Web.

Quali sono i vantaggi o gli svantaggi dell'utilizzo dei moduli di riferimento al posto del modulo di tassonomia?

Di recente, ho iniziato a costruire un sito web di archivio di riviste.

Ci sono molte riviste. Queste riviste hanno problemi. Ogni numero ha articoli.

La parte più piccola (e più profonda) qui è gli articoli .

Articolo

• Numero di pagina (intervallo):
• Titolo:
• Autore:
• Tipo di articolo:
• parole chiave:
• Rivista:
• Problema:

Problema

• Edizione numero:
• Immagine di copertina:
• Data (pubblicata):
• Rivista:

Rivista

• Descrizione:
• Immagine di copertina:

Qui ci sono (almeno) 2 metodi per implementare questo sito Web:

1. Ci sarà un tipo di contenuto chiamato articlee tutti gli altri (numero, rivista, autore) saranno termini di tassonomia (gerarchici). Ci sarebbe una gerarchia tra numero e rivista ecc.

2. Ci saranno molti tipi di contenuto: articolo, numero, rivista, autore. Durante la creazione di articoli; numero, rivista e autore potrebbero essere citati ecc.

Quindi, teoricamente entrambi i modi sembrano molto simili.

C'è qualcuno che ha affrontato una situazione simile e potresti per favore dire quale metodo hai preferito, perché?

Esistono anche altre soluzioni al tuo problema.

Collezione Field

È possibile utilizzare i moduli di visualizzazione raccolta campi e raccolte campi per archiviare e organizzare i contenuti. Usando questo approccio il Issuee Magazinestanno per essere tipo Field Collection, Issueè un campo di Articleed Magazineè un campo di Issue. Ho esperienza nell'implementazione di tale struttura. Nel mio caso il requisito era Libraryche dovrebbe contenere libri (con campi Titolo, Editore e ...), Ogni libro contiene più volumi (Numero di pagine, traduttore, ...) e ogni volume contiene anche un numero illimitato di alcuni altri elementi (come la scansione di alcune pagine che non sono le stesse tra i libri).

Ho implementato questo usando l'approccio Field Collection ed è molto bello. Puoi facilmente creare un link per modificare ogni singolo elemento di ogni raccolta di campi e puoi anche filtrare per elementi della raccolta di campi. Ho pubblicato una risposta agli elementi del gruppo in Viste in base al valore in Raccolta campi che mostra come lavorare con le viste Raccolta campi

Allegato vista entità

Conosciuto anche come modulo EVA .

"Eva" è l'abbreviazione di "Entity Views Attachment;" fornisce un plug-in di visualizzazione Views che consente di collegare l'output di una View al contenuto di qualsiasi entità Drupal. Il corpo di un nodo o di un commento, il profilo di un account utente o la pagina di elenco per un termine di tassonomia sono tutti esempi del contenuto dell'entità.

È possibile utilizzare EVA per visualizzare solo i valori dei campi per un determinato contenuto, offrendo un controllo incredibile sulla flessibilità di visualizzazione e formattazione dei campi. Ad esempio potresti desiderare di concatenare due campi in qualche modo speciale. È possibile aggiungere i campi al display EVA, impostare il filtro contestuale su NID, aggiungere un campo di testo globale: e utilizzare i token per formattare i campi con HTML. Non dimenticare di escludere i campi dalla visualizzazione se li utilizzerai insieme in un campo di testo Globale. Esempio: potresti avere una città, uno stato e campi zip. Puoi combinarli in un campo Global: Text in Views per visualizzarlo come "Città, Stato ZIP". Quando gestisci il display per il tuo tipo di contenuto aggiungi l'EVA appena creato al display e ogni volta che viene visualizzato un nodo il tipo passa il suo nid all'EVA e l'EVA restituirà i campi selezionati, formattato come desideri. (fonte :Caso di utilizzo di EVA ed Entity Reference Use Case )

Questo modulo è perfetto, allega una vista come campo ai nodi di un tipo di contenuto. Ho usato questo modulo per creare un Album. L'album contiene singer(con alcune informazioni su ciascuno) e songsche contiene un file, titolo, tasso e .... Quindi ho creato una vista di tipo EVA e l'ho collegata a un nodo. Quindi nella pagina del nodo di ogni cantante, ho visualizzato questa vista che ottiene le informazioni appropriate dal nodo. Le visualizzazioni con Entità di Riferimento è un tutorial perfetto di come utilizzare questo modulo.

Termini tassonomici VS Riferimento entità

Ti consiglio di leggere il riferimento all'entità rispetto alla tassonomia e ci sono vantaggi / avvertenze nell'uso del riferimento all'entità rispetto al riferimento a termine? Come si dice, le tassonomie sono meglio utilizzate quando si organizzano oggetti simili in modo gerarchico. Come tag .

La tassonomia consente di utilizzare la codifica gratuita (può essere disabilitata utilizzando il modulo Tassonomia dei contenuti ), che consente la creazione di nuovi tag al volo. È molto facile modificare lo scheletro dei contenuti. Utilizzando questo approccio, utenti regolari o almeno alcuni utenti autenticati (che non hanno alcuna conoscenza della programmazione) possono cambiare questo scheletro. Il modulo di selezione gerarchica è un perfetto esempio di tale approccio.

Anche se la tassonomia è facile da usare, ma io stesso preferisco Entity Reference, apre molte possibilità e scalabilità e consente di creare strutture molto complesse. Il concetto di entità in questo contesto non si limita al contenuto. Può essere commenti, utenti, tassonomie e .... È molto più scalabile, quindi non dovrai preoccuparti della personalizzazione dei tipi di contenuto o della modifica in futuro (come è stato sottolineato in Riferimento entità vs. tassonomia ). Credo che l'approccio Entity sia più potente della tassonomia.

Esistono anche altre combinazioni di questi approcci che non è necessario menzionarle.

Comunque ti consiglio di comprendere appieno l'approccio Entity e i relativi moduli. Se lo usi in più progetti, nonostante la sua complessità, sarà molto facile per te usarlo. Non solo nel tuo attuale requisito, ma anche in futuro sarà uno strumento molto affidabile per te.

Potresti anche avere qualche altra combinazione, come articoli e numeri sono nodi e riviste sono tassonomie.

Non c'è davvero una risposta giusta o sbagliata per questo dipende dalle preferenze personali, dai requisiti specifici del progetto, ecc.

È meglio usare nodi per contenuti e tassonomie per la categorizzazione di quel contenuto, tuttavia a volte può diventare un po 'oscuro se qualcosa è solo categorizzazione o il suo contenuto.

Ad esempio, i campi relativi al tipo di articolo e alle parole chiave sembrerebbero più ovviamente tassonomie, ma i numeri e le riviste potrebbero davvero andare in entrambi i modi.

Una cosa che potrebbe influenzare la tua decisione è la funzionalità pronta all'uso. Ad esempio, ci sono molti più moduli aggiuntivi per i nodi di quanti ce ne siano per le tassonomie ma per le tassonomie si esce dalle pagine dell'elenco (se le si desidera). Potrebbero esserci anche funzionalità relative alla gerarchia che è più facile ottenere con una soluzione o l'altra.

Le definizioni dei tipi di contenuto sono solo una parte dell'immagine. Dovresti assolutamente considerare in che modo intendi che il contenuto sia presentato all'utente, come desideri che l'utente navighi attraverso la gerarchia dei contenuti, in che modo questo contenuto sia collegato ad altri contenuti del sito, come desideri che gli amministratori amministrino questo contenuto, ecc. Ad esempio, vuoi una sorta di sistema di menu gerarchico, vuoi che le persone siano in grado di andare alla rivista o pubblicare pagine o che i contenuti siano correlati solo a quelli visibili nelle pagine degli articoli. Vuoi avere una sola ricerca che elenchi tutti e 3 i tipi di contenuto (questo potrebbe essere meno banale se alcuni sono nodi e altri sono termini di tassonomia).

Pianifica tutto questo e poi vedi quali moduli sono disponibili per aiutarti a raggiungere questo obiettivo. Potresti trovare un modo per facilitare il raggiungimento di ciò che desideri. In caso contrario, devi solo andare con quello che ritieni migliore per qualsiasi motivo tu abbia.

A volte puoi andare in un modo e poi trovare qualcosa che rende difficile raggiungere i tuoi requisiti. Se lo pianifichi in anticipo il più possibile, riduci quel rischio.

Un'altra considerazione quando si usano i termini della tassonomia per cose come "Rivista" è che perderai funzionalità come la revisione e i commenti su quegli articoli. Le revisioni concesse possono essere aggiunte con un modulo come Revisione tassonomia ma si tratta di un modulo con una base di installazione molto bassa. Personalmente mi fiderei del core sulla gestione delle revisioni sui nodi.

Mi viene in mente almeno un'occasione in cui ho dovuto cambiare qualcosa da un termine tassonomico a un nodo dopo che un progetto è diventato attivo a causa di cambiamenti nei requisiti, e questo comporta un bel po 'di ristrutturazione e migrazione.

Probabilmente scoprirai che se passi ad usare altri tipi di entità come nodi con entity_reference, allora non avrai problemi ad apportare le modifiche poiché tutto funziona allo stesso modo ma ti darà maggiore flessibilità.

Non dirò che questa è la risposta più accurata, ma è come la penso. Spiegherò con alcuni esempi.

Di solito uso le tassonomie per classificare i nodi in base a un'astrazione. Ad esempio, le notizie possono essere classificate in sport, politica, ecc.

Ma quando voglio avere un riferimento come una rivista, penso al futuro. Pensa a quando vuoi aiutare l'utente a decidere quale articolo scegliere. Il grado di rivista (forse il fattore di impatto) è una possibilità. O forse voglio contattare quella rivista. Un termine non mi aiuterebbe in questa situazione, dove sarebbe se fosse un nodo o un'entità.

D'altra parte devi fare alcune cose da solo. Ad esempio, facendo clic su un termine di tassonomia si accederà a una pagina piena di nodi categorizzati di quel termine. Quindi ora sono necessari una vista e un filtro contestuale, ecc.

Ero sicuro che qualcuno mi chiedesse perché sarei rimasto lontano dalle raccolte di campi, ma il commento sembra essere stato rimosso. Ad ogni modo i miei 2 centesimi:

Le tassonomie dovrebbero essere utilizzate per la classificazione e la categorizzazione. Non per le relazioni sui contenuti. Collegando 2 parti di contenuto tramite un termine di tassonomia si utilizzano 3 entità in cui sono necessarie solo 2.

In base alla mia esperienza, sebbene le tassonomie siano ora fieldable, non sono entità a pieno titolo, e quindi non dovrebbero essere utilizzate come "contenuto".

In questo caso particolare, se la tua rivista ha dei contenuti (una descrizione di cosa si tratta, dettagli su come ordinarli, ecc.) O una "pagina" a sé stante, allora dovrebbe essere un tipo di contenuto, perché è contenuto.

I problemi sono un po 'ambigui, ma è probabile che tu abbia una panoramica ecc., Quindi probabilmente hanno una pagina e sono anche contenuti. Quindi un altro tipo di contenuto.

Gli articoli sono ovviamente tipi di contenuto.

Nel costruire l'amministratore per questo puoi usare l'Entity Reference per collegare questi contenuti, ma puoi andare meglio.

Allo stesso modo in cui @Drupalist ha suggerito di utilizzare Field Collections, è possibile utilizzare moduli entità in linea (penso che faccia parte di Entity Reference). Le collezioni sul campo sono uno di questi vecchi moduli che rappresentano una grande idea, non molto ben implementata e con molte collisioni con altri moduli. Mentre ora sono entità, hanno ancora problemi e sarebbe meglio usare entità a pieno titolo (anche tipi di contenuto) per cose come voi autori ecc.

I moduli entità incorporati ti consentono di creare e modificare entità referenziate, dall'interno dell'entità da cui desideri fare riferimento ... quindi, crea / modifica l'autore dall'interno di un articolo, o semplicemente fai riferimento a una già creata.

Aggiungi CER e otterrai automaticamente un riferimento dall'autore all'articolo, l'articolo al numero e il numero al Magazine, o in qualunque direzione tu stia andando. Ciò ha dei vantaggi nel modo in cui le tue visualizzazioni si comportano, ma ti consente anche di mostrare un elenco di articoli nella pagina dell'autore e le informazioni sull'autore nella pagina dell'articolo, il tutto senza alcuna vista.

Tornando indietro alle tassonomie, le useresti per "taggare" articoli ecc. Con ... "pesca", "auto", "computer" ecc. / Qualunque cosa ... in modo da poter trovare qualsiasi numero, rivista, articolo o autore che ha contenuto / scritto su quel tag.

Ho cercato di fare questo breve, quindi spero che aiuti e abbia un senso. L'ho fatto su dozzine di siti. Eventi sportivi globali, siti di prenotazione di viaggi / vacanze, emittenti internazionali, bevande, enti di beneficenza, ecc. Potenti, potenti e ti coprono per esigenze impreviste.