Con l'attuale stato D8, qual è l'albero decisionale per la creazione di un nuovo tipo di entità di contenuto rispetto alla creazione di un tipo di contenuto per l'entità di contenuto "Nodo"?

Abbiamo visto quattro anni e la prima versione di Drupal 8 da quando la risposta accettata è stata scritta per la domanda " Quando è appropriato creare un'entità anziché aggiungere un nuovo tipo di contenuto ?" E, le entità sono più centrali in Drupal 8 rispetto a Drupal 7. ( RefB , RefC , RefD )

In questo nuovo mondo di Drupal 8, qual è l'albero decisionale per la creazione di un nuovo tipo di entità di contenuto rispetto a un nuovo tipo di contenuto per l'entità di contenuto di tipo "Nodo"?

Quando consideri una risposta, considera quanto segue:

• Un nuovo tipo di contenuto per il tipo di entità di contenuto di "Nodo" è ancora appropriato in situazioni del 99% rispetto a un nuovo tipo di entità di contenuto?
• L'albero decisionale ora include motivi più, migliori o più chiari per allontanarsi dall'uso del tipo di entità di contenuto "Nodo" e creare invece un nuovo tipo di entità di contenuto? E se sì, cosa sono? Includono:
  • Prestazione?
  • Sicurezza / permessi?
  • Il numero di moduli che funzionano con i tipi di contenuto di tipo di entità nodo e non funzionano con altri tipi di entità di contenuto?
• Forse - in base alla precedente risposta accettata a cui si fa riferimento in precedenza - l'unico motivo generale per eseguire un tipo di entità di contenuto personalizzato è se si desidera raggruppare i dati del Nodo, ad esempio con termini di tassonomia o annotare Nodo, ad esempio con commenti?

La compatibilità dei moduli sembra una considerazione particolarmente interessante per un albero decisionale. Al momento, alcuni dei moduli più installati hanno una versione per 8.x che non è semplicemente alpha, beta o rc (una release candidate). E sembra difficile identificare quanti di questi funzioneranno immediatamente con un nuovo tipo di entità personalizzato rispetto a un nuovo tipo di contenuto di entità nodo. Non sembra esserci un attributo del progetto per distinguere tra quelli che sono "scritti per entità" rispetto a "scritti per tipi di contenuto di entità nodo".

Dai un'occhiata a pathauto, che è attualmente il quarto modulo più installato di quelli che hanno qualsiasi tipo di rilascio 8.x. La gente sta lavorando duramente su una versione 8.x che generalmente supporta entità e non solo tipi di contenuto di tipo entità nodo. Ma che dire di tutti gli altri moduli? E i moduli che supportano entità che in genere richiedono tipi di entità di contenuto personalizzati per avere "hook" specifici del modulo prima che il modulo funzioni con loro? (Contro il modo in cui i moduli possono funzionare immediatamente con nuovi tipi di contenuto?) Questo sembra essere il tipo di sfida con cui il team pathauto sta lavorando, e forse è un motivo per allontanarsi da un tipo di entità di contenuto personalizzato?

Potrebbe anche valere la pena ricordare che Drupal 8 core contiene un'interfaccia utente per la creazione di nuovi tipi di contenuto per l'entità del contenuto di tipo "Nodo", ma al momento non contiene un'interfaccia utente per la creazione di nuovi tipi di entità del contenuto. ( RefX , RefY , RefZ )

Albero decisionale per la scelta tra la creazione di un nuovo tipo di contenuto di tipo entità nodo rispetto a un nuovo tipo di entità di contenuto:

