Quando si devono realizzare siti di un certo livello scegliere lo strumento adatto è una delle cose più delicate che ci siano. La scelta sbagliata potrebbe portarci ad un fallimento oppure alla necessità di dover riniziare tutto da capo. Per un lavoro che sto seguendo devo importare e rendere fruibili (leggasi: trasformare in nodi di Drupal) un buon numero di file XML dove la componente principale sono dei rami tutti uguali, tanti rami tutti uguali, che non possono essere considerate come entità separate.

Fate conto di dover fare il censimento della cancelleria delle filiali di una azienda (compresa la casa madre). In tutte sono presenti penne (di colore differente), evidenziatori (anche essi di colore differente) e vari tipi di formato di fogli. La prima cosa che viene in mente è quella di creare un tipo di contenuto per singolo elemento e legare il tipo dell'elemento tramite una tassonomia. Avremo quindi la tassonomia “cancelleria” da associare a più tipi di contenuto, ma questo ci porta alla necessità di avere anche una tassonomia per i colori. Quindi per le tre penne di colore rosso della filiale 'X' avremo un nodo, per le 2 penne nere avremo un altro nodo, e per l'evidenziatore verde un terzo nodo. E meno male che abbiamo solo penne, evidenziatori e fogli, perché se dovessimo aggiungere anche gomme, matite e temperamatite, le cose si farebbero complicate. Dobbiamo per forza di cose raggruppare più elementi possibili in un unica struttura.

E torniamo a quello che dicevo nel cappello introduttivo: dobbiamo scegliere lo strumentto adatto. Nel nostro caso si tratta del modulo CCK di Drupal. Ma non lo possiamo utilizzare così come è: per come è stato costruito questo modulo ci permette di definire un gruppo contenitore di altri elementi CCK, ma questo gruppo non puo' essere inserito più volte. Lo possono essere gli elementi al suo interno, ma non il gruppo. Ma questo non ci deve fermare. Sappiamo che il CMS Drupal ha mille risorse utilizzabili per i nostri bisogni, e questa volta la risorsa è proprio il modulo CCK. E' vero, poc'anzi ho detto che questo modulo non ci permette di raggruppare gli elementi in “blocchi” ripetibili per come è stato costruito, ma nessuno ci vieta di costruire un nuovo elemento di CCK che rappresenti proprio il nostro “contenitore” ripetibile; nel mio caso ho creato un nuovo campo “Elementi” contenente tre righe (tipo, colore, quantità) e questo mi permette di definire la possibilità di inserire più “righe” del campo “Elementi” permettendomi così di gestire al meglio l'inserimento della cancelleria di ogni singola filiale.

L'uso di questa soluzione ci permette anche di poter dare al cliente alcune viste (magari con i filtri “visibili” così da creare delle ricerche mirate “a costo zero”) grazie alla programmazione di base del modulo CCK che esporta gli elementi che compongono il campo “Elementi” come entità singole; possiamo, ad esempio, cercare quali filiali della nostra azienda hanno delle penne rosse oppure hanno una calcolatrice CASIO. E legando questi elementi al nodo di appartenenza (una delle tante possibilità “normali” del modulo “Views”) diamo in mano all'utente la possibilità di andare a visionare i dati, della cancelleria, delle filiali trovate. Se avessimo cercato di fare tutto questro tramite l'uso di CCK “di base” e di alcuni tipi di contenuto avremmo avuto non poco da fare con le ricerche mirate e con la relazione tra “tipo di contenuto cancelleria” e “tipo di contenuto succursale”. E neppure il modulo “node reference” (sottomodulo CCK) ci può aiutare perché crea una relazione che lega la filiale ad uno o più “nodi” cancelleria, ma a noi serve il contrario.

Per chiudere vi mostro una immagine di quello che vede l'utente quando va ad inserire o modificare un tipo di contenuto che ha il nostro “Elementi” (il bordo rosso l'ho inserito io prima di modificare la grafica del sito):

Se avete trovato questo articolo interessante potrei anche scrivere come realizzare da zero un nuovo tipo CCK. Fatemi sapere nei commenti.