Drupal: Riutilizzare VS Creare: qual è la strategia giusta?

Quando ci si trova di fronte ad un progetto Drupal che prevede la creazione di un gran numero di content type e quindi di field, viene da chiedersi quale sia la strategia migliore tra a) creare un nuovo field per ogni content type e b) riutilizzare quando possibile un field già creato. Vi spieghiamo perché non esiste la risposta giusta e come tutto possa dipendere dalle esigenze del vostro progetto.

˅
Tempo stimato di lettura
10 m 15 sec

Una delle funzionalità più interessanti di Drupal è la possibilità di creare nuove strutture dati (o tipi di contenuto) direttamente da interfaccia, senza dover scrivere una sola riga di codice.

Ricordo che quando mi avvicinai per la prima volta a Drupal ed al mondo dei CMS opensource, uno dei motivi per cui scelsi proprio Drupal tra i vari CMS presenti in rete, fu proprio il fatto che direttamente da interfaccia web, con pochi click del mouse, era possibile creare delle strutture dati anche di una certa complessità senza dover toccare una sola riga di codice PHP.

Erano i tempi di Drupal 4.6, CCK non era ancora uscito e c'era un modulo che si chiamava Flexinode. Da quei tempi di strada ne è stata fatta parecchio, ed a partire da Drupal 7, la possibilità di creare strutture dati anche molto complesse è stata integrata nel core ed estesa con il concetto delle entity. Ancora oggi la semplicità con cui è possibile creare delle strutture dati molto complesse direttamente da interfaccia e con l'aggiunta di qualche modulo, è uno dei maggiori punti di forza di Drupal.

Quando abbiamo pochi tipi di contenuto, e strutture dati piuttosto semplici in genere si può non vedere la necessità di una specifica strategia o di avere delle linee guida da seguire nella creazione dei tipi di contenuto ma cosa succede se i contenuti ed i campi che dobbiamo creare sono diverse centinaia?

In un recente lavoro Drupal, a fine progetto, avevamo qualcosa come 30 strutture dati diverse ciascuna con diversi field per un totale di oltre 170 field diversi. A questo punto viene da chiedersi, è stata la soluzione giusta? Avremmo potuto / dovuto riutilizzare più spesso lo stesso field. Che implicazioni / problematiche possono esserci nell'avere un numero di field così elevato?

OSTraining ha scritto di recente un articolo piuttosto interessante sull'argomento intitolato Should I re-use existing Drupal fields?, nel quale si prendono in esame i pro ed i contro sul riutilizzo dello stesso field. L'articolo non giunge ad una conclusione ma si limita ad elencare vantaggi e svantaggi, sottolineando come la scelta corretta dipenda dalle esigenze del progetto.

Ho provato quindi ad analizzare alcuni delle principali motivazioni per cui si tende a dire che riutilizzare un medesimo field tra vari content type potrebbe sembrare la soluzione più corretta.

PRO: riutilizzare lo stesso field è più veloce che crearne uno nuovo.

Vero, ma in minima parte. Utilizzando field UI, la procedura di creazione di un nuovo field è più lenta rispetto al riutilizzo di uno stesso field, ma la differenza è davvero minima, in quanto la creazione di un nuovo field richiede solo qualche passaggio aggiuntivo. Il resto è praticamente identico.

PRO: riutilizzando lo stesso field è più veloce il theming.

Falso. A livello di theming, utilizzare lo stesso field o implementarne uno nuovo, non fa nessuna differenza. Ci potrebbero essere tuttavia altri approcci, ad esempio basati su fences, per i quali riutilizzare un medesimo field risulterebbe più comodo.

Questa cosa funziona bene se il field dovrà avere lo stesso markup ovunque viene utilizzato. Può essere quindi un pro ma anche un contro, dipende sostanzialmente dal progetto e da come abbiamo organizzato la struttura dati.

PRO: Riutilizzare lo stesso field è comporta dei vantaggi in termini prestazionali.

Generalmente parlando è probabile che questa affermazione sia da ritenersi vera, ma una volta attivati tutti i sistemi di cache di Drupal ed altri sistemi di cache esterna (ad esempio memcache), è altrettanto probabile che la differenza sia irrilevante.