1. Sei un programmatore o hai un facile accesso a un programmatore?
   • In caso contrario, al momento sei praticamente limitato alla creazione di nuovi tipi di contenuto di entità nodo. (Non esiste un'interfaccia utente nel core per la creazione di nuovi tipi di entità di contenuto e il modulo contrib ECity (Entity Construction Kit) attualmente ha solo una versione alpha.)
   • Se sì, continua ...
2. Sai esattamente quali moduli contrib vuoi sfruttare per i tuoi dati?
   • In caso contrario, la scommessa sicura è probabilmente quella di creare un tipo di contenuto di entità nodo.
   • Se sì, quei moduli supportano già i tipi di entità personalizzati che stai prendendo in considerazione o sei disposto a contribuire a migliorarli in modo che possano o ricreare la funzionalità desiderata nel tuo modulo?
     • In caso contrario, la creazione di un tipo di contenuto di tipo entità nodo può essere la soluzione migliore per te.
     • Se sì, continua ...
3. I dati di contenuto effettivi abilitati dal tuo modulo aiuteranno semplicemente a raggruppare o annotare altri dati di contenuto? (In modo che venga raramente visualizzato da solo.)
   • Se sì, considera se il tuo modulo è simile ai tipi di entità esistenti per i termini e i commenti di tassonomia. In tal caso, un nuovo tipo di entità potrebbe essere una scommessa sicura.
   • In caso contrario, continua ...
4. Puoi spiegare chiaramente perché un nuovo tipo di contenuto di tipo entità nodo non funzionerà per te?
   • Se no, la tua scommessa sicura è probabilmente quella di creare un nuovo tipo di contenuto di tipo entità nodo.
   • Se sì, continua ...
5. Infine, sei sicuro di non poter semplicemente estendere il tipo di entità Node e di voler ricreare tutte le sue utili funzionalità come le operazioni CRUD?
   • Se sì, vai avanti e crea un nuovo tipo di entità personalizzato.
   • Se no, o se non sei sicuro, allora probabilmente vuoi coinvolgere alcuni esperti per aiutarti a decidere.

Gli appunti:

1. Questo albero decisionale non considera le prestazioni o la sicurezza. Non sono sicuro se o quando un nuovo tipo di entità di contenuto personalizzato avrebbe prestazioni migliori e sarebbe più o meno sicuro di un tipo di entità Node.
2. Anche se questo albero è una buona risposta, probabilmente non rimarrà nel tempo a causa degli aggiornamenti nel core di Drupal e nelle versioni del modulo contrib. StackExchange non sembra accettare come la risposta "migliore" oggi potrebbe non essere la risposta migliore domani.)

Un approccio semplice a tale proposito è quello di prendere in considerazione lo scopo del progetto, le dimensioni e i requisiti aziendali.

1. In che modo il tipo di contenuto predefinito dell'entità nodo influisce sulla costruzione del progetto in un modo semplice e ordinato più vicino all'architettura e ai flussi di dati prodotti dal pensiero analitico dei documenti di progetto.

Un avviso importante qui la decisione di creare un nuovo tipo di entità di solito presa da sviluppatori o lead tecnici non da costruttori di siti o proprietari di progetti che gestiscono l'applicazione e si concentrano solo sul business.

2. Drupal 8 dipende da alcuni pacchetti di symfony2 ed è più vicino ai framework, allo sviluppo che ai tradizionali cms che parlano di Drupal con quei grandi cambiamenti architettonici, immagino che costruire una nuova entità sia meglio che fare molte personalizzazioni e configurazioni complesse sui tipi di contenuto di entità nodo per sfruttare Drupal tra gli altri framework poiché molte persone non amano il modo in cui la configurazione di Drupal e le impostazioni distribuite, potresti dover affrontare alcune persone provenienti da WordPress e utilizzate per configurare tutto da un modulo che li rende infastiditi quando si tratta della dashboard di amministrazione di Drupal.

3. Drupal 9 prevede di rimuovere completamente il sistema hook e sostituirlo con il dispatcher di eventi che porta a una grande necessità di un'interfaccia di amministrazione per creare una nuova entità poiché alterare la funzionalità esistente dal codice sarà molto più difficile per le persone che non sono sviluppatori e sarà molto essenziale per aggiungi quella funzione.

Alla fine , vedo che nuove entità su misura per le esigenze del progetto offrono prestazioni migliori rispetto ai tipi di contenuto complessi con un gran numero di campi poiché ora ogni campo aggiunge 2 tabelle al DB e deve caricare la sua configurazione su ogni richiesta, specialmente con il è richiesta una logica aziendale pesante.

Chiaro e semplice: non è tutto contenuto. L'elenco dei contenuti potrebbe essere piuttosto lungo ed essere fonte di confusione se si utilizzano solo tipi di contenuto. ( ContentEntityBase potrebbe anche essere implementato da un'entità personalizzata)

Se hai un autore e uno stato pubblicato , dovresti scegliere un tipo di contenuto.

