POLITECNICO DI MILANO
Polo Regionale di Como
Facoltà di Ingegneria dell'Informazione
Corso di Studi in Ingegneria Informatica
IMPORT/EXPORT IN
SISTEMI CMS
RELATORE:
ELABORATO FINALE DI:
Marco Brambilla
Manfredi Andrea
Matricola: 703338
ANNO ACCADEMICO 2009/2010
1
Indice
1 Introduzione
4
1.1
CMS ( Content Management System ) . . . . . . . . . . . . . . .
1.2
Un problema fondamentale: L'integrazione . . . . . . . . . . . . .
4
1.3
Obbiettivi della Tesi
. . . . . . . . . . . . . . . . . . . . . . . . .
5
1.4
Struttura Tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2 I Sistemi CMS
2.1
2.2
2.3
2.4
4
6
I CMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.1
Cenni Storici
6
2.1.2
Vantaggi e svantaggi dei CMS . . . . . . . . . . . . . . . .
6
2.1.3
Gestione dei contenuti . . . . . . . . . . . . . . . . . . . .
7
2.1.4
I Web Content Management System
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
8
Problemi di Integrazione . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.1
Cms to Web Service
8
2.2.2
Web Service to CMS . . . . . . . . . . . . . . . . . . . . .
I più usati e famosi CMS
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
10
2.3.1
Joomla!
2.3.2
Caratteristiche
2.3.3
Estensioni . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3.4
Componenti . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3.5
Moduli . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.6
Template
. . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.7
Mambot . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Drupal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
10
2.4.1
Storia
2.4.2
Struttura
. . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4.3
I Moduli . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.4.4
Contenuti . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.4.5
Viste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3 Import/Export in Drupal
14
22
3.1
Backup and Migrate
. . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2
Printer, e-mail and PDF versions . . . . . . . . . . . . . . . . . .
23
3.3
User Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.4
Taxonomy import/export via XML . . . . . . . . . . . . . . . . .
26
3.5
Taxonomy CSV import/export
. . . . . . . . . . . . . . . . . . .
27
3.6
Views Datasource . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.7
Custom Reports
28
3.8
Views Importer . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.9
Save To FTP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.10 Node Table
3.11 CCK Importer
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.12 Views Node Feed . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.13 Joomla To Drupal
36
. . . . . . . . . . . . . . . . . . . . . . . . . .
2
4 Prove con il portale Energy CH-IT
38
4.1
Cos'è l'Energy CH-IT
. . . . . . . . . . . . . . . . . . . . . . . .
38
4.2
Moduli per l'import di database in Drupal . . . . . . . . . . . . .
38
4.2.1
Modulo Sheetnode
39
4.2.2
Node Import
4.3
4.4
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
42
Creazione di un nuovo content type tramite il modulo CCK . . .
43
. . . . . . . . . . . . . . .
45
4.4.1
Modulo Node Import, utilizzo pratico
Passo 1: Selezione del Content Type . . . . . . . . . . . .
45
4.4.2
Passo 2: Selezione del le da importare
45
4.4.3
Passo 3: Impostazioni del le da importare
4.4.4
Passo 4: Mappatura degli attributi del le con i campi
. . . . . . . . . .
. . . . . . . .
46
della struttura dati . . . . . . . . . . . . . . . . . . . . . .
47
4.4.5
Passo 5: Opzioni per l'importazione
47
4.4.6
Passo 6: Impostazione dei valori di default
. . . . . . . .
47
4.4.7
Passo 7: Anteprima dei dati . . . . . . . . . . . . . . . . .
48
4.4.8
. . . . . . . . . . . .
Passo 8: Inizio dell'import . . . . . . . . . . . . . . . . . .
49
4.5
Creazione di interrogazioni sul database tramite le Viste . . . . .
51
4.6
Problemi riscontrati con l'operazione di migrazione del database
54
5 Conclusioni
59
A Glossario
60
3
1
Introduzione
1.1
CMS ( Content Management System )
Un Content Management System (CMS), che tradotto signica sistema di gestione dei contenuti, è uno strumento software installato su un web server progettato per pubblicare e gestire contenuti sul web. Solo questa parte di denizione
non indica nulla di particolare che già non si possa fare. Per questo, per comprendere meglio lo scopo dei CMS è necessario introdurre un ulteriore pezzo di
denizione:
La pubblicazione e la gestione dei contenuti è permessa anche per coloro che
non conoscono le tecniche di programmazione web.
Esistono numerosi CMS,
essi vengono suddivisi in due principali categorie:
CMS specializzati ( forum, blog, siti vetrina, enciclopedie on-line, ecc.)
CMS generici, che sono per natura più essibili, e possono essere congurati per la gestione di vari tipi di contenuti
Si può facilmente intuire che quelli specializzati derivino da quelli generici; la
distinzione viene fatta semplicemente per far emergere il lavoro già svolto ( congurare CMS generici per creare CMS specializzati) e per favorire il riuso di
questi modelli già costruiti evitando le perdite di tempo.
Tecnicamente un
CMS è un'applicazione lato server che si appoggia su un database preesistente
per lo stoccaggio dei contenuti ed è suddivisa in due parti: la sezione di amministrazione (back end ), che serve ad organizzare e supervisionare la produzione dei
contenuti, e la sezione applicativa (front end ), usata dall'utente per la fruizione
dei contenuti e delle applicazioni del sito. L'amministratore del CMS gestisce
dal proprio terminale, tramite un pannello di interfaccia e controllo, i contenuti
da inserire o modicare e invia i dati al database del server tramite protocollo
FTP.
1.2
Un problema fondamentale: L'integrazione
L'integrazione di Web Service in un CMS è un aspetto fondamentale per comprendere le potenzialità di un Content Management System. Approcciarsi ad
un nuovo metodo per sviluppare il proprio sito web senza questa possibilità
sarebbe inutile poiché si andrebbe a perdere un eventuale lavoro già svolto in
passato. Per questo motivo gli sviluppatori aggregati ai vari CMS hanno speso
molto tempo per riuscire ad ottenere un set di strumenti (i moduli) che fosse
in grado di coprire quasi totalmente l'aspetto della migrazione da un sito web
sviluppato con le comuni tecniche di programmazione web ad uno sviluppato
tramite CMS. I moduli che sono tutt'ora disponibili hanno molte potenzialità
ma non devono essere sottovalutati poiché il loro utilizzo necessità un certo
di livello di accortezza.
Per questo motivo il problema dell'integrazione verrà
trattato più dettagliatamente nella sezione successiva.
4
1.3
Obbiettivi della Tesi
Gli obbiettivi di questa tesi sono molteplici:
1. Comprendere in modo dettagliato i problemi dell'integrazione tra web
service e CMS;
2. Approfondire l'argomento dell'import/export, per comprendere le potenzialità di queste piattaforme nell'interfacciarsi con il resto degli attori
presenti sul web;
3. Identicare un set di strumenti (moduli) adatti alla risoluzione delle varie
casistiche di import/export;
4. Applicare i concetti appresi su un caso d'uso reale, il portale ENERGYCHIT.
1.4
Struttura Tesi
La tesi, oltre alla parte di introduzione, contiene:
Una sezione di approfondimento sui concetti base dei sistemi CMS ( I
Sistemi CMS ).
La sezione principale in cui vengono descritti i Moduli Utilizzati ( Import
Export in Drupal ).
Un ulteriore sezione in cui vengono presentati le prove eettuate con un
Web Service esistente (Prove con Energy-CHIT).
Una sezione di conclusioni nali.
Una glossario dove verranno inseriti i concetti e i termini non chiari a
tutti.
5
2
I Sistemi CMS
2.1
I CMS
2.1.1 Cenni Storici
I content management system sono nati negli Stati Uniti e sono stati inizialmente sviluppati da alcune organizzazioni che producevano notevoli quantità di
pubblicazioni, per il loro uso interno. Nel 1995 la CNET rese pubblici gli studi
e i prodotti sviluppati internamente, distribuendoli con l'etichetta Vignette. La
compagnia cominciò a mettere a disposizione il proprio software come sistema
di gestione dei contenuti via web. Per la prima volta un utente poteva creare il
proprio sito direttamente dal web, usando l'interfaccia CNET. Nel 1998, la Pencom Web Works, una compagnia di consulenza aziendale, introdusse il server di
trasformazione dati (DTS) Metaphoria, che permetteva agli sviluppatori Java
di scrivere applicazioni che si potevano collegare ai contenuti e permettevano di
distribuire tali contenuti su canali diversi. Il prodotto non ebbe successo, ma il
concetto che era stato introdotto costituì le basi di ciò che è diventato il CMS
odierno.
2.1.2 Vantaggi e svantaggi dei CMS
Vantaggi
Un CMS permette di costruire e aggiornare un sito dinamico, anche
molto grande, senza necessità di scrivere una riga di HTML e senza conoscere
linguaggi di programmazione lato server (come PHP o ASP) o progettare un
apposito database.
L'aspetto esteriore delle pagine può essere personalizzato
scegliendo un foglio di stile CSS appositamente progettato per un determinato
CMS. I at le CMS, altrimenti noti come text-based CMS, sono dei content
management system che si basano su le di testo (il più delle volte les XML)
e che perciò non necessitano di alcun database come MySQL, PostgreSQL, ecc.
Questi CMS sono facilmente installabili e dunque sono particolarmente adatti
per siti personali o per piccole comunità. La maggior parte dei CMS sono opensource e quindi tutti i relativi vantaggi del software aperto.
I Siti statici o
vetrina sono semplici da realizzare per chiunque, sia che sia un programmatore
web svogliato sia che sia un commerciante che voglia far conoscere la propria
attività senza dover ricorrere ad una azienda di web-design.
Per esempio il sito internet del gruppo Foppapedretti è stato realizzato in
Joomla ( uno dei più noti CMS), il sito della squadra calcistica Sampdoria è
stato realizzato anch'esso tramite un Content Management System. Il campo
d'uso è veramente vasto e permette la pubblicazione di contenuti nelle forme
più svariate a seconda delle esigenze.
Svantaggi
Un CMS è tanto più eciente quanto più è specializzato. Molti
piccoli portali fanno ricorso a CMS (scritti da altri e messi a disposizione gratuitamente o a pagamento) di tipo generico; per quanto un CMS possa essere
essibile, un sito basato su questa struttura in genere presenta un aspetto poco
personalizzato se non è possibile intervenire direttamente sul codice sorgente
per modicarlo. Analogamente i contenuti saranno sempre ancorati a quanto
previsto da chi ha progettato il CMS e non alle esigenze di chi pubblica il sito.
Problemi di gestione possono derivare dal fatto che chi pubblica o gestisce il sito
può usare il CMS per intervenire sui contenuti e sull'aspetto, ma generalmente
6
(caso del software proprietario) non è in grado di intervenire direttamente (o
far intervenire) sulla struttura del CMS stesso; questo è un limite strettamente
connesso al vantaggio primario dei CMS: pubblicare un portale senza doverne
progettare la struttura o senza possedere le conoscenze tecniche (o le risorse
nanziarie) per uno sviluppo personalizzato. Tuttavia esistono anche CMS particolarmente evoluti che permettono di scrivere direttamente sul database.
È
il caso per esempio di alcuni CMS proprietari. Questi problemi sono risolvibili
utilizzando software open source: la possibilità di accedere al codice sorgente del
prodotto permette di personalizzare il software sulla base delle proprie esigenze a patto di non avere necessità di apportare modiche al prodotto adottato.
Anche in questo caso, vanno messi in conto i costi per lo sviluppo di moduli
personalizzati o funzioni particolari a meno di non possedere in proprio o nella
propria struttura aziendale le conoscenze tecniche per intervenire nel codice sorgente. I portali di una certa importanza generalmente non fanno mai ricorso a
CMS distribuiti bensì usano programmi e database progettati su misura, ovvero
"CMS personalizzati" e dunque necessariamente specializzati; in questo modo
la struttura e la presentazione vengono realizzate tenendo presenti i contenuti
che il sito dovrà ospitare e potranno essere modicati in seguito a nuove esigenze. Un ulteriore problema riguarda l'integrazione con sistemi già esistenti,
questo argomento sarà trattato nel dettaglio nella prossima sezione poiché è un
aspetto critico dei CMS.
2.1.3 Gestione dei contenuti
Per la gestione delle informazioni è necessario adottare una serie di passi:
1. Identicazione degli utenti di back end ( coloro che producono e pubblicano
i contenuti ) e di fronte end ( coloro che beneciano dei contenuti ).
2. Impostazione delle varie responsabilità e dei vari permessi di accesso alla pubblicazione (in un grosso progetto sviluppato da numerose persone
è necessario impostare privilegi e permessi di modica/lettura/scrittura).
Inoltre è ragionevole pensare che, per determinati ambiti, anche la fruizione
dei contenuti sia soggetta a restrizioni (forum, intranet aziendali, ecc).
Tutto questo è possibile tramite la denizione di gruppi utenti e, più in
dettaglio, tramite l'impostazione dei permessi per ogni singolo utente.
3. Il prodotto nale è il più delle volte costituito da componenti prodotti da
più persone, quindi è necessario determinare un workow, che tramite procedure di supervisione permette l'assemblaggio dei vari pezzi in maniera
semplice.
Per poter rendere eciente la comunicazione tra i vari liv-
elli della gerarchia, è necessaria un'infrastruttura di messaggistica, con
la quale i gestori del contenuto possono ricevere notica degli avvenuti
aggiornamenti.
4. Tracciamento e gestione delle versioni del contenuto
5. Pubblicazione dei contenuti
6. Gestione delle pubblicazioni delle varie sezioni del sito (Impaginazione,
collegamenti, ecc).
7
2.1.4 I Web Content Management System
Nonostante i CMS non siano stati concepiti per il Web, oggi il loro utilizzo più
diuso è rivolto alla gestione di siti web, soprattutto se sono di grandi dimensioni e richiedono un frequente aggiornamento. Una delle applicazioni più utili
dei sistemi di WCMS, infatti, è nella gestione dei portali (intranet, extranet,
community, siti di e-commerce...), dove vengono impiegati come strumento di
pubblicazione essibile e multiutente. Ad esempio, gestione di contenuti testuali
(notizie, articoli ecc.), link, immagini, liste di discussione, forum, materiale scaricabile. Può essere modicata anche la struttura stessa delle pagine in numero
ed organizzazione.
A volte i WCMS danno la possibilità di gestire anche più
versioni dello stesso sito (ad esempio, HTML o Mobile). I WCMS consentono di
denire utenti, gruppi e diritti in modo da poter permettere una distribuzione
del lavoro tra più persone. Per esempio, è possibile denire una classe di utenti
abilitati esclusivamente all'inserimento delle notizie, mentre si può riservare la
scrittura di articoli ad un altro gruppo, e limitare tutti gli altri alla sola consultazione.
L'introduzione di un web content management system in azienda
richiede la denizione di chiari processi interni di approvazione dei contenuti.
La scelta di un software di WCMS è strategica per le aziende che generano la
maggior parte di volume d'aari su Internet, ma, in proporzione diversa, è molto
importante anche per il libero professionista che vuole utilizzare il medium Internet per farsi conoscere. In letteratura esistono numerosi modelli che aiutano
a valutare il ritorno di un investimento in un WCMS. I costi di adozione sono
spesso elevati, quindi non sono sostenibili per i professionisti o i privati che non
fanno del Web la loro competenza di base. Per rispondere a questa necessità di
mercato sono nati alcuni application service provider (ASP) che orono questo
servizio direttamente via Web, senza richiedere alcun investimento hardware o
software. Gli ASP costano ai loro clienti un canone annuale per il servizio di
WCMS erogato.
2.2
Problemi di Integrazione
L'integrazione dei CMS con dei web services già esistenti (non realizzati tramite
CMS) è un problema delicato che apparentemente non sembra preoccupare ma
che invece risulta un ostacolo piuttosto alto da scavalcare. Per comprendere al
meglio il concetto è necessario fare una distinzione:
Integrazione di CMS in Web Service.
Integrazione di Web Service in CMS.
La distinzione è obbligatoria poiché le due operazioni non sono aatto uguali,
dieriscono in: procedure, vincoli e strutture dati.
Integrare invece due web
service realizzati tramite CMS è molto più semplice, a patto che siano stati
implementati i moduli per il passaggio da un content type all'altro.
2.2.1 Cms to Web Service
Ragionando per logica, inserire un CMS in un Web Service , signicherebbe unire
due applicazioni web con strutture completamente diverse. Il web service che
dovrebbe accorpare il Cms è costituito dai seguenti elementi:
8
Un Web Server che permette l'esecuzione del servizio;
Pagine HTML;
Script PHP/ASP/JSP;
Un Database;
Fogli di Stile CSS
Il CMS possiede anch'esso tutti questi elementi ma vengono nascosti per denizione,
cioè per far evitare all'amministratore di scrivere codice di qualsiasi tipo.
A
questo punto ci sono due possibilità per continuare il processo:
1. Se il CMS non è open-source c'è poco da fare, conviene abbandonare l'idea
di utilizzare i CMS è continuare lo sviluppo del web-service esistente.
2. Se il CMS è open-source si può accedere al codice sorgente ed integrarlo con
quello esistente, ma come si può intuire è un'operazione piuttosto lunga e
complicata, specialmente se si pensa cosa succederebbe all'aumentare della
dimensione del CMS. Per far comprendere più a fondo è meglio spiegare
un esempio pratico:
(a) Il web Service ed il CMS hanno due database diversi, con schema relazionale e tabelle diverse. Se trattiamo database con una decina di
tabelle, è fattibile rifare il modello relazionale unendo i due precedenti, ma se invece stiamo trattando database con centinaia di tabelle?
Non troverete nessuno, con un po di senno, che sia disposto a farlo.
(b) L'esempio sopra citato calza perfettamente anche per il resto dei
componenti (Pagine HTML, script PHP o JSP).
In denitiva l'integrazione di CMS in un web service già esistente (realizzato
con le tecniche comuni di programmazione web) è un operazione sconsigliabile
a prescindere dalla situazione iniziale, conviene invece realizzare il contrario,
ovvero integrare l'esistente web service in uno nuovo realizzato tramite CMS.
2.2.2 Web Service to CMS
Il caso di integrazione di un web service in uno implementato tramite CMS
è una via più immediata rispetto alla situazione precedentemente analizzata.
Qualsiasi CMS open-source o non , potente o meno, mette a disposizione dell'amministratore una serie di strumenti per l'importazione chiamati Moduli
(Per chiarire il concetto di modulo si rimanda alla sezione successiva I Sistemi
CMS). Ovviamente non tutti i CMS mettono a disposizione gli stessi strumenti
con la medesima potenzialità perciò è necessario scegliere con cura il CMS da
utilizzare a seconda delle necessità che si hanno.
I maggiori problemi che si
posso arontare in questa situazione sono:
Scelta del CMS adatto alle proprie esigenze.
Identicare in maniera corretta il modulo che permette l'operazione necessaria.
Gestire eventuali dipendenze del modulo in esame con altri moduli.
9
Risolvere eventuali problemi che il modulo solleva al momento dell'esecuzione.
Rendere disponibile, ai vari gruppi di utenti, i contenuti che il modulo ha
elaborato.
Può capitare però che uno di questi punti sia un problema non risolvibile per
una serie di motivi quali:
Il modulo non garantisce la totalità delle nostre necessità > Possibile
Soluzione: Ricerca di un altro modulo da aancare a quello già presente
che svolga il mancante.
A volte le dipendenze dei moduli creano conitti con altri moduli già presenti > Possibile Soluzione: Trovare una coppia di moduli che svolgano
lo stesso compito e che non creano conitti
La risoluzione dei problemi generati spesso non è possibile > Possibile
Soluzione: Si ritorna alla scelta del modulo, cercandone un altro che svolga
il medesimo compito e che non crei problemi. Se anche questa soluzione
non porta a nessun risultato concreto allora bisogna necessariamente cambiare il risultato che si vuole ottenere.
2.3
I più usati e famosi CMS
2.3.1 Joomla!
Joomla! è un software di content management per siti web, realizzato completamente nel linguaggio PHP. È pubblicato con licenza open source GNU GPL
v.2. È nato nel settembre 2005 da una scissione dal codice del CMS Mambo;
attualmente è in rapido sviluppo, sotto la guida di un gruppo di sviluppatori
(per buona parte ex-sviluppatori di Mambo) riuniti nell'associazione no-prot
Open Source Matters.
2.3.2 Caratteristiche
Il CMS è distribuito sotto forma di pacchetto compresso. È suciente scompattare l'archivio in una cartella pubblica di un server Web dotato di supporto
a PHP ed avere a disposizione un database MySQL per i dati del programma.
Dopo un processo di installazione (più propriamente, di prima congurazione)
di pochi minuti, il sito è operativo. Tra le caratteristiche principali proposte ci
sono:
Alto grado di personalizzazione grazie ai numerosi moduli, componenti e
mambot/plugin disponibili sia come Software libero che con altre licenze;
Caching delle pagine per incrementare le prestazioni;
Funzioni di Search Engine Optimization, per facilitare l'indicizzazione dei
contenuti da parte dei motori di ricerca;
Feeding RSS, che permette ai visitatori di essere avvisati degli aggiornamenti dei contenuti mediante l'utilizzo di un feed reader;
10
Versione stampabile delle pagine;
Esportazione delle pagine in formato PDF;
Pubblicazione tipo Blog; Sondaggi;
Ricerca testuale su tutti i contenuti inseriti;
Localizzazione internazionale, che permette la traduzione di ogni funzionalità del software nella propria lingua;
Altri componenti open source disponibili separatamente, sponsorizzati dal team
di sviluppo di Joomla! ma non sviluppati dallo stesso team consentono, fra le
altre cose, di:
Creare e gestire forum di discussione (Joomlaboard / Fireboard) ;
Tradurre l'intero contenuto del sito per renderlo fruibile in più lingue
(Joom!Fish);
Migliorare la gestione degli utenti registrati e potenziare loro interazioni,
creando un eetto community (Community Builder)
Figura 1: Home Page di una Installazione di default di Joomla!
11
2.3.3 Estensioni
Uno dei punti di forza di Joomla! è la vivacità della comunità che lo supporta, sia in termini di discussione e capacità di aiuto (il forum uciale supera i
100.000 post mensili) che di ampia disponibilità di componenti aggiuntivi per
personalizzare la funzionalità del motore. Tutte le estensioni vengono distribuite
sotto forma di pacchetti compressi, la cui installazione è gestita in maniera
completamente automatica da uno script apposito, disponibile nella sezione di
amministrazione del proprio sito Joomla!, che permette anche di disinstallare
estensioni già installate. Ne esistono di tre tipi: componenti, moduli e mambot.
Molte estensioni (nell'ordine delle migliaia) sono scaricabili dall'archivio uciale
http://extensions.joomla.org.
2.3.4 Componenti
I componenti di Joomla! sono estensioni speciche che permettono di aggiungere
funzionalità complesse a un sito realizzato usando il CMS Joomla!. I componenti
per Joomla! dieriscono dai moduli essenzialmente per il livello di complessità
supportato.
Tradizionalmente, i moduli vengono utilizzati per implementare
funzionalità elementari mentre i componenti possono aggregare più moduli per
realizzare funzionalità più complesse e più complete. In generale, l'aggiunta di
un componente corrisponde all'aggiunta di un'intera sezione al sito dove viene
installato. Per esempio, nel caso della gestione di una newsletter i moduli coprono funzioni tipo "iscrizione (aggiunta) di un nuovo utente", "descrizione
(cancellazione) di un utente" eccetera mentre un componente potrebbe gestire
la newsletter nel suo complesso. A loro volta, secondo il medesimo schema modulare, i componenti possono essere usati da applicazioni che coprono livelli di
funzionalità ancora più complessi.
I componenti possono essere realizzati da
qualsiasi utente di Joomla!. In rete si possono inoltre trovare componenti già
pronti, prodotti da sviluppatori indipendenti.
Figura 2:
La schermata di amministrazione di Joomla!.
gestire tutti i Moduli e i Componenti del sito.
12
Da qui è possibile
Per l'impiego di un componente riveste un ruolo fondamentale la versione di
Joomla! per cui esso è stato sviluppato. Infatti, la versione Joomla! 1.0, per
limitazioni intrinseche al framework, pone dei limiti anche alla complessità dei
componenti, limiti che la versione 1.5 ha consentito di superare con l'adozione
del modello MVC (model-view-controller). Un componente sviluppato espressamente per una specica versione di Joomla! viene detto anche "componente
nativo" per quella versione. Fra la versione 1.0 e la versione 1.5 di Joomla! è
supportata solo la compatibilità in avanti dei componenti, ossia è possibile usare
su Joomla! 1.5 componenti originariamente sviluppati per Joomla! 1.0, grazie
anche a un plugin chiamato Legacy Mode.
L'uso di questo plugin può avere
un impatto sul livello di sicurezza e sulle prestazioni dei componenti, tuttavia
ha consentito di evitare la riscrittura di molti componenti nativi. I componenti
nativi per Joomla! 1.5 non supportano la compatibilità all'indietro, non sono
cioè utilizzabili su Joomla! 1.0, a causa dei notevoli cambiamenti al framework
e per il cambio di modello. Si prevede che la versione Joomla! 1.6 supporterà
la compatibilità all'indietro verso Joomla! 1.5.
2.3.5 Moduli
I moduli di Joomla! sono estensioni che permettono l'aggiunta di piccole porzioni
di HTML a un sito realizzato usando Joomla!. Sono usati per mostrare elementi di informazione o funzionalità interattive all'interno di un sito Joomla!, in
maniera collaterale al contenuto principale. Si possono considerare come nestre
aggiuntive attraverso le quali dare informazioni non necessariamente correlate
alla pagina visualizzata, magari per mostrare le altre funzionalità del sito.
I
moduli recuperano le informazioni, o parti di informazioni denite attraverso
parametri, e le visualizzano nella zona di loro competenza; ad esempio il modulo "ultime notizie" recupera di default i soli titoli degli articoli per visualizzarli
nel sito come lista, dando la possibilità di anticipare al visitatore ciò che si trova
all'interno del sito stesso e quali sono le notizie più recenti. All'utente viene data
la possibilità di scegliere quali moduli visualizzare e dove collocarli all'interno
del layout della pagina, in accordo con un template (vedi sotto). Moduli sono
anche i menù di navigazione all'interno di un sito Joomla!.
Agendo diretta-
mente nella sezione Gestione Moduli (Module Manager) dell'amministrazione,
possono essere creati semplici moduli in HTML. Nel caso di script più complessi, essi sono in genere preparati per essere installati con le apposite procedure.
Esistono moltissimi moduli di grande utilità già programmati e pronti all'uso,
messi gratuitamente a disposizione nell'apposita sezione del sito uciale delle
estensioni. Fra i moduli standard si possono segnalare il modulo main menù (il
menù principale), il modulo di login (per l'accesso riservato degli utenti), quello
per i sondaggi (poll) e quello per la distribuzione dei feed RSS (syndicate).
Generalmente, un modulo è composto da un le XML che funge da installer e
che contiene le informazioni sullo sviluppatore dell'estensione e sugli altri le che
lo compongono. È aancato da uno o più le PHP che ne svolgono la funzione
principale, ovvero quella di generare il codice html che verrà poi riproposto sul
sito. È possibile includere le .ini per consentire una più facile localizzazione
del modulo. Tutti i le sopra elencati vengono poi compattati in un archivio di
tipo .tgz o .zip, poi installabile sul CMS.
13
2.3.6 Template
Un template è un documento HTML/CSS che contiene il codice necessario a
guidare Joomla!
e ad impaginare i contenuti:
ad esempio contiene il codice
che permette il caricamento dei vari moduli in posizioni predenite, codice per
caricare il cosiddetto mainbody (la zona in cui vengono presentati i contenuti
principali generati da Joomla!
o dai componenti aggiuntivi) e cosi via.
Per
ottenere l'aspetto desiderato molti template contengono anche una serie di immagini (per gli sfondi, i bordi eccetera).
Ogni template può essere scaricato
da appositi siti gratuitamente o a pagamento ed installato attraverso l'apposita
area admin.
2.3.7 Mambot
I mambot sono nella versione 1.0 l'equivalente dei plugin della versione 1.5x,
quando richiamati, attivano un programma, uno script o eseguono una specica
funzione. Spesso agiscono in background nell'intero sito. Possono essere semplicissimi come la funzione che sostituisce un certo testo digitato con una funzione
codicata (ad esempio posizionare una immagine precaricata impaginandola in
un testo o spezzare in due pagine il contenuto di un lungo articolo), ma possono
anche avere eetti molto più evidenti, come richiamare, all'interno delle nestre
dei form per l'inserimento dei contenuti, le funzionalità di sosticati editor di
testo in modalità WYSIWYG elaborati da terze parti. Possono inoltre permettere collegamenti tra diversi componenti; una galleria di immagini, ad esempio,
può avere un mambot collegato che renda la descrizione delle immagini disponibile alle funzioni di ricerca sul sito. Esistono mambot per inserire funzioni Flash,
per collegare automaticamente un glossario alle parole contenute nei testi degli
articoli, per generare miniature delle immagini inserite nei testi in modo che
alla selezione appaia una nestra con l'immagine a maggiore risoluzione, e molti
altri.
2.4
Drupal
Drupal è un content management system (CMS) modulare scritto in linguaggio
PHP e distribuito sotto licenza GNU GPL. Drupal funziona su diversi sistemi operativi, tra cui Windows, Mac OS X, Linux e qualsiasi piattaforma che
supporti i web server Apache e il linguaggio PHP. Drupal utilizza inoltre un
database per memorizzare i contenuti, e necessita dunque di un software come
MySQL e PostgreSQL che sono gli unici DBMS al momento supportati.
2.4.1 Storia
Creato originariamente da Dries Buytaert come bulletin board system, divenne
un progetto libero nel 2001. Il nome Drupal è la traslitterazione inglese per la
parola olandese druppel che signica goccia. Il nome nasce dal defunto drop.org,
sito il cui codice si evolse lentamente no a trasformarsi in Drupal. Buytaert
voleva chiamare il sito dorp (In olandese villaggio, riferendosi all'orientamento per community del progetto), ma commise un errore di digitazione quando
controllò la disponibilità del dominio.
Rileggendo, decise che drupal suonava
meglio. Negli anni Drupal ha acquistato popolarità. Da maggio 2006 ad aprile
2007, Drupal è stato scaricato più di 600.000 volte. Ora lo sviluppo di Drupal
14
gode dell'apporto di una grande comunità. Dal novembre 2009 il sito della Casa
Bianca WhiteHouse.gov utilizza Drupal.
2.4.2 Struttura
Una volta installato sulla macchina, drupal presenta una home page come
quella mostrata nella gura sottostante.
Figura 3: Home Page di una Installazione di default di Drupal
La pagina mette a disposizione 4 servizi principali:
Accedere alla sezione di Amministrazione, dove è possibile gestire tutte le
regole per qualsiasi contenuto o modulo del sito
Figura 4: Sezione di amministrazione, da qui è possibile raggiungere qualsiasi
impostazione del sito.
15
Accedere alla sezione di gestione dei Moduli, dove è possibile abilitarli/disabilitarli oppure scaricarne di nuovi .
Figura 5: Sezione di Gestione dei Moduli.
Gestire la parte di Design Graco tramite la sezione Temi.
Figura 6: Parte di Gestione dell'aspetto graco del sito.
16
Inserire un nuovo contenuto informativo all'interno del nostro sito.
Figura 7:
Creazione di contenuto in Drupal tramite i contenitori di Default
(Pagina e Storia)
Drupal, per essere usato correttamente, richiede l'apprendimento del concetto
fondamentale di funzionamento: in Drupal tutto ruota ai Moduli e ai
Contenuti ; il Data Base è secondario poiché viene gestito automaticamente da
Drupal( Non è assolutamente necessario conoscere SQL). Vedremo nelle sezioni
successive l'approfondimento di questi concetti.
17
2.4.3 I Moduli
I Moduli sono dei plugin aggiuntivi che estendono le funzionalità predenite di
drupal.
Appena installato Drupal contiene veramente poco di utile quindi, è
necessario, portarsi subito alla pagina di download dei componenti aggiuntivi,
dove, oltre all'elenco dei moduli più scaricati, esiste un veloce e comodo motore
di ricerca, che ci porta subito all'argomento desiderato.
Come Funzionano?
I Moduli sono dei pacchetti di codice Php che eseguono
diverse funzionalità. Drupal è comandato da un processo core chiamato cron,
questo processo è stato progettato con un sistema di hook (ganci) o callback,
che permettono ai moduli sviluppati dalla comunità di inserire funzioni nel processo di esecuzione di Drupal. I moduli, così gestiti, non creano pericoli, poiché
non hanno il pieno controllo del core.
Come si Installano?
I Moduli scaricati vengono salvati sulla propria macchi-
na come archivi (.tar.gz); una volta scompattato, la directory risultante va posizionata della directory di Drupal nella sotto cartella chiamata /modules. A
questo punto basta comandare un refresh al web server(in modo che carichi i
nuovi le), posizionarsi nella sezione di amministrazione dei moduli e con un
semplice click abilitare il modulo che abbiamo appena scaricato ed importato
all'interno di drupal.
Ostacoli?
Ci sono due possibili ostacoli che si possono presentare durante
l'installazione di un modulo:
1. Il modulo non è compatibile con la versione di Drupal installata.
> Ritornare sul sito e cercare la versione compatibile, altrimenti abbandonare il modulo e cercarne un altro che svolga lo stesso compito ma che
sia aggiornato.
2. Nel caso stessimo per attivare un modulo, come è ragurato nella gura
seguente, può capitare che il modulo abbia delle dipendenze.
A questo
punto è necessario scaricare ed attivare il/i modulo/i richiesto/i dal modulo di partenza per poter continuare il processo di attivazione. Questo può
risultare scomodo e poco eciente poiché all'aumentare delle dimensioni
del sito, aumentano i moduli utilizzati e quindi anche i moduli passivi
(quelli richiesti come dipendenza). Tutto ciò può portare confusione all'interno della pagina di amministrazione dei moduli e anche al calo di
prestazioni del web server.
18
Figura 8: Dipendenza nel modulo Node Import, richiede infatti Date API e
Advanced Help
Vantaggi
Un modulo, rilasciato da poco, integrato totalmente nel core di
Drupal chiamato update_status notica automaticamente il gestore del sito
quando vengono rilasciate nuove versioni dei moduli e temi installati. Questo
evita un lavoro manuale di ricerca periodica di aggiornamento assai lungo e
tedioso.
Inoltre la comunità di Drupal ha sviluppato moduli per:
Sistemi e-commerce ;
Flusso di lavoro redazionale;
Gallerie fotograche ;
Gruppi autogestiti ;
Sitemap di Google ;
Gestione di mailing list ;
Integrazione con CVS ;
Gestire immagine e video ;
19
Gestire servizi di terze parti (Adsense, AuctionAds, Technorati, etc.);
Aggiungere funzionalità Javascript ed Ajax
2.4.4 Contenuti
Il Contenuto in Drupal è esattamente ciò che esprime la parola stessa.
Nel
caso di un blog saranno post, nel caso di un sito vetrina saranno le notizie,
la presentazione dell'attività, ecc. A livello di amministrazione, in Drupal, non
si deniscono i Contenuti ma i Contenitori, cioè le strutture che andranno a
contenere i contenuti. Se si vuole far una paragone con la programmazione a
oggetti, i Contenuti sono istanze di classi Contenitori. Di default in drupal ci
sono due tipi di contenitori:
Pagina : Una pagina (page), simile come struttura a una story, è un metodo semplice per creare e mostrare informazioni che raramente vengono
cambiate, tipo una sezione Chi siamo di un sito web. Come impostazione
predenita, una pagina non prevede commenti dei visitatori e non viene
mostrata nella home page iniziale del sito.
Storia : Una storia, simile come struttura a una pagina, è ideale per creare
e mostrare contenuti che coinvolgano o informino i visitatori. Comunicati
stampa, annunci ed altri contenuti simili al blog possono essere creati con
la voce storia. Come impostazione predenita, una storia viene automaticamente mostrata sulla pagina principale del sito ed è possibile aggiungervi
commenti.
Come balza all'occhio questi due tipi di contenuti sono molto scarni e permettono poco rispetto a quello che si può fare con del codice HTML+ SCRIPT. Per
questa motivazione la comunità di Drupal ha messo a punto e poi pubblicato un
modulo chiamato CCK (Content Construction Kit). Questo modulo si integra
nella sezione Tipi di Contenuto e permette appunto la creazione di Content
type customizzati. Una volta terminata la procedura di creazione di un nuovo
Content Type, Drupal creerà due tabelle nel proprio Database; in una ci sarà
l'elenco dei campi inseriti, nell'altra invece ci saranno i dati veri e propri codicati secondo le politiche di Drupal per non renderli in chiaro. Si Rimanda alla
sezione Prove Energy-CHIT per un esempio pratico di creazione di un Custom
Content Type.
20
2.4.5 Viste
Fino a questo punto abbiamo visto come interagire con Drupal per elaborare
procedure(Moduli) e per immagazzinare Dati (Contenuti). Per completare un
completo processo di pubblicazione di contenuti su web manca all'appello una
procedura per visualizzare i dati contenuti nel database oppure i risultati di
una elaborazione. Per questa necessità sono state sviluppate le Viste che sono
niente meno che delle Query SQL sul database. Per rimanere nei preconcetti
di un CMS (Chiunque può sviluppare siti web), le viste non chiedono assolutamente comandi SQL, ma propongono all'amministratore una semplice ed
intuitiva interfaccia graca. Grazie ad un wizard, con pochi passi, si possono
recuperare tutte le informazioni necessari. L'unico limite è che si possono interrogare tabelle di cui si è i proprietari, cioè tabelle che derivano dalla creazione
di un Custom Content Type oppure che derivino da strutture dati standard; le
tabelle private di Drupal non si possono interrogare per ovvi motivi di sicurezza
interna. Per un esempio pratico di creazione di viste in Drupal si rimanda anche
in questo caso alla sezione Prove Energy-CHIT.
21
3
Import/Export in Drupal
I moduli sono importanti per un CMS come lo è il carburante per un motore
a scoppio; senza di essi il CMS non ha funzionalità e quindi non ha ragione di
esistere. Nel mio elaborato ho arontato la categoria di moduli più critica: la
fase di Import / Export.
Questa categoria è stata classicata critica poiché il CMS, attraverso i moduli opportuni, deve riuscire ad interagire con componenti a lui estranei, scritti in
altri linguaggi e dagli scopi più vari . La comunità di Drupal ha sviluppato nel
corso nel tempo, e sta ancora sviluppando, una quantità notevole di moduli per
garantire l'integrazione in Drupal. Uno dei fattori più interessanti è che, nella
comunità degli sviluppatori, esiste uno spirito di collaborazione elevatissimo;
quando parte un progetto per un nuovo modulo, la partecipazione è altissima,
sia che sia un progetto utile a pochi sia che sia uno nuovo che possa aiutare
numerose persone. Nella mia analisi ho estratto un insieme ridotto di moduli
giudicati signicativi per far comprendere in maniera pratica le potenzialità di
uno dei migliori CMS esistenti.
Per rendere più facile la comprensione di ogni singolo modulo, questa sezione
verrà divisa in tante sottosezioni quanti sono i moduli; ogni sottosezione conterrà
un modulo descritto nelle sue caratteristiche.
3.1
Backup and Migrate
Backup and Migrate semplica l'attività di backup e di ripristino del database
di Drupal, permette inoltre di spostare il database da un sito in Drupal ad un
altro. Supporta i formati di compressione bzip,gzip,zip e permette di eettuare
backup programmati.
Caratteristiche:
Backup e ripristino di più database alla volta
Upload del backup su server FTP/email
Programmazioni di backup multiple su più database
Crittograa AES per i backup
22
Figura 9: Operazione di Backup sul database selezionato
Come si può vedere dall'immagine sopra l'operazione di backup è accompagnata da quella di restore. Inoltre è possibile scegliere la destinazione del le
di backup e chi può eettuare tali operazione. L'ultima caratteristica permette
invece di eettuare backup programmati.
Il Modulo funziona perfettamente, ogni sua caratteristica raggiunge il suo
scopo. Ovviamente all'aumentare delle dimensioni del database l'operazione di
backup/restore sarà più lunga ma porta comunque ad un risultato certo.
Il
Modulo è funzionante sulla versione stabile di Drupal ed è in fase alfa per la
nuova versione 7 di Drupal che è ancora in fase di sviluppo.
3.2
Printer, e-mail and PDF versions
Il Modulo permette di esportare ogni nodo del sito in 3 formati diversi:
In un formato web, come una pagina internet salvata in locale;
In formato PDF;
Come un link web spedibile via e-mail (viene mandato il link completo del
sito per la visualizzazione del nodo).
23
Figura 10: La gura mostra il modulo installato e pronto all'uso.
Oltre alla possibilità di eseguire uno dei 3 export esiste un ulteriore tab
che permette di gestire le Impostazioni; è possibile impostare un foglio di stile
CSS per impaginare e presentare l'export, gestire il formato degli url inviati
ed abilitare javascript per la visualizzazione della pagina (nel caso fosse necessario).Viene richiesto inoltre, per la fase di esportazione in pdf, di indicare un
software di generazione di PDF installato sulla macchina poiché il servizio non
è integrato nel modulo.
Il Modulo non è particolarmente articolato ma molto utile nel caso in cui
si voglia esportare i contenuti del proprio sito (presentazioni, condivisione del
proprio lavoro nel team di sviluppo, ecc ). Potrebbe essere arricchito inserendo
nuovi formati di export come CSV ed XML ma esistono già altri moduli che
permettono questa cosa.
24
3.3
User Import
La scopo del modulo consiste nell'importare nel sito utenti tramite un le CSV
(Comma Separated Value).
L'operazione di import permette di aggiungere
nuovi utenti oppure di aggiornare quelli esistenti.
In Drupal gli utenti sono
nodi con una struttura di default inseriti in una tabella privata del database.
Figura 11: Lo User Import è formato da 3 sezioni, in questa gura viene mostrata
la principale: L'import da CSV.
Una prima sezione mostra tutte le importazioni no ad ora eettuate, la
seconda, che è la principale, permette di importare un CSV contenente la lista
degli user; una terza permette di settare due parametri:
il numero massimo
di user importabili per volta e il numero massimo di utenti contenuti in un
singolo le.
Sono due parametri legati alle prestazioni; il primo concerne il
fatto che quando un utente viene importato riceve una e-mail di notica che
informa dell'avvenuta registrazione al sito, il secondo invece riguarda solo il
fattore busy della macchina che è impegnata nell'importazione.
Il Modulo viene usato per Import di grosse moli di utenti, evita infatti l'inserimento manuale tramite il form di amministrazione del sito. Molto utile per
la migrazione della tabella utenti da un database all'altro.
Per una corretta
operazione di Import è necessario che il le CSV sia sintatticamente corretto (ogni dato separato da virgole , ogni tupla separata da un carattere di a
capo). Come si può intuire esiste il modulo inverso che permette lo User Export, chiamato Prole CSV. Questo modulo è praticamente uguale all'import,
dierisce ovviamente nella direzione dei dati.
25
3.4
Taxonomy import/export via XML
Questo modulo permette di importare ed esportare vocabolari e termini tassonomici tramite XML, CSV, RDF e altri formati.
Il modulo ha una dipen-
denza verso il pacchetto Taxonomy che è installato da drupal di default. Per
questo motivo l'interfaccia per l'import/export via XML viene integrato nella
sottosezione Taxonomy che è già presente nella pagina di amministrazione del
sito. Il modulo 'taxonomy' permette di suddividere in categorie i contenuti utilizzando sia tag inseriti dall'utente, sia categorie denite dall'amministratore.
E' uno strumento potente per classicare i contenuti, con molte funzionalità
avanzate.
Figura
12:
Modulo
aggiuntivo
per
l'esistente
'Taxonomy'
che
permette
l'import/export di vocaboli/vocabolari tassonomici via XML
Tutt'ora lo sviluppo di questo modulo è molto attivo, poiché la tassonomia
rappresenta uno dei punti forti di un sistema Cms; gli sviluppatori stanno cercando di aggiungere al modulo la funzionalità di supporto remoto così da poter
ricevere via web intere librerie di termini. Un ulteriore idea di sviluppo sarebbe
che ogni sito Drupal diventi un server tassonomico per rendere il le sharing
di vocabolari e termini più aperto è decentralizzato.
Dalle molte prospettive
future presenti, il modulo sarà nelle versioni future uno dei must to have per
un amministratore di Drupal. Il modulo è stabile e funzionante nella versione
corrente di Drupal mentre non si hanno aggiornamenti sullo sviluppo per la
nuova release di Drupal
26
3.5
Taxonomy CSV import/export
Questo modulo non è un overriding di quello precedente, bensì è un'alternativa.
Quando si desidera importare un vocabolario, una tassonomia o una semplice
lista di termini nel sito Drupal, si hanno due scelte principali: taxonomy_xml
o taxonomy_csv.
Taxonomy_xml è perfetto per importare tassonomie e vocabolari standardizzati, nonostante il nome è possibile importare/esportare anche le CSV ma
formattati secondo il formato ISO 2788.
In alternativa se si vuole importare
vecchi vocabolari e termini non standardizzati è necessario utilizzare Taxonomy_csv. Una volta importato il necessario è possibile esportare i contenuti utilizzando tranquillamente taxonomy_xml, infatti anche taxonomy_csv si integra
perfettamente nel modulo standard 'Taxonomy'.
Figura 13: Taxonomy CSV import/export si integra nel modulo di default 'Taxonomy', esso a dierenza del taxonomy_xml permette di gestire una serie di
parametri per l'import di tassonomia non standardizzata
Tramite un veloce ed intuitivo form da compilare è possibile importare qualsiasi tipo di tassonomia è standardizzarla per renderla utilizzabile secondo i
formati già esistenti. Il modulo oltre a funzionare perfettamente è già in Beta
anche per la prossima versione di Drupal.
27
3.6
Views Datasource
Views Datasource è un set di plugin per le viste in Drupal, esso permette di
esportare i contenuti delle viste in un certo numero di formati condivisibili basati
su XML,JSON e HTML. Questi tipi di formati permettono l'accesso ai dati delle
viste da parte di client web alla ricerca di semantica.
Il modulo è formato da 4 plugin per le Viste:
1. views_xml - Output come righe XML, OPML, e Atom;
2. views_json - Output come JSON, JSONP/JSON come script;
3. views_rdf- Output come FOAF, SIOC, e DOAP;
4. views_xhtml - Output come hCard, hCalendar, e Geo.
Per essere installati questi plugin richiedono come dipendenza il Modulo 'Views'
che serve appunto per creare Viste. Il Modulo purtroppo è in fase beta e non
funziona, le impostazioni per settare l'esportazione non vengono visualizzate all'interno della sezione Viste e quindi non è possibile testare i plugin. Nonostante
il bug questo progetto ha buone potenzialità se portato a termine con successo
poichè può rendere accessibili i contenuti a numerosi web service anche se essi
lavorano con formati di dato diversi.
3.7
Custom Reports
Custom Reports è stato creato per permettere al client collegato al sito Drupal
di scaricare dati dal database, questo è permesso tramite delle Custom Views.
Questo modulo è stato creato principalmente per gli sviluppatori. Il modulo va
a completare le viste per quanto riguarda le interrogazioni al database; questo
perché il wizard delle viste permette di eettuare solo query semplici. Il Modulo
è stato creato per due semplici ma importanti scopi:
Accedere a tabelle che non sono accessibili tramite le 'Viste' (Il modulo
viste non permette le interrogazioni su tabelle private di Drupal);
Permettere la creazione e l'esecuzione di Query SQL Complesse;
28
Figura 14: La schermata per la creazione di un Custom Report
Il Modulo funziona nel seguente modo:
Usa un esistente custom content type, o ne crea uno nuovo nel caso fosse
necessario;
Si crea un custom report node (Tramite l'interfaccia), gli si da un nome e
si incolla nella text area il codice SQL precedentemente creato;
Si accede alla tabella utenti e si danno i permessi per visualizzare il report;
Gli utenti quando visiteranno la pagine del report potranno scegliere il
formato di export ( di default sono abilitati CSV e XML ma si possono
inserire altri tipi).
Custom report è di massima utilità, capita spesso di dover creare interrogazioni
abbastanza complesse e data la lacuna delle viste è stato necessario sviluppare
questo modulo.
Non presenta problemi di funzionamento ed è stabile per la versione corrente. L'unico problema è che per utilizzare queste custom views è necessario
conoscere il linguaggio SQL e come i database funzionano; questo va un po'
contro la natura dei CMS ma purtroppo altre soluzioni per questa necessità al
momento non esistono.
29
3.8
Views Importer
View Importer permette di importare viste precedentemente esportate in maniera
davvero semplice. Questo modulo si comporta come una sorta di plugin per
il modulo Viste aggiungendo nell'interfaccia dell'ultimo una 'tab' che gestisce
l'import.
Figura 15: L'import di viste viene integrato nel modulo 'Viste'
Questo modulo permette l'import in due modi dierenti:
1. Tramite la sezione di amministrazione delle viste, dove si inserisce il titolo
e il codice della vista precedentemente esportata.
2. Il modulo nel suo path di installazione dentro drupal possiede una cartella
chiamata import, nella quale è possibile inserire le di testo contenenti il
codice delle viste esportate; quando si va ad attivare il modulo da Drupal
esso viene installato e con esso vengono anche importate le viste contenute
nella cartella. Questo è un modo veloce nel caso si hanno un set notevole
di viste da importare.
Il modulo è utile nel caso di migrazione parziale o totale del sito, nel caso
di clonazione su diverse macchine di sezioni vitali del sito che non possono
subire inoperatività. L'operazione di export delle viste non è stata implementata in un modulo specico ma è integrata direttamente nel modulo 'viste'
come funzione per le views esistenti; la funzione permette di copiare ed incollare in un le di testo il codice della vista visualizzato all'interno di una pagina
nell'amministrazione delle viste.
30
3.9
Save To FTP
Il Modulo permette di salvare il contenuto di un nodo su un server FTP, in formato .html, esso inserisce inoltre eventuali le aggiuntivi necessari al nodo(fogli
di stili CSS, js, immagini).
Figura 16: Il Modulo Save To FTP pronto per essere utilizzato
Il modulo nella fase iniziale prevede di poter inserire in formato HTML
informazioni nell'header, prima e alla ne del body.
Inne si inseriscono le
informazioni del server FTP come riportato nella gura sotto.
Figura 17: Fase di inserimento dei dati del server FTP, spesso è la medesima
macchina dove viene hostato il sito.
31
I Principali utilizzi sono i seguenti:
esportazione delle pagine statiche e dinamiche;
tenere lo storico del cambiamento delle pagine nel corso del tempo;
condividere il proprio lavoro con chi lo necessità in un modo rapido e senza
perdere dati.
L'utilità è ristretta al solo fatto di poter caricare nodi su FTP, se non si trova
un'applicazione di questo modulo all'interno del proprio sito web è piuttosto
inutile. Usarlo invece è davvero semplice ed in pochi passaggi si è in grado di
caricare del contenuto su FTP.
32
3.10
Node Table
NodeTable è un modulo per la gestione di tabelle HTML in siti Drupal.
Il
modulo fornisce funzionalità per la creazione, il caricamento, la modica e la
presentazione di tabelle HTML all'interno di nodi o come nodi.
Figura 18: Il modulo inserisce un nuovo content type usufruibile per la gestione
di tabelle HTML
Crea un nuovo content type e lo inserisce assieme a quelli di default (Storia e
Pagina) fornendo all'amministratore un considerevole numero di funzioni, quali:
Inserire tabelle HTML all'interno del nodo bloccandone il contenuto attraverso dei ltri;
Generazione automatica di markup HTML relativo alla tabella;
Inserimento di tabelle nel 'nodetable' tramite le CSV;
Esportazione delle tabelle in formato CSV;
Creazione manuale di 'nodetable' all'interno del menù di amministrazione
dei contenuti;
Generazione automatica degli Headers HTML;
Permette l'ordinamento di una o più colonne in modo essibile (asc/desc
,tramite altri ltri di default o condizioni customizzate);
Permette la creazione, la modica o la cancellazione di una qualsiasi riga
o colonna della tabella;
Permette il riordinamento delle righe tramite drag and drop (funziona solo
se non ci sono ltri applicati sulle colonne);
33
Inserisce automaticamente un ID identicativo per ogni tabella inserita e
per eventualmente anche per ogni riga della tabella;
Permette l'inserimento di codice HTML per ogni singola cella della tabella,
per applicare stili di formattazione, di visualizzazione etc.
Possiede una robusta struttura di permessi che controlla le operazioni sulle
tabelle (aggiungi/modica/cancella);
Il Modulo purtroppo è in fase 'alpha' e non tutte queste caratteristiche funzionano perfettamente; inoltre il modulo si avvale di alcuni script Javascript
per l'ordinamento e per l'import/export dei csv, quindi l'esecuzione risulta più
lenta e laboriosa rispetto alle altre operazioni. Tuttavia l'importanza di questo
modulo è innegabile poiché le tabelle sono ovunque sul web. Da sottolineare la
procedura di import/export di tabelle tramite CSV, utile nel caso di integrazione
di un sito web costruito 'normalmente' in uno realizzato tramite Drupal.
34
3.11
CCK Importer
CCK Importer permette di importare nel proprio sito Drupal custom content
type precedentemente esportati.
La funzione si va ad integrare nella sezione
d'amministrazione tipi di contenuto e si identica tramite l'aggiunta di una
tab 'Importa' nel menù di navigazione.
Figura 19: La funzione 'Importa' per i Custom Content Type
L'utilizzo è semplicissimo, si può specicare il tipo dei campi da importare
oppure crearne uno nuovo se non esiste uno uguale già creato; inne si incolla
nella text area il codice precedentemente esportato. A questo punto nella sezione
tipi di contenuto si ha il nuovo tipo appena importato. Il Modulo è davvero
utile nella migrazione di database che utilizzano custom content type(CCT),
infatti evita di dover re-impostare i nuovi tipi sul nuovo DB. Una eventuale
miglioria nel modulo potrebbe permettere l'importazione multipla di CCT.
3.12
Views Node Feed
Il modulo permette di creare dei feed per le viste create, inoltre è possibile
specicare un qualsiasi codice di markup (JSON,XML,ecc.)
invece dell'RSS.
L'obbiettivo del modulo è quello di rendere disponibile i contenuti del sito a cui
è applicato tramite dei feed; in questo modo l'utente utilizzatore del sito può
tenersi aggiornato sui contenuti sottoscrivendosi ai feed che l'amministratore
del sito rende disponibili.
Purtroppo il modulo è compatibile con la vecchia
versione di Drupal e non è stato possibile testarlo. Nonostante l'impossibilità
di testare il modulo, la scopo del progetto è molto rilevante. I Feed sono oggigiorno usati su larga scala portando numerosi beneci, un amministratore di
un sito web costruito tramite Drupal dovrebbe avere la possibilità di usare tale
tecnologia per mettere in luce il proprio portale. Il team di sviluppo non ha rilasciato dichiarazioni relative ad un eventuale implementazione del modulo per
la versione corrente o per quella futura di Drupal.
35
Figura 20: Views Node Feed non è compatibile con la versione attuale di Drupal
3.13
Joomla To Drupal
Joomla to Drupal permette la migrazione di un sito web sviluppato in Joomla
verso uno creato in Drupal.
Figura
21:
Il
modulo
richiede
di
congurare
all'operazione di migrazione
36
alcuni
parametri
necessari
Figura 22: Le opzioni congurabili non sono poche e permettono una migrazione
accurata
Il modulo permette di spostare i contenuti di maggior rilevanza quali:
La tabella utenti
Sezioni e categorie, essi vengono tramutati in vocabolari tassonomici o
termini.
I 'Content Items' di Joomla vengono tramutati in nodi leggibili da Drupal.
Oltre a spuntare quali elementi si vuol importare l'interfaccia di congurazione
del modulo chiede inoltre di impostare:
Se aggiornare eventuali elementi già importati prima;
I parametri di Joomla quali:
L'indirizzo del server Joomla;
Il Nome del database Joomla;
Username e Password dell'account di amministrazione del database
Joomla;
Un eventuale path della cartella Home del sito Joomla( nel caso in
cui non si trovi nella /public).
Ulteriori parametri riguardanti i tipi di Content, il formato di Input e le
impostazini di Import.
Il Modulo è ancora in fase Alpha e quindi non è molto stabile, infatti casualmente il processo di import si interrompe inaspettatamente. Tuttavia il modulo
propone grandi vantaggi nella prospettiva di migrazione da Joomla a Drupal.
Sarebbe ulteriormente vantaggioso se fossero implementati altri moduli per la
migrazione da e verso i maggiori CMS tutt'ora presenti, per realizzare ciò è
assolutamente necessaria la collaborazione degli sviluppatori di ogni CMS.
37
4
Prove con il portale Energy CH-IT
4.1
Cos'è l'Energy CH-IT
L'energy CH-IT è un progetto per il risparmio energetico nelle aziende tra la
provincia di Como, Varese ed il canton Ticino. E' questo il progetto, nanziato nell'ambito del Programma di cooperazione Italia-Svizzera 2007-2013, che
la Camera di Commercio di Como sta avviando in collaborazione con Politecnico Milano, Fondazione Politecnico, Api Servizi Varese, Centro Tessile Cotoniero e Abbigliamento e la SUPSI (Scuola Universitaria Professionale della
Svizzera Italiana). Il progetto ore gratuitamente alle aziende presenti sul territorio delle diagnosi sui consumi termici ed elettrici per far emergere eventuali aree di inecienza ed identicare i possibili interventi di risparmio energetico realizzabili.
Il Progetto è stato portato anche sul web all'indirizzo
http://www.energychit.com/.
Il sito web è stato realizzato con le tecniche comuni di programmazione web
e, proprio per questo motivo, è stato scelto come cavia per arontare la migrazione verso un CMS. Il 'cuore' del portale consiste in un database contenente
tutte le informazioni delle aziende che si sono iscritte al progetto; il 'goal' del
mio lavoro è stato quello di riuscire ad importare il database del sito nel CMS
Drupal per testare il funzionamento dell'importazione.
Prima di arontare il tema principale appena descritto è meglio analizzare
gli strumenti che sono stati utilizzati per realizzare il test.
4.2
Moduli per l'import di database in Drupal
Per realizzare l'import di database nel CMS Drupal è stata fatta un'analisi dei
moduli che la comunità di sviluppatori ha realizzato per arontare questo tipo di
problema. La scelta dei moduli da poter utilizzare è stata inoltre condizionata
dal formato dei dati che devono essere importati; dopo una serie di colloqui
con gli amministratori del portale si è concluso che il formato reso disponibile
fosse quello .xls (Microsoft Excel).
Nell'insieme dei moduli disponibili nella
comunità, moduli per la gestione diretta di le .xls non esistono, sono disponibili
però alcuni strumenti per la gestione di le .csv. Con una semplice conversione
tramite comunissimi software è possibile ottenere le .csv da .xls.
I moduli trovati per eettuare l'import di le .csv sono 2:
Sheetnode
Node Import
Necessaria l'analisi dettagliata di questi due moduli che rappresentano il mezzo
per arrivare allo scopo pressato.
38
4.2.1 Modulo Sheetnode
Sheetnode è uno dei moduli più complessi presenti fra quelli disponibili. Esso
infatti, a dierenza di quasi tutti gli altri moduli di Drupal, non è un 'semplice'
modulo scritto solo in php ma necessità di eseguire contenuti Java. Per questo
motivo Sheetnode, al momento dell'installazione, necessita di una serie non banale di passaggi di congurazione.
Questo alto livello di dicoltà è dato dal
fatto che il modulo una volta installato presenta un'interfaccia simile a un foglio
di calcolo permettendo diverse funzioni quali:
Creare nodi, ogni nodo è un foglio di calcolo completo comprendente
formule e formattazione delle celle;
Riferimenti incrociati tra celle di nodi diversi;
Integrazione completa con il motore di ricerca interno di Drupal (per
cercare contenuti all'interno delle celle);
Funzione che richiede java);
Import/Export di le .xls (
Esportazione diretta in formati OpenOce;
Importazione di fogli di calcolo da Google Docs;
Creazione di viste che riportano i risultati direttamente in fogli di calcolo,
visualizzando correttamente formule utilizzabili ed eventuali graci;
Esportazione delle viste create in formati compatibili con Excel/OpenOce
e GoogleDocs.
39
Figura 23: Esempio di nodo visualizzato come foglio di calcolo
40
Il modulo, come illustrato in gura sotto, richiede per funzionare
correttamente l'installazione di un
PHP/JAVA Brigde.
Nonostante che il
modulo non sia totalmente dipende da codice Java, per sfruttare le
funzionalità più interessanti necessita di tale caratteristica. Questo ponte,
come si può intuire, permette la comunicazione tra il modulo (in php) e le
classi (in java) che servono per gestire le varie funzioni del foglio di calcolo e il
foglio di calcolo stesso.
Figura 24: Dipendenza da PHP/JAVA Bridge richiesta da SheetNode per poter
funzionare in tutte le sue funzionalità
Questo 'Ponte' risulta il punto cruciale per il funzionamento generale del
modulo. All'interno della pagina del modulo, sul sito web di Drupal, esiste una
guida creata dagli sviluppatori per installare correttamente il bridge;
purtroppo questa guida è molto generica e la buona riuscita dell'installazione
non è assicurata. In denitiva l'utilizzo del modulo SheetNode è stato
abbandonato per una serie di motivi:
Non è stato possibile installare il bridge perché la nuova versione non è
compatibile con la versione attuale del modulo sheetnode (gli sviluppatori dei due componenti sono diversi e a quanto pare non sono per nulla
allineati); tutt'ora non si hanno notizie riguardo ad aggiornamenti nel
modulo.
L'unica soluzione sarebbe quella di reperire in rete la versione
precedente del bridge, ma purtroppo la ricerca non ha dato esito positivo.
Anche se i vari tentavi avessero portato ad un risultato concreto non
sarebbe stato possibile usare questo modulo poiché alcuni vincoli sulla
macchina ospitante il sito Drupal impossibilitano l'esecuzione di codice
Java (questo è stato scoperto in seguito ed ha comportato l'inutilità di
alcuni giorni di lavoro).
Avendo lavorato molto con questo modulo posso concludere che, se l'installazione
avesse avuto buon esito e che la macchina ospitante fosse libera da vincoli, il
41
modulo possiede alte potenzialità per una gestione completa ed user friendly
di fogli di calcolo proprio come avviene sui comuni software.
4.2.2 Node Import
Node Import permette di importare dati da un un le .CSV(Comma Separated
Value) o .TSV (Tab Separated Value). Come vincolo unico richiede che i le
siano formattati secondo la codica UTF-8. Per essere abilitato inoltre il modulo
richiede due dipendenze:
verso il modulo 'advanced help' che fornisce una specie di help per l'uso
di alcuni moduli;
verso il modulo 'date API' che, anch'esso per una serie di moduli, controlla
il usso temporale delle operazioni.
Il modulo, rispetto al SheetNode, è molto più semplice da usare; si integra nella
pagina di amministrazione di Drupal inserendo la voce 'Import Content'. Esso
è composto da 3 sezioni principali:
1. Una sezione 'Elenco', dove viene elencato uno storico degli import eettuati;
2. La sezione principale 'New Import', che permette di inizializzare una nuova
importazione;
3. Una sezione 'Impostazioni', dove è possibile eettuare alcuni setting quali:
(a) La cartella dove posizionare i le da importare;
(b) La possibilità di fare l'upload dei le da importare sul server FTP
(questa opzione serve per caricare le da remoto);
(c) Le estensioni dei le accettate dal modulo; (solo estensioni di le di
testo).
Figura 25: Sezione di Impostazioni del modulo Node Import
42
La fase di 'New Import', che è il cuore del modulo, verrà analizzata nel
dettaglio nella pagine a seguire dove verranno descritte le prove eettuate con i
vari moduli per raggiungere lo scopo di questa tesi, la migrazione del database.
4.3
Creazione di un nuovo content type tramite il modulo
CCK
Il modulo Node Import, per essere utilizzato, richiede in una delle prime fasi
dell'importazione di specicare il tipo di contenuto che esso andrà ad importare.
Per questo motivo prima di iniziare l'operazione di Import è necessario creare un
nuovo 'tipo di dato' sfruttando il modulo ad hoc CCK (Content Construction
Kit). Il modulo si integra nella sezione d'amministrazione 'Tipi di contenuto' e,
la sua corretta installazione, è identicabile tramite il tab 'Aggiungi nuovo tipo
di contenuto'.
Figura 26: Fase iniziale della creazione di un Custom Content Type
Dopo una serie abbastanza intuitiva di parametri da impostare, nell'elenco dei
Content Type, verrà mostrato il nuovo tipo di dato appena creato. Il passo
successivo consiste nel modica dei campi del nuovo tipo di dato azionando il
comando 'manage eld' posto alla ne della riga di ogni content type. La
pagina mostrata permette 3 azioni sui campi del content type:
Creare un nuovo campo;
Cancellare un campo esistente;
Modicare l'ordine dei campi;
Creare un gruppo di campi, cioè indicare a Drupal che un certo numero di campi sono relativi ad un medesimo concetto.
Per esempio il
numero di telefono dell'azienda e il numero di cellulare del responsabile
sono raggruppati nel gruppo numero di telefono
43
Figura 27:
L'operazione di creazione di un nuovo campo chiede inizialmente
alcune informazioni basilari.
A questo punto è possibile inserire tutti i campi necessari per il proprio
Custom Content Type. Nel caso del portale Energy CHIT la tabella utenti è
così fatta:
Figura 28: Campi della tabella Utenti Energy CH-IT
Con una buona dose di pazienza si inseriscono tutti i campi in Drupal
impostando per ogni campo i parametri richiesti e quelli opzionali a seconda
del caso; fra i più rilevanti:
Il tipo primitivo del dato (testo, intero, binario, oat.. cc);
Il tipo di Input Field (Casella di testo, Checkbox,Text Area,ecc);
La lunghezza massima dell'input;
L'opzione not null, praticamente un campo obbligatorio.
Alla ne della procedura si ottiene una schermata come in gura sotto.
44
Figura 29: Elenco dei campi al termine della procedura di inserimento
Come si può notare i campi sono stati ordinati come da prototipo della
tabella. L'unico vincolo che pone il modulo CCK è che venga inserito
obbligatoriamente il campo di default 'Titolo', esso viene utilizzato come
chiave primaria per ogni tupla della tabella. Se non è già presente nel le .xls
da importare basta semplicemente aggiungere una colonna in testa al le,
nominarla 'Titolo' e inserire come valori numeri interi incrementati di uno
partendo da zero. A questo punto l'operazione di creazione di un Custom
Content Type è terminata e si può procedere all'utilizzo del modulo 'Node
Import'.
4.4
Modulo Node Import, utilizzo pratico
Come già detto nella sottosezione 4.2.2, si accede alla schermata del modulo e
ci si posiziona nel tab 'New Import' per iniziare l'operazione di Import. L'operazione è stata realizzata mediante un wizard di otto passi in cui si andranno
a congurare tutte le opzioni per ottenere il risultato voluto.
Analizzeremo
in questa sezione tutti gli 8 passi anche se alcuni sono piuttosto immediati da
svolgere.
4.4.1 Passo 1: Selezione del Content Type
In questo primo 'step' viene richiesto di indicare il tipo di dato compatibile con
i dati da importare, nel nostro caso l' EnergyCHITUsers appena creato.
4.4.2 Passo 2: Selezione del le da importare
Il secondo passo richiede si selezionare il le contenente i dati da Importare.
Il File, come da speciche, può avere estensione .CSV o .TSV; nel nostro caso
andremo ad importare un le .CSV. Il le .CSV, come detto in precedenza, è
facilmente ottenibile dal le .xsl salvando l'ultimo nell'estensione voluta tramite
45
qualsiasi editor di fogli di calcolo; inoltre, una volta convertito il le, è necessario controllarlo per vericare che la conversione non abbia provocato errori
di sintassi e che sia correttamente formattato secondo le speciche del formato
.CSV. Una volta prese queste accortezze si può procedere al passo successivo.
Figura 30: Passo numero 2 per la fase di import: La selezione del le contenente
i dati
4.4.3 Passo 3: Impostazioni del le da importare
Il terzo passo è un 'settings step' dove si specica come è stato formattato il
le .CSV. La prima cosa da aggare è l'opzione che indica che la prima riga
del le contiene il nome degli attributi; questa opzione è facoltativa ma è buona
norma selezionarla sempre per facilitare Drupal a mappare gli attributi indicati
sui campi della struttura dati creata con il CCK. Il resto di questo passo consiste
nel scegliere la formattazione adottata nel le .CSV. Il le convertito degli utenti
del portale Energy CHIT è cosi formattato:
File Format: Semicolon Separated Value ( non si riferisce all'estensione
pura del le ma ad alcune varianti della formattazione del le CSV);
Record Separator : NewLine, cioè il classico carattere di 'a capo';
Field Separator: il carattere che separa i campi ( ; );
Text Delimiter e Escape Character: il carattere ();
Alla ne della pagina viene inoltre mostrato un esempio del le caricato nel
passo 2 per facilitare la scelta della formattazione.
Dopo aver correttamente
scelto l'opzione giusta si può procedere al passo successivo.
46
Figura 31: Passo 3: Settaggio delle opzioni di formattazione del le
4.4.4 Passo 4: Mappatura degli attributi del le con i campi della
struttura dati
Questo 4° passo è denibile 'gratis', poiché non c'è nulla da fare. Se il le .CSV
alla prima riga contiene i nomi degli attributi, e questi nomi sono esattamente
uguali ai campi della struttura customizzata, il mapping lo fa Drupal stesso
senza chiedere nulla in aggiunta.
In fondo alla schermata inoltre Drupal fa
un esempio tabellare praticamente uguale al le .XSL di origine ( solo con
4/5 tuple) per far comprendere visivamente che no a questo punto va tutto
bene.
Oltre alla mappatura dei campi sono presenti altre voci per le opzioni
di pubblicazione, sono opzionali e non inuiscono sull'esito dell'import. Dopo
aver controllato l'esatta mappatura si può procedere tranquillamente al passo
numero 5.
4.4.5 Passo 5: Opzioni per l'importazione
Questo passo invece, è piuttosto oscuro, con tutte le prove di import svolte
non è mai stato richiesto nulla da impostare o altro; si rivela ancora più 'gratis'
del passo numero 4.
4.4.6 Passo 6: Impostazione dei valori di default
In questo terzultimo passo il wizard richiede alcune informazioni di default da
allegare all'import quali
Il formato dell'import, Filtered o Full HTML ( il le .CSV è solitamente
ltered poiché contiene solo dati senza neanche una riga di HTML);
Informazioni riguardanti l'autore dell'import;
Informazioni sulla revisione;
47
Opzioni di pubblicazione (diverse da quelle presenti nel passo 4);
Impostazioni sulle opzioni per inserire dei commenti sull'import;
4.4.7 Passo 7: Anteprima dei dati
Nel settimo passo, Drupal dovrebbe mostrare l'anteprima dei dati prima dell'import nale. Uso il condizionale poiché dalla prima no all'ennesima prova,
il sistema ha dato sempre e solo Warning.
Figura 32: Passo 7: Il problema dei Warning sull'anteprima dell'import
Inizialmente questi 'pericoli' sono stati ignorati proprio per il loro senso
intrinseco, cioè non segnalano errori ma avvertono di potenziali problemi.
Tuttavia in seguito questi warning trascurati saranno fondamentali per l'esito
del progetto; andremo ad analizzare questo problema successivamente non
appena sarà nita la descrizione del wizard di import.
48
4.4.8 Passo 8: Inizio dell'import
L'ultimo passo consiste in un riepilogo delle informazioni principali ottenute in
tutti i passi precedenti, dando all'utilizzatore, una visione complessiva del lavoro
svolto durante il wizard.
Figura 33: Ultimo passo: Visualizzazione di riepilogo prima di iniziare l'import
Figura 34: Seconda schermata che riassume le informazioni nel passo 8
Inne dando il comando 'start import' il processo viene eseguito; al termine
una pagina compone il risultato dell'operazione fornendo alcune informazioni
sul risultato, quali:
49
Il risultato dell'operazione;
Il numero di righe importate;
Il numero di righe importate con errori (zero signica che tutto è andato
liscio);
Informazioni sul processo di import (data e ora , utente loggato che ha
eettuato l'import, e il nome del le importato).
Inoltre è possibile fare interrogazioni sulla tabella di Drupal appena popolata
per identicare:
Le righe con errori;
Le righe senza errori;
Tutte le righe con l'aggiunta dell'eventuale codice di errore;
Tutte le righe con la chiave primaria in testa alla tupla.
Se si richiedono queste interrogazioni il risultato è un le .CSV scaricabile
contente le tuple che hanno avuto riscontro.
Figura
35:
Risultato
dell'operazione
di
import
con
annesse
funzioni
di
interrogazione
I risultati di tutti i test di import hanno mostrato sempre un esito
apparentemente positivo; tutte le righe vengono importate senza errori e anche
gli Id vengono importati correttamente. Tuttavia i primi problemi si sono
vericati quando è sorta la necessità di interrogare la tabella contenente gli
utenti del portale Energy CHIT. Prima di arontare il problema riscontrato è
necessario svolgere un'attività riassuntiva su come si eseguono interrogazioni
tramite le Viste.
50
4.5
Creazione di interrogazioni sul database tramite le
Viste
Le viste sono, come accennato nella sezione di introduzione, uno dei concetti fondamentali per un CMS. Nel caso di Drupal sono l'unico strumento per accedere
ai contenuti immagazzinati nel database. Il modulo 'viste' non è preinstallato
nella versione di default ma è presente come contenuto extra scaricabile. L'importanza di questo strumento è accentuata anche dai numerosi plugin sviluppati
dalla comunità Drupal che arricchiscono le funzioni già presenti (Views Node
Feed, Views Importer, Views Datasource, ecc.). Dopo aver installato il modulo,
e dopo aver aggiunto eventuali plugin necessari, l'interfaccia di creazione delle
viste è raggiungibile dalla sezione di amministrazione del sito e si presenta come
mostrato in gura sotto.
Figura 36: Pagina principale del modulo Viste
Le opzioni di navigazione permettono di:
Mostrare l'elenco delle viste create e delle viste di default, modicarle ed
esportarle;
Aggiungere una nuova vista;
Importare viste precedentemente esportate (se si ha attivato il modulo
relativo);
Raggiungere un pagina 'tools', cioè strumenti che permettono di abilitare
una serie di opzioni sulle viste; non vengono analizzate poiché sono nominate in modo autoesplicativo e posseggono inoltre un ulteriore descrizione
sul loro ruolo.
La funzione principale è ovviamente quella che crea nuove viste, l'andremo
immediatamente ad analizzare.
51
Non appena entriamo nella sezione, il sistema richiede alcune informazioni
iniziali (nome, descrizione e che tipo di dato si vuole estrarre); nel caso che
si voglia estrarre il contenuto di una custom structure l'opzione da scegliere è
'nodo', negli altri casi invece si possono scegliere le strutture di default. La fase
successiva (mostrata sotto) è il cuore della creazione delle viste; qui si possono
impostare una serie notevole di parametri per poter comporre la Query.
Figura 37: Il 'core' della creazione delle viste.
Il procedimento è composto da 3 blocchi principali disposti da sinistra verso
destra:
Il primo blocco riguarda Pagine e Blocchi, serve per denire come la
vista deve essere visualizzata, se come blocco o come pagina.
In ques-
ta si sceglie se si vuol creare una nuova pagina (o blocco), l'url, il tipo
di vista da visualizzare (vale a dire se nella vista i contenuti devono
essere visualizzati per intero o solo come un'anteprima, in una tabella,
ecc.), l'intestazione, il footer, il menù, se si vuole utilizzare ajax e tanto
altro ancora.
Un parametro importante da evidenziare è il path, es-
so serve per impostare il percorso della vista raggiungibile direttamente
dall'url (es:
www.miosito.it/nomevista), in questo modo si inizia già a
denire una gerarchia di pagine all'interno del sito. Inoltre è possibile posizionare la raggiungibilità della vista in un qualche menù di navigazione
presente nel sito (basta specicare il nome del menù ed essa sarà aggiunta
automaticamente).
Il secondo blocco riguarda più un aspetto 'tecnico', si posso impostare
eventuali relazioni (cammini di join), argomenti (i parametri che si mettono nella condizione 'where') e i campi da visualizzare che sono praticamente i campi che vengono inseriti nella 'select'. Gli argomenti vengono
passati a Drupal tramite l'URL, questo sfrutta esattamente il metodo 'get'
che viene nascosto all'utilizzatore all'interno del codice del modulo.
52
Il terzo blocco riguarda i criteri di ordinamento e i ltri; la sezione ltri
serve per ltrare quale tipo di contenuto (nodo, tassonomia. . . ) vogliamo
visualizzare (es. Tipo di contenuto-> Story, visualizzerà solo i contenuti
di tipo Story). Nella sezione criteri di ordinamento si può settare l'ordine
di visualizzazione della vista (es. ordinati per data).
Un esempio pratico potrebbe essere quello di visualizzare in una Pagina il contenuto della tabella Utenti di Drupal, estraendo il nome, l'email e la data di
registrazione. Risulta necessario specicare un piccolo ma signicativo concetto:
nel caso si voglia estrarre dati da una sola tabella, il tool, nei suoi settings, non
permette di impostare il nome della tabella. Quindi come si fa?. La risposta è
piuttosto semplice ma altrettanto non immediata da comprendere; Drupal non
vuole fare vedere l'elenco delle sue tabelle, poiché possiede una metodologia
di organizzazione delle tabelle tutta sua e abbastanza dicile da comprendere,
perciò applica una procedura piuttosto intelligente per fare la select sulla tabella
giusta:
1. In base al tipo di dato selezionato nella pagina iniziale della procedura di
creazione, ltra le tabelle non necessarie;
2. Dopo questa 'scrematura' applica una procedura per vericare i permessi
( si ricorda che l'utente può interrogare solo le tabelle di cui è proprietario
e quelle di default). Con questo sistema elimina ulteriori tabelle del tipo
di dato corretto ma che non sono accessibili.
3. Le rimanenti tabelle sono quelle che contengono le informazioni accessibile
e desiderate.
Ora la domanda sorge spontanea: Se ci sono due tabelle Utenti per esempio, di
cui una contiene gli utenti attivi e l'altra quelli non attivi, e voglio estrarre il
nome di quelli attivi , come faccio a distinguere il campo 'nome' di quelli attivi
e non attivi?
Risposta> Quando seleziono i campi da visualizzare, i campi sono disposti
secondo la sintassi [Nome Tabella: Nome campo], in questo modo Drupal elimina
le ambiguità fra nomi di campi uguali.
Le viste sono utilissime per popolare il proprio sito di contenuti personalizzabili ma, a dierenza degli altri strumenti di drupal, non sono immediate da
padroneggiare. Come detto in precedenza, le viste, posseggono una lacuna sulla
possibilità di eettuare interrogazioni complesse (es. Query concatenate); per
questo motivo è stato sviluppato un plugin (Custom Reports) e si rimanda alla
sezione dei moduli di Import/Export per comprenderne il funzionamento.
53
4.6
Problemi riscontrati con l'operazione di migrazione
del database
All'inizio dei test con il modulo 'node import' gli unici errori riscontrati furono i
vari warning che, nel 7° passo, indicavano dei problemi sulla visualizzazione dell'anteprima dell'import. I problemi reali sono sopraggiunti quando sono passato
alla realizzazione della vista per mostrare i contenuti appena importati. La vista
o query in questione è piuttosto semplice, una banale selezione di tutti i campi
nella tabella EnergyCHITUsers ordinati per chiave primaria. La costruzione e
l'esecuzione di tale interrogazione è stata necessaria per provare che l'operazione
di import era andata a buon ne, nonostante che il modulo incaricato avesse
dato esito positivo. Il problema, tradotto in risultato, è che la query non restituiva nulla come risultato. Di primo impatto ho pensato che avessi sbagliato
l'impostazione della query e dopo una serie ripetuta di test questa opzione è
stata scartata poiché la vista era giusta. Dopo un certo numero di riessioni ho
deciso di scendere di livello ed entrare nel sistema di gestione del database di
Drupal.
Figura 38: Pagina di Amministrazione 'manuale' del database di Drupal
Il mio intento era quello di esplorare le tabelle del modulo 'node import' per
vericare che esse fossero state popolate dall'operazione di importazione.
Come da speciche il database di Drupal è piuttosto grande e poco chiaro; il
CMS, appena installato, crea già una trentina di tabelle in cui gestisce i suo
contenuti privati. Inoltre ogni modulo installato e attivato crea una o più
tabelle dove va a inserire i dati più svariati; ma secondo la logica di Drupal,
l'utilizzatore non dovrebbe mai entrare in questa sezione, e quindi non è un
obbiettivo rendere il database leggibile e comprensibile nella sua versione
'nuda'.
54
La ricerca delle tabelle create dal modulo è stata abbastanza semplice poiché,
a dispetto del contesto, il nome di ogni tabella è abbastanza chiaro e riconduce
immediatamente al modulo proprietario.
Figura 39: Le tabelle del modulo node import
Come mostrato in gura sopra le tabelle create dal modulo 'node import' sono
2:
node_import_status;
node_import_tasks;
La prima contiene tutti i dati importati, in cui ogni tupla è un record completo;
mentre nella seconda sono memorizzate tutte le operazioni di import eettuate
(quest'ultima tabella è stata ripulita poiché le prove di import non sono state
molte più di una). Il fattore evidente è che la tabella 'import_status' contiene
60 tuple e il le 'utenti_energy_chit.csv' contiene esattamente 60 record, ciò
dimostra che l'operazione di import ha prodotto 'qualcosa'. Il contenuto è stato
denito 'qualcosa' perché se si entra nella tabella in modalità 'mostra contenuto'
il risultato non è per nulla chiaro (vedi gura sotto).
55
Figura 40: Il contenuto della tabella node_import_status
Il contenuto sembra molto simile ad una serie di indirizzi di memoria e non a
dati veri e propri e quindi l'accertamento della buona riuscita dell'import non
è possibile. Dopo questa analisi ho pensato che la struttura customizzata
creata tramite il CCK non fosse stata creata correttamente e quindi sono
andato ad analizzare le tabelle del Content Construction Kit.
Figura 41: Il contenuto della tabella del modulo CCK
Anche in questo caso, come è possibile notare dalla gura sopra, l'operazione
eseguita dal modulo costruttore è andata a buon ne; è stata creata una
tabella con il nome del content type (UsersEnergyChIT) e al suo interno sono
stati inseriti i campi customizzati rispettando tutte le speciche che erano
state data in fase di generazione.
56
Inne dopo questo ennesimo controllo, con l'aiuto del professor Marco Brambilla, è venuto alla luce un piccolo dettaglio che, in fase di analisi non era stato
rivelato. Nella pagina relativa al modulo 'node import', sul sito web di Drupal,
una voce nella descrizione delle caratteristiche del modulo annunciava che :Il
modulo dovrebbe funzionare con le strutture customizzate create con il CCK.
Figura 42: Home page del modulo 'node import' sul sito web di Drupal
Figura 43: Home page del modulo di Drupal e la voce dichiarante il non possibile
funzionamento
A causa di questa 'possibile' incompatibilità il lavoro di migrazione del
database non è avvenuta con successo.
57
Il progetto avrebbe avuto seguito se
fosse esistito un altro modulo per l'importazione di le .CSV, ma purtroppo
non è così. Un'analisi più accurata in fase di progettazione concettuale avrebbe
evidenziato questa complicazione e magari il progetto avrebbe potuto evolversi
in un'altra direzione ma per mancanza di tempo materiale e per non gettare alle
ortiche il lavoro svolto l'obbiettivo non è stato raggiunto.
Tutto questo evidenzia quanto un'accurata analisi dei requisiti e degli strumenti sia importante per la buona riuscita del progetto; in questo caso, il mancato raggiungimento dell'obbiettivo, non ha portato a grosse conseguenze essendo
un progetto didattico. Si pensi però se questo progetto fosse stato avviato in
un ambito lavorativo e portato avanti nelle stesse modalità, il danno economico
per la società sarebbe stato molto più rilevante dell'insuccesso nel mio progetto
di tesi.
58
5
Conclusioni
L'elaborato presente è stato svolto per introdurre il mondo dei CMS, i suoi
scopi, i suoi pregi e difetti. Il problema dell'integrazione è stato arontato in
maniera approfondita per far comprendere la delicatezza di tale operazione e
le potenzialità dei Content Management System.
La fase di descrizione dei
moduli di import/export ha raorzato il concetto di potenzialità nonostante
che alcuni moduli non siano perfettamente funzionanti o manchino di funzioni
essenziali;inoltre, la descrizione, ha sollevato il concetto di stabilità ed adabilità dei moduli con l'intento di suggerire all'utente di eseguire ricerche accurate
all'interno della comunità Drupal prima di iniziare l'utilizzo di un qualsiasi modulo. L'aspetto dell'analisi è fondamentale nell'uso dei CMS, poiché, permette di
pianicare nel dettaglio il lavoro da svolgere aancandogli possibili strade alternative nel caso si vericassero imprevisti spiacevoli. La comunità di sviluppatori
è in continua crescita e lo sviluppo dei più svariati moduli non accenna a fermarsi; pertanto con il passare del tempo questi nuovi strumenti di programmazione
web diventeranno sempre più stabili ed usati.
In linea con questa tesi potrebbe essere avviato un progetto di sviluppo di
un modulo stabile per l'import di le .CSV. Il progetto avrebbe come scopo
la programmazione in PHP di un modulo che colmi le lacune di quelli usati
permettendo così, all'utilizzatore, la possibilità di una migrazione semplice di
database.
Avrei Voluto
Nell'arontare il problema avrei voluto un impatto migliore
con i CMS; la comprensione di come funziona e come è gestito non è immediata. Mi sarebbe piaciuto che, una volta installato, Drupal mi fornisse una sorta
di 'tutorial' per apprendere senza ambiguità i procedimenti basilari. Alla ne
di questo 'tutorial', sarebbe stato molto comodo un modulo di 'welcome' che
permetta, in base alle scelte dell'utente, di auto-congurare la piattaforma a
seconda dell'intento per cui è stato installato (blog, sito aziendale, pubblicità,
ecc.). L'auto-congurazione non è un concetto astratto; secondo me si potrebbero creare dei pattern già congurati e pronti all'uso per permettere all'utente
di spendere il suo tempo nell'inserimento dei contenuti e non nella congurazione
dei contenitori. Ovviamente questa soluzione non può coprire tutte le possibili
casistiche, ma di certo potrebbe essere un buon inizio.
59
A
Glossario
Questo glossario serve per coloro che non comprendono alcuni termini o concetti
presenti in questa tesi. Non si vuole fornire una spiegazione esaustiva su ogni
termine o concetto ma si vuole solamente dare un' infarinatura con informazioni
base per comprendere almeno l'argomento di cui fa parte; alcuni concetti e
termini non sono stati descritti poiché non è possibile riassumere in poche righe
il concetto.
1.
Web Server :
Un server web è un servizio, e per estensione il computer
su cui è in esecuzione, che si occupa di fornire, tramite software dedicato
e su richiesta dell'utente, le di qualsiasi tipo, tra cui pagine web.
2.
Html :
HyperText Markup Language (traduzione letterale: linguaggio di
descrizione per ipertesti) è un linguaggio usato per controllare la struttura
dei documenti ipertestuali disponibili nel World Wide Web.
3.
Php
: PHP (acronimo ricorsivo di "PHP: Hypertext Preprocessor", pre-
processore di ipertesti) è un linguaggio di scripting interpretato, con licenza open source e libera , originariamente concepito per la programmazione
Web ovvero la realizzazione di pagine web dinamiche.
Attualmente è
utilizzato principalmente per sviluppare applicazioni web lato server
4.
Css
:
(Cascading Style Sheets), è un linguaggio usato per denire la
rappresentazione graca di documenti HTML, XHTML e XML.
5.
Xml
:
(sigla di eXtensible Markup Language) è un metalinguaggio di
markup, ovvero un linguaggio marcatore che denisce un meccanismo
sintattico che consente di estendere o controllare il signicato di altri
linguaggi marcatori.
6.
Java:
7.
Content Type
Java è un linguaggio di programmazione orientato agli oggetti.
: (tradotto, tipo del contenuto), usato per indicare nei
CMS una struttura dati avente uno specico tipo.
8.
Jsp :
JavaServer Pages, di solito indicato con l'acronimo JSP, è una tec-
nologia Java per lo sviluppo di applicazioni Web che forniscono contenuti
dinamici in formato HTML o XML.
9.
Caching :
L'operazione che sfrutta la cache o più propriamente la memo-
ria cache che è una memoria temporanea, non visibile al software, che
memorizza un insieme di dati che possano successivamente essere velocemente recuperati su richiesta.
10.
WYSIWYG : Acronimo di What You See Is What You Get ("quello che
vedi è quello che ottieni").
Esprime il concetto di ottenere un risultato
uguale identico a quello realizzato in fase di progettazione; sia su carta
che sullo schermo.
11.
Gnu Gpl
libero.
: La GNU General Public License è una licenza per software
È comunemente indicata con l'acronimo GNU GPL o semplice-
mente GPL.
60
12.
Dbms :
Database Management System, è un sistema software progettato
per consentire la creazione e manipolazione eciente di database.
13.
Javascript :
JavaScript è un linguaggio di scripting orientato agli oggetti
comunemente usato nei siti web.
14.
Ajax :
acronimo di Asynchronous JavaScript and XML, è una tecnica di
sviluppo per la realizzazione di applicazioni web interattive (Rich Internet
Application).
Lo sviluppo di applicazioni HTML con AJAX si basa su
uno scambio di dati in background fra web browser e server, che consente
l'aggiornamento dinamico di una pagina web senza esplicito ricaricamento
da parte dell'utente.
15.
Script
: In informatica, il termine script designa un tipo particolare di
programma.
I linguaggi di programmazione utilizzati per scrivere tali
programmi vengono detti linguaggi di scripting.
16.
Wizard :
Nel linguaggio dell'informatica, il wizard indica una procedura
informatica, generalmente inglobata in una applicazione più complessa,
che permette all'utente di eseguire determinate operazioni (solitamente
complesse) tramite una serie di passi successivi.
17.
Tassonomia
: Nel suo signicato più generale, la scienza della classi-
cazione.
18.
Ftp :
Il File Transfer Protocol (FTP) (protocollo di trasferimento le), è
un Protocollo per la trasmissione di dati tra macchine.
19.
Csv
:
comma-separated values, è un formato di le basato su le di
testo utilizzato per l'importazione ed esportazione (ad esempio da fogli
elettronici o database) di una tabella di dati.
20.
Rdf
:
Il Resource Description Framework (RDF) è lo strumento per
la codica, lo scambio e il riutilizzo di metadati strutturati e consente
l'interoperabilità tra applicazioni che si scambiano informazioni sul Web.
21.
Json
: Acronimo di JavaScript Object Notation, il JSON è un formato
adatto per lo scambio dei dati in applicazioni client-server.
22.
Plugin :
Il plugin in campo informatico, è un programma non autonomo
che interagisce con un altro programma per ampliarne le fu
23.
Path di installazione
:
Indica il percorso all'interno delle cartelle di
sistema partendo dalla radice (root), dove viene installato un software o
dove è locato un le.
24.
UTF-8
:
(Unicode Transformation Format, 8 bit) è una codica dei
caratteri Unicode in sequenze di lunghezza variabile di byte.
25.
Api
:
Le Application Programming Interface (Interfaccia di Program-
mazione di un'Applicazione), sono ogni insieme di procedure disponibili
al programmatore, di solito raggruppate a formare un set di strumenti
specici per un determinato compito.
61
26.
Url :
Un Uniform Resource Locator è una sequenza di caratteri che iden-
tica univocamente l'indirizzo di una risorsa in Internet, come un documento,un'immagine o una pagina web; è quella stringa di caratteri che
viene inserita nella barra degli indirizzi di un browser web.
62
![(Microsoft PowerPoint - EOS_CMS.ppt [modalit\340 compatibilit\340])](http://s1.studylibit.com/store/data/007527366_1-a7c0359f0c6240d4c919352174d3d4dd-300x300.png)