Aggiungere un nuovo field comporta la creazione di 2 nuove tabelle nel database (se è attiva la revisione). Avere quindi 200 field diversi comporta quindi nel caso peggiore la creazione di 400 nuove tabelle nel database, ma questo non è necessariamente un grosso problema. Più problematico a livello di performance è ad esempio il numero di field presenti in un dato bundle piuttosto che il numero di field unici in se.

Se guardiamo la documentazione ufficiale di Drupal (c'è una pagina dedicata all'argomento Reusing fields), al momento di scrivere questo articolo c'è solo un breve accenno alle performance "Reusing fields not only makes Drupal run faster, it also makes your project easier to maintain". Al di là di quanto viene detto relativamente alla gestibilità, che affronteremo successivamente, è interessante notare (guardando le varie revisioni della pagina) come i consigli sull'argomento siano cambiati nel corso del tempo.

Se seguiamo i consigli di chi di Drupal se ne intende, in Aquia si suggerisce di riutilizzare il field quando possibile, motivando la scelta con questioni di risorse e perfomance.

Sull'argomento si potrebbe scrivere molto, ma questo articolo non è il luogo adatto per scendere in dettaglio. Il nostro consiglio è quindi, se il progetto lo consente, riutilizzare lo stesso field è una buona pratica, ma se nel vostro progetto risulta preferibile per vari motivi creare dei nuovi field per ogni content type, non limitate la flessibilità del progetto pensando alle prestazioni, perché probabilmente non ne vale la pena.

PRO: riutilizzando più volte lo stesso field il sito è più semplice da gestire

Vero e falso. Avere un gran numero di field può comportare una maggior difficoltà nella gestione del progetto, ma se il naming dei field segue delle regole strutturate e se avete prestato tutta la dovuta attenzione alla fase di architettura dell'informazione del vostro progetto Drupal, un numero maggiore di field non necessariamente implica una maggior complessità di gestione, anzi, avere dei bundle (content type) composti da field differenti, permette una miglior separazione tra le varie funzionalità del sito, che nell'ottica di un progetto in continuo sviluppo potrebbe risultare preferibile.

E' anche vero che avere un elevato numero di field differenti, può implicare problemi nella gestione di alcune funzionalità di Drupal a livello di interfaccia. L'interfaccia del modulo Token in presenza di un elevato numero di field può avere notevoli limiti prestazionali, tanto da rendere praticamente inutilizzabile la stessa interfaccia di selezione dei token disponibili. Una soluzione potrebbe essere quella di limitare la profondità dell'albero dei token oppure utilizzare drush per l'elenco dei token, con il comando: drush token.

Anche la costruzione delle viste, soprattutto quanto sono coinvolti diversi content type all'interno della stessa vista, può risultare più complessa se si utilizzano field diversi tra i vari content type, ma se questa cosa dovesse diventare problematica, allora è probabile che il vostro progetto abbia bisogno di un aggiustamento architetturale, in quanto queste necessità andrebbero se possibile previste in fase di identificazione dell'architettura dell'informazione.

Considerazioni

Se analizziamo quanto discusso finora, possiamo concludere che non esiste un motivo specifico per cui il riutilizzo di uno stesso field debba essere consigliato rispetto alla creazione di nuovi field per ogni bundle (o tipo di contenuto che dir si voglia). La scelta va ponderata in fase architetturale, valutando pro e contro di ciascuna opzione.

A titolo di nota negativa, avere field condivisi può essere un problema nel caso in cui cambino le specifiche del progetto strada facendo, e ad esempio un field condiviso avesse la necessità di essere multi-field su di uno specifico bundle e single field su di un altro.

Se (come mi auguro facciate) utilizzate features per lo sviluppo dei vostri progetti Drupal, la gestione delle features e delle relative dipendenze potrebbe risultare leggermente più complessa utilizzando field condivisi, soprattutto in assenza di una buona strategia di pianificazione.

Se ipotizziamo che un tipo di contenuto (content type / bundle) corrisponda ad una specifica funzionalità (feature) del nostro progetto, condizione non sempre valida ma che può verificarsi piuttosto spesso, una buona strategia in queste condizioni è prevedere l'utilizzo di una feature base in cui salvare tutti i base field condivisi tra i vari content type.

In questo modo potremmo mantenere separate le varie funzionalità pur in presenza di campi condivisi.