Altrimenti (supponendo che tu sia un programmatore) dovrebbero essere preferite entità personalizzate. Molto può essere facilmente implementato con tutte le interfacce (come revisionabile, field-based, restrizione d'accesso ecc.)

Dal mio punto di vista questa è solo un'architettura più chiara e ordinata (e anche più performante).

Pensando alla riusabilità in diversi progetti, lo sforzo di far esplodere le entità personalizzate ... ci sono anche ingegnosi aiutanti come il generatore di codice drupal . Per mantenere la codifica personalizzata (o la complessità) a un livello basso, è consigliabile utilizzare i tipi di contenuto se si desidera:

• Per tradurre l '"entità" (almeno in D7), ci sarebbe anche un'interfaccia.
• (aperto per suggerimenti) ..

È una domanda difficile che onestamente penso sia compresa solo dopo averla implementata in precedenza. Ma, come accennato da Remy, non tutto è grezzo, contenuto per l'utente .

In Drupal 7, esisteva la capacità di creare entità personalizzate, ma poteva essere un compito scoraggiante se eri in difficoltà con OOP. È stato un po 'implementato per metà (o per metà, comunque tu voglia dirlo), che ha portato a modi di creare entità che non erano tutte esattamente uniformi e concordavano approcci, con procedimenti misti e OOP misti.

In Drupal 8, l'idea è molto più realizzata ed è molto più semplice iniziare a funzionare con un'entità personalizzata. Il nodo stesso si basa su ContentEntityBase, così come i blocchi, gli utenti, i file e la tassonomia.

I nodi sono specificamente per i dati di contenuto pubblicati, visibili (o autorizzati) che in genere fungono da contenuto (ovvero, in un menu o nella Sitemap o nella Sitemap XML o nei feed RSS, ecc.). Drupal è stato progettato in un modo in cui è possibile agganciarsi a qualsiasi fase del processo delle operazioni del nodo e modificarlo, il che può avere conseguenze indesiderate se si dispone di un mix errato di moduli forniti. Questa è probabilmente un'opinione controversa, ma aiuta a divorziare dall'idea di "tutto è un nodo" per abbracciare di più il concetto di Entità.

Contenuti ideali che rendono fantastici tipi di contenuti:

• Articolo
• Pagina
• Annunci di lavoro
• Evento
• Pagina di destinazione
• Homepage

Il filo conduttore per loro è che condividono il concetto di un tipo di contenuto. Di solito si trova in qualsiasi numero di stati del flusso di lavoro (pubblicato, promosso, appiccicoso, archiviato, in primo piano, ecc. - se si utilizzano opzioni di pubblicazione personalizzate) e un gran numero di moduli contribuiti interagisce direttamente con esso, come Pathauto.

Ma supponiamo che tu voglia archiviare in Drupal dati interni, privati, che guidano altri dati o dati che non dovrebbero consentire l'integrazione al di fuori del suo ambito a meno che tu non lo consenta. Che tipo di dati potrebbe essere? Ecco alcuni possibili tipi:

• Prodotto (Drupal Commerce)
• Elemento pubblicitario (Drupal Commerce)
• Server di ricerca (ApacheSolr / SearchAPI)
• Contatto (come il lead CRM)
• Ticket (come il ticket di supporto)

Cosa li rende così diversi? Perché dovresti desiderare un'entità per il contatto, invece di utilizzare il modello utente? Potresti fare alcuni argomenti lì, ma il mio esempio sarebbe che se dici, raccogliendo indirizzi e-mail e nomi e alcuni altri metadati da un modulo di contatto, memorizzali come entità personalizzata. Impedisci che l'elenco utenti venga inquinato da elementi non relativi all'account, riduci potenziali problemi di sicurezza (cosa succede se uno script o qualcuno aggiorna accidentalmente quegli account in modo che diventino amministratori o invii una posta di massa?), Gestisci le spese generali interne dell'utente reale account più semplice e segmentate ciò che state acquisendo in ciò che è, un bit specializzato di dati.

Da qui, è in gran parte separato dalle parti più automatiche del sistema Drupal / Node e puoi personalizzare le azioni e l'esperienza. Determinare i percorsi, l'accesso e il flusso di lavoro CRUD.

In questa mentalità, rende più facile capire perché l'approccio a ciò sarebbe stato fatto in quel modo. Prendi l'esempio del ticket di supporto: sono le richieste in arrivo, ma non sono i dati pubblicati e probabilmente ha un flusso di lavoro molto specifico che è più facile da configurare che separare da parti del sistema del nodo che non vuoi che aderisca a.

Un altro esempio potrebbero essere i dati importati esterni. Nella maggior parte dei casi, questi dati di solito non sono arricchiti con dati Drupal locali (anche se, come entità, è ancora possibile farlo). Potrebbe essere qualsiasi cosa. Forse sono le fatture, forse sono libri, forse stanno tirando marche di birra.

Dati come questo sono in genere specifici e richiedono un controllo al di là del significato del nodo. Ciò non significa che non sia possibile aumentarlo utilizzando un campo di riferimento su un nodo per puntare all'entità personalizzata (è così che Drupal Commerce ha funzionato, ad un certo livello) per arricchire i dati. Allo stesso tempo, stai isolando e assicurando il controllo dei tuoi dati e dell'interfaccia utente da un codice contributore errato che va oltre la sua progettazione e interferisce con il tuo modello. Questo è probabilmente meno un problema in D8 rispetto a D7, anche se alcuni ganci rimangono.

L'architettura corretta esiste ora per incoraggiare la separazione. Non tutto è un nodo.