Quello che emerge è che se da una parte non vi sono dei netti svantaggi all'utilizzo di nuovi field per ogni tipo di contenuto rispetto al riutilizzo di un medesimo field condiviso tra i vari tipi di contenuto, quello che fa evidentemente la differenza è una buona strategia di pianificazione iniziale, dalla quale il progetto non può prescindere. Ecco perché noi in Twinbit abbiamo definito una specifica strategia, perché quando le strutture dati diventano complesse, avere la corretta procedura di implementazione significa poter garantire la gestibilità e la scalabilità del progetto.

La nostra strategia

Analisi architetturale prima di tutto.

Quella che potete intravvedere qui sotto è una mappa con la struttura dei tipi di contenuto per un progetto cui abbiamo recentemente lavorato.

Prima di iniziare a lavorare con Drupal, la prima cosa che facciamo è analizzare l'architettura dei dati e dell'informazione, strutturare una mappa e definire tutti i tipi di contenuto, le relazioni e le strutture dati che andremmo poi a replicare in Drupal.

I tipi di contenuto, parola d'ordine generalizzare.

In fase architetturale, se abbiamo delle strutture dati tra loro molto simili, a meno che non strettamente necessario, andremo a preferire la strada di un unico content type generalizzato (possiamo ad esempio utilizzare un field aggiuntivo per specificare una eventuale classe da assegnare al nodo se avessimo particolari esigenze di stilizzazione). Questo riduce i tempi di implementazione e di gestione. Implementare, configurare e temizzare un unico content type, per quanto eventualmente più complesso, ha sicuramente i suoi vantaggi in termini di tempo. Anche a livello di features la gestione è più semplice.

I field. La scelta tra riutilizzare o creare nuovi field.

Se sin dalla fase iniziale del progetto sono disponibili tutte le informazioni sul progetto, e se queste specifiche non andranno a mutare nel corso del tempo, allora probabilmente abbiamo già tutto quello che serve per definire i tipi di contenuto e le funzionalità da implementare. In queste condizioni risulterà possibile e comodo avere un gran numero di campi generalizzati e condivisi tra i vari tipi di contenuto, nell'ottica della semplificazione, sacrificando forse un po' la flessibilità.

Al contrario, se le specifiche iniziali del nostro progetto sono solo una parte del tutto, o se il progetto avrà bisogno di evolvere con lo sviluppo, in queste condizioni conviene prediligere una soluzione che offra la massima flessibilità possibile e quindi l'utilizzo di field differenti per ciascun tipo di contenuto si rivela la scelta migliore. In questa ottica le varie funzionalità del sito risultano totalmente indipendenti e più semplici da gestire come singole unità (attivabili o disattivabili indipendentemente).

Strutturare il naming dei field.

Se abbiamo un content type chiamato "entry", tutti i field specifici per questo content type avranno il naming che inizia con "field_entry_". Quindi ad esempio, un field immagine specifico per il tipo di contenuto "entry" potrebbe essere "field_entry_image"; un field descrittivo con un'area di testo "field_entry_description" e così via.

Tutti i field che invece che saranno condivisi tra diversi content type, utilizzeranno una nomenclatura generica, in cui non comparirà nessuna indicazione relativa al bundle; un campo immagine globale potrebbe essere field_image o field_thumbnail ad esempio.

Questa logica permette immediatamente di capire se un field è condiviso globalmente o se è specifico di un dato tipo di contenuto. In questo modo ad esempio possiamo già sapere se sia possibile modificare la cardinalità del field senza che questo influisca su altri tipi di contenuto.

Come ultima nota, per tutti i nomi macchina di field e content type usiamo una nomenclatura rigorosamente in inglese.


Questi accorgimenti sembrano poca cosa se presi singolarmente, ma se presi nel'insieme, vi assicuriamo che alla fine contribuiranno a fare la differenza tra il successo o l'insuccesso del vostro progetto Drupal.

Voi cosa ne pensate? Avete delle strategie differenti o opinioni differenti e volete dire la vostra? Ogni commento od opinione in merito è benvenuto.

Nel frattempo, un arrivederci al prossimo articolo.

Gli ultimi post di Andrea Panisson

Restiamo in contatto

Enter your email address below to receive all our latest articles and announcements via email.