Progettazione e Sperimentazione Di Un Framework Estensibile Per Applicazioni Web

UNIVERSITÀ DEGLI S TUDI DI MILANO BICOCCA
FACOLTÀ DI SCIENZE M ATEMATICHE FISICHE E N ATURALI

Corso di Laurea in Informatica
Progettazione e Sperimentazione
di un Framework Estensibile per
Applicazioni Web
SUPERVISORE: Chiar.mo Prof. R. Polillo
Relazione della prova finale di:

DAVIDE CASALI
Matr. n. 041666
Anno Accademico 2004/2005


A Elisa
-2-

S o m ma ri o
Sommario ...................................................................................... 3
1. Introduzione ............................................................................. 6
1.1. Obiettivi.............................................................................. 6
1.2. Storia ................................................................................. 6
1.3. Organizzazione del lavoro ................................................... 7
1.4. Struttura dell’elaborato........................................................ 8
2. Analisi .................................................................................... 10
2.1. Definizioni ........................................................................ 10
2.1.1. Cos’è un Content Management System (CMS) ................... 10
2.1.2. Cos’è un Framework......................................................... 11
2.2. Tratti comuni: così fan tutti ................................................ 12
2.3. Tratti distintivi: analisi dei vari motori................................. 13
2.3.1. PHPNuke ......................................................................... 14
2.3.2. Xoops .............................................................................. 16
2.3.3. Mambo ............................................................................ 18
2.3.4. Drupal.............................................................................. 19
2.3.5. WordPress ....................................................................... 20
3. Requisiti del sistema phpGolem............................................ 22
3.1. Linee guida....................................................................... 22
3.2. Tipologie di utenti ............................................................. 24
3.2.1. Framework developer ....................................................... 24
3.2.2. Framework user ............................................................... 25
3.2.3. Backoffice user ................................................................ 25
3.2.4. Public site user................................................................. 26
3.3. Requisiti di architettura ..................................................... 26
3.4. Requisiti di usabilità e interfaccia ...................................... 28
3.5. Requisiti tecnici ................................................................ 29
4. Architettura generale del sistema ......................................... 31
4.1. Architettura....................................................................... 31
4.2. Database.......................................................................... 33
-3-

4.2.1. Gestore web multisito (web, setup) .................................... 34

4.2.2. Gestore estensioni (ext).................................................... 35
4.2.3. Gestione utenti, gruppi e diritti (user, auth) ........................ 36
4.2.4. Gestione dell’architettura del sito (arch)............................. 39
4.2.5. Gestione della configurazione (config) ............................... 41
4.3. Filesystem ........................................................................ 42
4.4. Framework ....................................................................... 43
4.4.1. Web handler..................................................................... 45
4.4.2. Extensions handler ........................................................... 46
4.4.3. Users handler................................................................... 47
4.4.4. Architecture handler ......................................................... 48
4.4.5. Configuration handler ....................................................... 50
4.4.6. Template handler ............................................................. 50
4.4.7. Interface handler .............................................................. 53
4.4.8. Script di generazione pagina ............................................. 53
4.4.9. Struttura dell’URL ............................................................. 56
4.5. Estensioni ........................................................................ 57
4.6. Come sono perseguite le linee guida ................................. 60
4.6.1. Estensibilità ..................................................................... 60
4.6.2. Flessibilità ....................................................................... 61
4.6.3. Semplicità di sviluppo ....................................................... 61
4.6.4. Semplicità di uso .............................................................. 61
4.6.5. Riuso ............................................................................... 62
5. User view ............................................................................... 63
5.1. Installazione ..................................................................... 63
5.2. Estensioni ........................................................................ 66
5.2.1. Extensions ....................................................................... 66
5.2.2. Configuration ................................................................... 67
5.2.3. Architecture ..................................................................... 68
5.2.4. Groups............................................................................. 70
5.2.5. Users............................................................................... 71
5.2.6. Articles ............................................................................ 72
5.2.7. Topics.............................................................................. 74
5.2.8. Comments ....................................................................... 75
5.2.9. Files ................................................................................ 76
6. Sperimentazione .................................................................... 78
6.1. Sito in oggetto .................................................................. 78
6.2. Metodologia di progettazione............................................. 78
-4-

6.3. Definizione requisiti .......................................................... 79

6.3.1. Analisi della concorrenza .................................................. 79
6.3.2. Obiettivi generali .............................................................. 82
6.3.3. Utenti............................................................................... 83
6.3.4. Requisiti di architettura ..................................................... 85
6.3.5. Requisiti di comunicazione................................................ 86
6.3.6. Requisiti funzionali ........................................................... 86
6.3.7. Requisiti di contenuto ....................................................... 87
6.3.8. Requisiti di gestione ......................................................... 88
6.3.9. Requisiti di accessibilità.................................................... 88
6.3.10. Requisiti di usabilità........................................................ 89
6.4. Web design ...................................................................... 89
6.5. Visual design .................................................................... 91
6.6. Sviluppo del software ........................................................ 93
6.7. Redazione dei contenuti.................................................... 93
6.8. Il risultato ......................................................................... 93
7. Riferimenti e bibliografia ....................................................... 98
7.1. Riferimenti ........................................................................ 98
7.2. Bibliografia ....................................................................... 99
-5-

1 . I n t ro d uzi o n e
1.1. Obiettivi
In internet esistono numerosissimi software per la gestione di siti web
di piccole, medie o grandi dimensioni. Questi programmi sono
denominati, in rapporto al loro approccio al problema, Content
Management Systems (CMS) oppure Frameworks.
Questo elaborato delinea i vari passi di realizzazione di un sistema

di questo tipo, sottostante un sito web, partendo da un’analisi dei suoi
requisiti per giungere alla realizzazione del prodotto software
pienamente funzionante.
Lo scopo è quindi dare una spiegazione esauriente delle fasi iniziali di

analisi e di progettazione, fino alla successiva implementazione e
sperimentazione in un sito web effettivo.
Il progetto software realizzato è una piattaforma aperta per la

realizzazione di un sito web interattivo di dimensioni piccole e
medie, focalizzato su alcuni aspetti peculiari che verranno delineati
nel corso della trattazione.
1.2. Storia
Il software qui esposto è denominato phpGolem. Ha preso avvio nel
giugno 2003 con scopi molto limitati e centrati ad hoc per un portale
web.
-6-

Successivamente (settembre 2003) questo progetto è stato

abbandonato, ma si è sentita la necessità di avere una solida base su
cui realizzare eventuali altri siti, senza essere vincolati ad un preciso
target operativo e visuale.
Quando si è giunti alla maturità della versione 0.3 (gennaio 2004) si è

notato che, sebbene i requisiti iniziali fossero stati ampiamente
soddisfatti, l’idea originale poteva essere estesa per realizzare un
sistema completamente modulare e quindi adattabile ad ogni
necessità.
Quindi giunge la versione 0.4 (prima beta a luglio 2004) è una
riscrittura integrale del codice basata su questa logica più astratta ed
efficiente, che ha portato a notevoli miglioramenti.
La versione di phpGolem 0.4 è quella qui presa come riferimento e ne

viene delineato lo sviluppo e la realizzazione.
1.3. Organizzazione del lavoro

Il lavoro è stato organizzato in due fasi distinte. La prima è stata
quella operativa che è andata ad analizzare phpGolem per verificare,
dal punto di vista dell’utente, quanto fosse efficace e come
rispondesse alle esigenze, cercando di realizzare una interfaccia
semplice ed uniforme.
In questa fase si è realizzata una versione navigabile di un sito web

(che si trova spiegata nell’ultima parte di questo elaborato), per poter
osservare operativamente il comportamento del motore nella
gestione delle pagine e della struttura del sito.
Nel frattempo, si procedeva alla realizzazione di una interfaccia più

intuitiva per la parte di amministrazione e gestione del sito, in modo
da verificare come i cambiamenti potessero essere effettuati in modo
semplice e, contemporaneamente come questi si riflettessero sul sito
pubblico.
-7-

Successivamente si è proceduto ad una analisi di tutto il materiale

raccolto sino a questo punto, del lavoro svolto e della struttura logica
del programma, delineando la struttura complessiva di questo
elaborato.
1.4. Struttura dell’elaborato

L’elaborato è strutturato in modo da fornire una prospettiva esauriente
su phpGolem.
Nella prima parte, Analisi (cap 3), verrà quindi esposta la tipologia di
programma software che è stata sviluppata, cioè il significato di
framework estensibile e di content management system, con i loro
contesti applicativi.
Verranno quindi analizzati i tratti fondamentali che sono comuni a
questi tipi di sistemi in modo da delineare quali siano i punti
imprescindibili che bisogna tenere in considerazione. In più verrà fatto
un breve passaggio sui vari sistemi opensource attualmente
disponibili che rientrano in questa categoria, così da avere una base
di implementazioni sulle quali ragionare e valutare i pro e i contro di
ciascuna.
Nella seconda parte, Requisiti del sistema phpGolem (cap 4),

saranno invece definite le linee guida sulle quali il progetto viene
fondato, in modo che siano sempre ben chiari le priorità e gli scopi da
perseguire.
E’ poi importante avere una immagine più concreta e aderente alla
realtà su chi siano gli utilizzatori di questo software, in modo da poter
focalizzare una utenza precisa. In quest’ambito ci si concentra
soprattutto sulla parte tecnica e di amministrazione: la parte pubblica
del sito avrà altre utenze che necessiteranno di una valutazione ad
hoc in rapporto alle necessità.
Quindi si passa alla definizione dei vari requisiti del sistema, come i
requisiti di architettura, di usabilità e tecnici.
-8-

La terza parte, Architettura generale del sistema phpGolem (cap

5), approfondisce l’analisi e passa ai dettagli implementativi a livello
di struttura e logica.
E’ una parte che senza scendere in dettagli troppo implementativi
descrive il funzionamento logico delle varie componenti che
costituiscono il software phpGolem, partendo da uno schema generico
e quindi descrivendo più esaurientemente ogni livello.
Viene poi posto un accento sulla prospettiva utente nella parte User
View (cap 6), dove vengono descritte le principali funzionalità che il
CMS, basato sul framework phpGolem, mette a disposizione.
Questo viene fatto tramite un approccio descrittivo non troppo tecnico,
che si rivolge ad un utente non esperto, spiegando come svolgere le
principali operazioni.
Infine c’è la parte di Sperimentazione (cap 7) che prendendo ad

esempio il modello di valutazione del libro “Il Check Up dei Siti Web”
(v. Bibliografia) lo applica alla progettazione per poter realizzare un
sito efficace e completo, basato sempre su phpGolem CMS.
-9-

2 . A n al is i
2.1. Definizioni
Prima di delineare come è stato progettato phpGolem, è meglio avere
una panoramica sul contesto nel quale si inserisce.
Vediamo quindi di entrare nella questione, definendo prima le

tipologie dei programmi utilizzabili per questo scopo e in seguito
analizzandone alcuni.
2.1.1. Cos’è un Content Management System (CMS)

Internet è un luogo dove l’informazione è libera di circolare, di essere
condivisa, rielaborata e diffusa globalmente.
Date queste premesse, è fondamentale l’esistenza di strumenti
software per organizzare questo flusso di informazione, nell’ambito
ristretto di un singolo sito web (o di un network di siti).
Tradotto da en.wikipedia.org:
Nell’informatica, un content management system (CMS) è un
sistema utilizzato per organizzare e rendere semplice la
creazione collaborativa di documenti e altri contenuti. Un CMS è
frequentemente una applicazione web utilizzata per gestire siti e
contenuti, anche se in alcuni casi dei CMS richiedono del
particolare software client installato su un computer per
modificare e realizzare articoli.
Un content management system è quindi una struttura software che è

adibita a gestire e organizzare, in modo coerente, una quantità di
- 10 -

informazioni anche notevole e, spesso, riguardante media differenti,

anche se principalmente si considera la componente testuale, data la
maggiore facilità con cui può essere veicolata.
L’operazione di gestire informazione in modo collaborativo può

essere condotta in svariati modi, differenti e specifici allo scopo che ci
si prefigge di ottenere.
Vi sono ad esempio:
• web content management systems per gestire ed organizzare
vari aspetti del web
• transactional content management systems (T-CMS) per gestire
e organizzare transazioni di commercio elettronico
• integrated content management systems (I-CMS) per assistere
nella gestione di documenti internamente ad una azienda
• publications management systems (P-CMS) per aiutare nella
gestione di pubblicazioni come manuali, libri, testi, etc
• learning management systems (L-CMS) che forniscono un
ambiente di supporto nell’apprendimento
Come si può vedere l’ambito di utilizzo di questi software può variare

molto, sia dal punto di vista dell’informazione veicolata sia dal punto
di vista dell’organizzazione della stessa e del modo di interazione.
2.1.2. Cos’è un Framework

Un framework software è invece uno strumento sopra il quale si può
realizzare il proprio progetto. Può essere considerato come le
fondamenta sulle quali viene costruito un edificio.
Tradotto da en.wikipedia.org:
Nello sviluppo software un framework è una specifica struttura di
supporto all’interno della quale un altro software può essere
organizzato e sviluppato. Un framework può includere programmi
di supporto, librerie di codice, linguaggi di scripting o altri
- 11 -

software per aiutare nello sviluppo e funziona come colla fra i vari
componenti di un progetto software.
Quindi, fondamentalmente un framework risulta essere un

componente invisibile all’utente finale, mentre è di cruciale
importanza per lo sviluppatore.
Utilizzare un framework piuttosto che iniziare da zero implica avere un
punto di partenza migliore e strumenti a disposizione già rifiniti per
poter lavorare, ma di contro bisogna anche ricordare che esistono dei
framework molto specifici e, quindi, sbagliare in questa scelta iniziale
potrebbe essere un problema perché vincola integralmente lo sviluppo
futuro.
Questo livello software, come è stato specificato può fornire più o

meno servizi, ma rimane un ambiente di lavoro all’interno del
quale il programma funziona.
Il framework si distingue quindi da una libreria in quanto quest’ultima

è qualcosa che si aggiunge al corpo di esecuzione del programma
principale, mentre nel caso del framework il software gira al suo
interno.
2.2. Tratti comuni: così fan tutti

Nella maggior parte dei programmi CMS opensource disponibili in
rete, si possono riscontrare vari elementi comuni.
Un numero notevole di CMS disponibili in rete, persegue un fine
specifico e/o si orienta verso una precisa fascia di pubblico.
Il target scelto da phpGolem è quindi condiviso da altri motori: si

colloca in una fascia di utenza non per forza esperta in questo tipo di
tecnologie, orientata ad un facile e veloce deployment (installazione
sul server) ed ha una gestione che può non richiedere alcuna
conoscenza di programmazione.
- 12 -

Oltre alle caratteristiche che definiscono la tipologia del programma,

questa categoria di CMS gestisce la grafica e il layout delle
pagine, seppure ciascuno in modo differente. Alcuni seguono un
approccio molto minimalista (ovvero solo la pagina principale, mentre
le altre vengono generate in modo iterativo) mentre altri forniscono un
modo molto flessibile per poter gestire vari layout. Tutti comunque
consentono una completa personalizzazione della grafica, anche se a
volte limitata per motivi strutturali.
In secondo luogo, tutti sembrano aver compreso come sia

fondamentale rendere il motore estensibile in qualche modo.
L’estensibilità del motore è effettivamente un punto molto importante
per soddisfare tutto il possibile ventaglio di esigenze che si possono
riscontrare. Nonostante questo, non c’è convenzione sui nomi
utilizzati: alcuni utilizzano “module”, altri “blocks”, altri ancora
“extensions” o “plugins”. Differenze che delineano anche come
notevolmente differiscano le varie implementazioni di questa
funzionalità.
2.3. Tratti distintivi: analisi dei vari motori

Nell’analisi di questo genere di strumentazioni bisogna sicuramente
considerare il target a cui esse si rivolgono. Infatti vi è una differenza
sostanziale fra uno strumento in uso presso una singola persona e
uno strumento analogo in ambito corporate (aziende di grosse
dimensioni, con notevole utilizzo di infrastrutture informatiche).
Per questo motivo ho delineato sostanzialmente quattro profili:

1. personale: il software viene usato da una singola persona per
uno scopo specifico. Raramente il carico di lavoro che dovrà
essere sopportato sarà eccessivo e possono essere usate
anche soluzioni a basso costo domestiche (i.e. blog personale,
sito personale).
2. piccolo portale: il numero di utenti che interagiscono è limitato
e non vi è la necessità di particolari accorgimenti per
l’organizzazione delle informazioni. Le interazioni degli utenti
- 13 -

con il sito sono poche o comunque occasionali (i.e. punto-

informatico).
3. medio portale: il numero di utenti che interagiscono diventa
sensibile e potrebbero essere necessari accorgimenti tecnici per
supportare il traffico sul server, oltre che avere a disposizione
banda sufficiente. E’ necessario studiare la struttura con
accuratezza per non dare senso di confusione al visitatore (i.e.
multiplayer.it).
4. grande portale: il numero di utenti che interagiscono è notevole
e lato server è fondamentale una architettura tecnica ben
studiata. Il motore deve poter sfruttare a dovere la potenza di
calcolo ed essere strutturato per gestire una notevole quantità di
interazioni al secondo (i.e. slashdot, deviantart).
Ho utilizzato il termine portale invece di sito, più generico, perché

nell’uso attuale sottintende il concetto di interazione più o meno ampia
con gli utenti, cosa che non è esplicitata dal vocabolo sito.
Escludo in questa disamina il profilo per quelli che si possono definire
portali enterprise, ovvero sistemi enormi che devono reggere un
carico notevole di lavoro, visto che solitamente sono realizzati ad hoc.
Considero in questa categoria siti come microsoft.com, ibm.com, etc.
2.3.1. PHPNuke
Questo uno dei motori più antichi e diffuso sul web. Si tratta di un
progetto nato in modo amatoriale da parte di uno sviluppatore intorno
all’anno 2000. E’ stato uno dei pionieri per quanto riguarda i sistemi
CMS opensource e per questo risulta avere un’enorme diffusione.
Il codice però è stato scritto nel 2000 con le conoscenze del periodo
dell’autore, cosa che comporta evidenti idiosincrasie strutturali e un
codice sporcato da moltissime pezze e aggiustamenti. Lo stesso
sistema a moduli risulta essere di difficile gestione (per quanto sia un
notevole passo avanti ai tempi) e facilmente intaccabile da
vulnerabilità di vario tipo.
Inoltre, dal punto di vista tecnico vi sono moltissime riscritture di
codice e la mancanza di un sistema centralizzato di gestione: vi sono
numerose tipologie funzionali (index, blocks, admin, moduli, …) ed
- 14 -

ognuna utilizza un differente host per lavorare, sebbene non vi sia

una necessità concreta.
Estendere questo motore risulta semplice quanto programmare uno
script separato se non si fa utilizzo di alcuna funzionalità interna, ma
diventa molto intricato quando si cerca di integrare il tutto.
Questo motore è fondamentalmente nato per la gestione di siti
personali e piccoli portali, ma a volte arriva, grazie a qualche team di
sviluppo, anche all’affidabilità necessaria per portali di medie
dimensioni, pur non raggiungendo l’idoneità completa a questo scopo.
Dal punto di vista

dell’interfaccia pubblica il
programma non consente
grosse variazioni, a partire
dalla struttura base costituita
da intestazione e tre
colonne. Allo stesso modo
tutti i moduli creabili per
questa piattaforma soffrono
di forti limiti e raramente
sfoggiano un sistema di
interazione con l’utente ben studiato.
A parte la divisione su tre colonne e in blocchi, il motore non offre
molte altre possibilità integrate per l’organizzazione dei contenuti: la
navigazione in profondità e la gerarchia del sito è demandata
unicamente al modulo che
sta gestendo in quel
momento il corpo del sito.
Per la parte amministrativa

la sensazione generale è di
caos, problema che si
accentua anche grazie al
fatto che i moduli sono
sviluppati da persone
diverse e spesso utilizzano
- 15 -

paradigmi e logiche differenti.

Il menu stesso di gestione si riduce ad una mera elencazione di varie
funzionalità e moduli.
Il target di questo motore è l’uso personale o di piccolo portale:
salendo con il numero di utenti la struttura inizia a far sentire le sue
debolezze
PostNuke rappresenta l’evoluzione di PHPNuke da parte di uno staff

differente di sviluppatori, che ha preso il progetto originale portandolo
avanti, ma permangono le logiche strutturali risalenti all’originale:
questo garantisce che tutti i moduli scritti per il progenitore funzionino
ancora, ma inficia il risultato finale nel suo complesso.
2.3.2. Xoops
Questo è un programma di gestione per portali di piccole o medie
dimensioni, e persegue il fine parallelo di essere un CMS (come loro
stessi spiegano nei dettagli del loro progetto). Sfrutta il concetto di
modularità, essendo questo un paradigma fondamentale per
garantire la crescita e la gestione dei sistemi complessi.
L’installazione prepara un
sistema vuoto (versione 2.2)
che può essere ampliato
scaricando dal sito ufficiale
altri moduli in modo da avere
a propria disposizione solo le
parti che si sono scelte per
gli scopi specifici del sito. Al
contrario la versione 2.0
fornisce un pacchetto già
contenente alcuni moduli, in
modo da poter partire fin da subito con un set minimo di feature.
Il sistema di amministrazione varia leggermente come interfaccia nelle
due ultime versioni scaricabili (2.0 e 2.2), passando da un menu
- 16 -

verticale con popup a un menu orizzontale, che mi è sembrato meglio

organizzato.
In entrambi i casi, il motore
e le estensioni native
risultano avere una
interfaccia piuttosto
spartana, con una
attenzione probabilmente
più all’aspetto della
programmazione che non a
quello dell’usabilità. Aspetto
che comunque potrebbe
essere personalizzato in
parte tramite un sistema di themes (templates) che ne ridefiniscano la
grafica.
Dal punto di vista dello sviluppo, i vari moduli sono strutturati piuttosto
bene, ma non vi è un sistema trasparente per farli interagire fra di
loro. Si possono usare unicamente le classi native (“core”) di Xoops e
non vi è un sistema per astrarre e condividere funzioni fra i vari
moduli.
Utilizza una logica object oriented per molte parti del motore, tenendo
un sistema misto per altre parti (funzioni, codice inline), probabilmente
a causa di una precisa scelta di architettura unitamente ai limiti
imposti da PHP 4.
L’utilizzo di Smarty come motore per i template è inoltre una buona
scelta, in quanto è un componente di Pear, la libreria pubblica di
classi per PHP, forse il migliore in quanto a personalizzazione e
velocità.
In definitiva Xoops è un sistema più giovane di PHPNuke, si fonda su

basi meglio pensate e con un continuo rinnovo (anche guardando la
roadmap questo è evidente), con l’idea di mantenere la compatibilità,
ma senza sacrificare l’evoluzione del motore stesso.
- 17 -

2.3.3. Mambo
Questo sembra un tool
orientato ad una fascia di
utilizzo più professionale:
Mambo si offre infatti come
strumento aziendale e
quindi presuppongo sia
orientato ad un carico di
lavoro piuttosto elevato.
L’interfaccia è meglio
strutturata dei precedenti,
con un sistema di
amministrazione separato dal sito effettivo, organizzato tramite una
barra orizzontale a menu, ognuna per una specifica categoria
funzionale del motore.
Mambo sembra presentarsi con una struttura a contenitori,
caratteristica comune sia a PHPNuke che a Xoops, ma utilizza una
nomenclatura specifica differente dagli altri. Ha Modules e, in più
strutture chiamate Mambots e Componente, a mio avviso, rischia di
rendere troppo complessa l’interazione con l’utente e di rendere la
curva di apprendimento piuttosto bassa, in quanto, prima di poterlo
utilizzare, bisogna capire tutte le nomenclature che questo motore
introduce.
Questo è evidente durante la programmazione di una di queste parti
per ampliare le funzionalità di Mambo, programmazione che quindi
rischia quindi di essere un po’ dispersiva.
L’interfaccia è comunque
ben strutturata e curata in
molti dettagli anche minori,
ma probabilmente non è
stata realmente pensata con
il concetto di usabilità in
mente: ad esempio c’è una
distinzione fra l’interfaccia di
amministrazione generica e
- 18 -

il pannello di gestione di un singolo elemento, ma non è sensibile il

passaggio dall’una all’altra, cosa che disorienta l’utente. Questo
risulta essere piuttosto problematico, poiché vi è nativo un sistema di
lock (se un amministratore sta modificando qualcosa, viene segnalato
con un lucchetto).
E’ in definitva un CMS molto completo e abbastanza efficace, poiché
risulta piuttosto solido ed estensibile in molti modi.
2.3.4. Drupal
Questo è un framework più che un CMS, piuttosto recente, che
sembra essere una sorta di versione più complessa di un motore per
blog.
Appena installato appare
piuttosto spartano nelle
funzionalità, con una
interfaccia pulita ed
essenziale. Questo ha come
risultato che si riesce ad
usare in un tempo molto
ridotto il motore e le sue
funzionalità.
Inoltre non vi è una reale
separazione fra la parte di
amministrazione e quella pubblica: l’interfaccia è la medesima e le
opzioni gestionali appaiono all’utente loggato con i diritti corretti
tramite un menu.
Come accennato, risulta
essere qualcosa più di un
motore per blog: di base
offre tutta una serie di
funzionalità che servono
per ottenere questo scopo,
ma il motore è ampliabile
tramite dei moduli
scaricabili in modo da poter
personalizzare tutto
- 19 -

secondo le proprie necessità. In effetti Drupal è la base sulla quale

Tipic ha sviluppato il suo servizio di blog: splinder.com.
Fra tutti Drupal grazie anche ad un inizio piuttosto essenziale ed ad
una interfaccia piuttosto ben strutturata, risulta essere forse il più
veloce in assoluto da imparare ad usare.
Un difetto che presenta Drupal è forse proprio il suo maggiore pregio:
il motore è piuttosto immediato da usare e gestire a discapito della
complessità strutturale: i template e i moduli sono piuttosto semplici e
non forniscono molti servizi e componenti per integrare il codice.
E’ forse la scelta migliore con poco tempo da dedicare all’aspetto
tecnico per siti di piccole e medie dimensioni, grazie alla sua
semplicità.
2.3.5. WordPress
Pur non essendo un CMS o un Framework in senso stretto,
WordPress è un motore piuttosto interessante. La sua funzione
primaria è quella di gestire blog, ma essendo un motore estensibile
risulta essere facilmente ampliabile per coprire una vasta gamma di
funzionalità.
E’ interessante perché,
seppure orientato ad un fine
preciso (ovvero il blog),
riesce ad essere
sufficientemente flessibile in
modo da adattarsi senza
problemi ad una notevole
varietà di utilizzi.
Inoltre, poiché è
primariamente un motore per
blog è stato accuratamente
studiato per essere molto efficace in questo senso avendo una
interfaccia semplice e immediata, che lo rende facilmente usabile.
Il sistema di plugins peraltro non è strutturato in modo tradizionale:
invece di essere un blocco funzionale separato, usa un corpo di
codice che tramite degli hook si aggancia al motore WordPress
- 20 -

ampliandone le
funzionalità in modo
uniforme, nel modo e luogo
dove serve.
Dal punto di vista della
presentazione, del layout e
della gerarchia, tutto è
semplificato in modo da
essere gestito tramite il
template e, modificando
questo, si personalizzano
le pagine che l’utente vedrà.
L’approccio è piuttosto semplicistico e necessita la conoscenza dei
linguaggi per il web come HTML e CSS, più qualche tag PHP, ma
risulta essere piuttosto veloce e immediato per chi ha un minimo di
conoscenza nel campo, mentre utenti generici possono comunque
utilizzare WordPress senza però andare a cambiare queste
componenti.
- 21 -

3 . R e q u i s i ti d e l s i s t e m a p h pG ol e m
Il motore che è stato realizzato è stato progettato partendo da alcuni

principi fondamentali che ne definiscono gli scopi.
Possiamo quindi considerare phpGolem come un framework
estensibile per applicazioni web, orientato verso la realizzazione di
content management system.
3.1. Linee guida

Possiamo sintetizzare i principi che caratterizzano i cardini intorno ai
quali è stato progettato il sistema e gli obiettivi che sono stati
perseguiti:
1. Estensibilità
Le funzionalità raramente sono fisse e comuni a tutti gli scopi da
raggiungere data l’immensa varietà di usi e applicazioni che può
avere il prodotto destinato al web.
Per questo motivo è stata scelta una via che minimizzi un
nucleo centrale di operazioni e che fornisca
contemporaneamente una solida base su cui costruire e
aggiungere funzioni in modo semplice ed intuitivo.
Questa idea di base, fulcro del motore, garantisce anche che il
programma scali bene, in proporzione alle necessità: un sito
semplice caricherà poche estensioni risultando quindi molto
snello e leggero. Al crescere delle necessità aumenterà anche il
numero di componenti utilizzate: il carico di lavoro risulta quindi
essere proporzionale alle necessità.
2. Flessibilità
Tanti sono i software per il web che forniscono una mole molto
valida di funzionalità, ma peccano di un requisito spesso
fondamentale, ovvero la flessibilità.
- 22 -

In questo caso la flessibilità è garantita dal perseguimento

dell’obbiettivo della separazione della logica dalla
presentazione. In questo modo il motore si adatta perfettamente
a qualunque layout grafico venga utilizzato, senza doversi
limitare ad un preciso stile.
Questo significa lasciare liberi i designer di scegliere la migliore
architettura per il sito ed il migliore layout visuale senza per
questo dover sacrificare funzionalità, o viceversa.
3. Semplicità di sviluppo
Dato che il punto chiave è fornire un sistema semplice e
immediato, facile da gestire e da potenziare, è cruciale che sia il
più possibile agevole per uno sviluppatore aggiungere parti
assecondando le necessità dell’applicazione che si va a creare.
Quindi ogni estensione del motore è ben separata da ogni altra:
questo consente ad ogni sviluppatore di utilizzare il proprio stile
di programmazione senza dover pensare a come è stato
realizzato il resto.
Garantire strumenti per creare una estensione ben integrata,
semplificando operazioni ripetitive e lasciando libertà al
programmatore di scegliere lo stile di sviluppo che più gli è
consono risulta quindi rilevante.
4. Semplicità di uso
Bisogna però sempre tenere il riferimento costante all’utente
finale. Rendere un software strutturato facile ad usarsi non è
una impresa così semplice, soprattutto tenendo in
considerazioni le limitazioni del web stesso.
Quindi è importante tenere sempre come riferimento linee guida
di utilizzo, soprattutto nel backend gestionale (backoffice) in
modo che mantenere un sito operativo non richieda personale
specializzato (al più, solo per le operazioni più critiche o
radicali).
5. Riuso
Il motore deve essere strutturato il più possibile per garantire
che le estensioni al suo interno possano comunicare e utilizzare
vicendevolmente le operazioni che ciascuna di esse fornisce.
- 23 -

Di conseguenza, pur lasciando libertà allo sviluppatore, il

motore è strutturato per favorire questo processo, facendo in
modo che ogni estensione possa esportare le proprie librerie e
classi così che siano disponibili in caso di necessità.
Per queste motivazioni è stato scelto il nome “golem”, con il prefisso

“php” di uso comune a tutti gli applicativi che si basano su questo
linguaggio: phpGolem.
Il golem è una creatura realizzata per mano dell’uomo, creato
assemblando più parti distinte e con lo scopo di aiutare il proprio
padrone: esattamente quello che fa questo motore, utilizzando
differenti estensioni per poter fornire un servizio preciso.
Il motore è sviluppato integralmente in lingua inglese per garantirne la

più ampia diffusione, ma dispone di una struttura tale da garantire la
possibilità di localizzazioni.
3.2. Tipologie di utenti

La progettazione del motore dal punto di vista dell’interazione e
dell’interfaccia tiene conto delle seguenti figure:
1. Framework developer
2. Framework user, o web builder
3. Backoffice user
4. Public site user
Queste sono state delineate in modo da avere sempre come
riferimento il tipo di utilizzo che verrà fatto dalle varie tipologie di
utente.
3.2.1. Framework developer

Il framework developer è una persona che si trova a dover sviluppare
su questo motore. E’ una persona che conosce PHP ad un livello
intermedio (almeno fino all’uso e all’instanziazione di classi). Egli avrà
la necessità di creare rapidamente una nuova estensione.
- 24 -

Ha bisogno quindi delle conoscenze base su come realizzare

l’extension ed eventuali spiegazioni su come funziona la struttura
stessa del motore, nel caso debba integrare il suo programma con
altre componenti.
Dato che conosce già il linguaggio che intende utilizzare, va sul sito
ufficiale per trovare le informazioni necessarie per poter iniziare e
portare avanti il proprio lavoro. Vuole mettersi al lavoro nel minor
tempo possibile senza dover imparare sintassi nuove, anche se
probabilmente in futuro potrà aver bisogno di alcune librerie interne di
phpGolem.
3.2.2. Framework user

Il framework user è la persona che utilizza phpGolem e tutte le
estensioni necessarie per poter realizzare un sito web. In questa
figura rientrano web administrator, web master ed eventualmente il
web designer.
Questa figura necessita di conoscere le modalità di configurazione e
uso delle estensioni che verranno inserite nel sito web che deve
creare o gestire, non è quindi richiesta alcuna conoscenza
programmativa.
Cerca quindi nella documentazione la spiegazione di come è
strutturato il motore dal punto di vista operativo per poterlo
organizzare secondo le sue necessità.
Tutte le operazioni sono svolte nella parte di amministrazione, mentre
viene a tratti aperta l’interfaccia pubblica per controllare il risultato del
proprio lavoro.
3.2.3. Backoffice user

Questo utente utilizza giornalmente alcune funzioni specifiche. E’ ad
esempio un editor dei contenuti che riporterà tutte le notizie sul sito
stesso. Questa persona non ha alcuna conoscenza tecnica e non ha
intenzione di imparare nulla di nuovo per poter lavorare. I suoi
strumenti sono semplici ed intuitivi e focalizzati sull’operazione che
deve svolgere.
Nella parte di backoffice (amministrazione) vede solamente le parti
specifiche al proprio ruolo e nient’altro che lo possa confondere.
- 25 -

Potenzialmente, l’orientamento di questa parte del lavoro è di tipo

semantico: l’organizzazione di eventuali articoli è in base al loro
significato e questo è indipendente dalla posizione gerarchica nel sito
finale.
3.2.4. Public site user

L’utente generico giunge sul sito volendo trovare informazioni nel
minor tempo possibile. Egli non è interessato a tecnicismi, quindi il
motore deve essergli nascosto. La grafica e il layout sono studiati ad
hoc nel progetto del sito per uno scopo specifico e deve essere quindi
garantita la massima flessibilità in questo senso.
Tutte queste tipologie di utenti sono tenute in considerazione nella

realizzazione del progetto con pari priorità, rappresentando ciascuna i
diversi livelli operativi ai quali è destinato il prodotto.
3.3. Requisiti di architettura

Le fondamenta di phpGolem poggiano su un sistema che deve
basarsi sul concetto di estensibilità.
E’ quindi fondamentale fornire un sistema che sia verticalmente
efficiente per la singola funzionalità operativa e contemporaneamente
consenta una comunicazione orizzontale fra le varie altre componenti
del software.
Il nome phpGolem definisce propriamente il framework e quindi un

nucleo di classi e oggetti che gestiscono l’intera struttura.
Il framework stesso deve quindi fornire un sistema per inserire e
coordinare funzionalità aggiuntive, fornendo contemporaneamente
alcuni classi e oggetti per gestire le funzionalità base che un sito web
dinamico potrebbe richiedere.
Queste funzionalità base sono:
• Gestione del database
• Gestione delle estensioni
• Gestione degli utenti e delle autorizzazioni
• Gestione dell’architettura del sito
- 26 -

• Gestione della grafica del sito (tramite templates)

• Gestione dei files e delle cartelle
Queste funzionalità sono quindi fornite come classi contenenti

solamente logica (nessuna interfaccia trattandosi di un framework)
più un elemento che gestisce il flusso di esecuzione delle componenti
per la generazione della pagina finale.
Nel caso di phpGolem si è pensato al concetto di estensione come di

un elemento che va ad inserirsi su una struttura base. Il vocabolo è
stato scelto per essere il più possibile di facile comprensione:
“estensione” (extension) è infatti lo stesso termine che usa il noto
browser web Mozilla Firefox e quindi dovrebbe essere un termine di
vasta diffusione.
Si è preferito questo vocabolo al posto di un forse più chiaro “plugin”
perché mentre il plugin è concepito come un elemento esterno che
aggiunge una funzionalità, al contrario l’estensione è qualcosa di
perfettamente integrato nel sistema.
L’estensione inoltre è pacchettizzata, questo significa che tutte le

parti che convergono a svolgere un preciso compito siano concentrate
e ben separate dal resto del sistema.
Un altro vantaggio che si ottiene è garantire una separazione dal
punto di vista dello sviluppo. In questo modo è possibile lavorare
separatamente su diverse estensioni senza per questo inficiare
l’intero sistema o impedire la programmazione di altre parti.
Infine la pacchettizzazione consente al sistema di gestire l’estensione
come un singolo elemento, e rende più semplice la distribuzione e
l’installazione.
Inoltre le estensioni devono essere abbastanza flessibili al loro

interno per consentire varie tipologie di programmazione, in modo da
adattarsi meglio allo scopo per cui vengono sviluppate.
Per questo è possibile inserire nell’estensione non solo il componente
base per la gestione dell’interfaccia, ma anche classi e oggetti per
gestire la logica o files contenenti la presentazione e la grafica.
- 27 -

Sono cioè fondamentali per perseguire i fini di flessibilità, la

separazione della logica dalla presentazione e contemporaneamente
il fornire un livello ottimale di interazione fra i vari componenti.
3.4. Requisiti di usabilità e interfaccia

Il livello utente è costituito da due interfacce separate e chiaramente
distinte. Una interfaccia è pubblica, accessibile a tutti e realizzata dal
web designer per soddisfare i fini del sito che verrà progettato. Una
seconda interfaccia è invece privata e costituisce la parte gestionale
del sito stesso, ovvero le pagine di amministrazione.
La parte pubblica varia quindi da sito a sito e non è nostro interesse
ora valutarla (verrà fatto nella parte di sperimentazione), mentre
quella privata deve essere disegnata durante la realizzazione del
motore CMS e quindi va pensata in sede di progettazione.
Dopo una prima pagina dove si effettua il login per l’identificazione, la

parte di amministrazione dovrà essere quindi in grado di indirizzare in
modo rapido l’utente (se ha diritti di accesso) alle funzionalità di cui
ha bisogno.
La pagina è quindi strutturata in modo da separare visivamente la

parte di navigazione (in nero) dalla pagina sulla quale si sta
operando (in bianco).
La parte di navigazione dispone quindi di due livelli di navigazione: il

primo è un menu verticale posizionato sul lato sinistro, sintetizzante
ciascuna voce con un vocabolo che chiarifica la parte della gestione
alla quale si può avere accesso.
In particolare, il raggruppamento delle varie opzioni del menu è
realizzato in modo da unire assieme varie funzionalità che assolvono
a compiti comuni.
Il secondo livello è espresso tramite una barra orizzontale opzionale
che varia contestualmente alla pagina visualizzata (ovvero alla voce
di primo livello selezionata). Per garantire una certa uniformità di
- 28 -

navigazione il primo pulsante su tale barra è costituito dal link “Back”

(indietro) per fornire all’utente un elemento fisso per tornare alla
pagina precedente indipendentemente dall’operazione che si sta
conducendo.
Ogni voce del menu di primo livello accede a parti del motore che non
sono necessariamente state scritte coordinatamente a phpGolem
stesso (estensioni, vedi più avanti), quindi è importante rifarsi a una
guideline coerente.
La prima pagina di ciascuna voce del menu deve fornire un riassunto
visivo dello stato attuale del sistema per quanto riguarda quella
specifica funzionalità.
Nella barra orizzontale di navigazione andranno definiti i vari pulsanti
per eseguire varie operazioni riguardanti la pagina su cui siamo.
Se fosse necessario poter effettuare ricerche o selezioni di vario
genere sugli eventuali elementi gestiti è consigliabile inserire in cima
alla pagina un campo per poter effettuare queste operazioni. Una
funzionalità di questo tipo è sempre consigliata nel caso di elementi
che si pensa potrebbero venire gestiti in grande numero.
L’inserimento e la modifica degli elementi andrebbero fatti in modo

coerente con una stessa interfaccia sia per l’inserimento che per la
modifica, in modo da mantenere l’uniformità e ridurre la possibilità che
l’utente possa venire spaesato.
Nel caso di liste contenenti svariate voci, uniformi o comunque

facilmente confondibili, è anche consigliabile l’utilizzo di una leggera
zebratura sulle righe dell’elenco.
3.5. Requisiti tecnici

Per la realizzazione del motore sono stati
scelti i due componenti opensource più
diffusi ad oggi nella rete:
- PHP 4.3 o superiore
- MySQL 4.0 o superiore
- 29 -

Questa scelta è dovuta al fatto che PHP 4 risulta tuttora la versione

più diffusa di questo linguaggio di scripting. Al contrario PHP 5,
seppure portatore di notevoli innovazioni, è ancora un linguaggio
giovane.
Vi è inoltre un motivo non essenziale, ma comunque da tenere in
considerazione: PHP 4 supporta nativamente MySQL, mentre nel
caso di PHP 5 è un modulo che deve essere attivato.
La versione attualmente in sviluppo è quindi PHP 4.3.11. Data la

compatibilità di PHP 5, passare a questa versione del linguaggio di
scripting non comporta praticamente alcun ostacolo né differenza di
utilizzo.
MySQL è storicamente l’accoppiata ideale per PHP 4 e quindi

raramente si vedono questi due programmi disaccoppiati.
Inoltre, questi due componenti sono installabili su qualunque

piattaforma in modo semplice: su Microsoft Windows, GNU/Linux,
Apple OS X, etc, sia su server Apache che IIS, garantendo una
notevole diffusione.
- 30 -

4 . A r ch i t e t t u r a g e n e r a l e d e l s is t e m a
In ogni progetto di una certa dimensione è fondamentale progettare la

logica e l’architettura del sistema in astratto, prima ancora di passare
a qualunque dettaglio implementativo.
Vediamo quindi in questo capitolo come è stato progettato phpGolem,

sulla base delle riflessioni e dei requisiti definiti nei capitoli
precedenti.
4.1. Architettura
Il sistema come abbiamo detto è un framework: questo significa che
fornisce un livello astratto e separato sul quale le applicazioni web
possono essere costruite.
Questo livello contiene una serie di classi per la gestione semplificata
di molti degli aspetti che si ritrovano nella maggior parte degli
applicativi web, come la gestione degli utenti, del database o della
grafica.
Oltre a fornire questi elementi primari, il framework incorpora

nativamente un sistema per la gestione di pacchetti software,
denominati estensioni. Queste costituiscono il modo più efficiente di
sviluppare applicazioni web su phpGolem e forniscono
contemporaneamente, un sistema logico per raggruppare funzionalità
omogenee.
Quindi questa struttura si va a definire su tre livelli fondamentali, che

si orientano da un livello di astrazione maggiore ad uno minore:
1. Estensioni, ovvero gli elementi che realizzano le applicazioni
sul motore e implementano l’interfaccia.
- 31 -

2. Framework, il livello dove viene gestito il caricamento e

l’interazione delle estensioni, fornendo contemporaneamente
una serie di funzioni utili.
3. Filesystem e Database, ovvero la struttura fisica sulla quale
poggia il framework. Da questo livello vengono prelevati i dati
grezzi per essere elaborati o trattati dal programma.
- 32 -

Questo schema delinea la struttura del motore in modo generale,

andando a disporre i vari blocchi logici come una struttura ordinata di
elementi che si basano l’uno sull’altro.
Il filesystem e il database sono ovviamente il più basso livello

possibile su cui lavorare: il framework si pone al di sopra di questo,
semplificando operazioni su queste due fonti dati grezze ed astraendo
in classi ed oggetti le funzionalità.
Sul framework si appoggiano tutte le estensioni, che vengono create
sul livello sottostante e vengono fatte interagire e funzionare nel modo
corretto.
Dopo questa visione generale della struttura, andiamo ad osservare i

vari livelli secondo un approccio bottom-up.
4.2. Database
Separiamo per una disamina più dettagliata il livello più basso nelle
sue due componenti principali: Files e Database.
Lo schema del database necessario al framework per funzionare è

costituito da un gruppo di tabelle, con nomi prefissi dalla stringa “g_”
(completamente personalizzabili), che vengono utilizzate dalle varie
classi del core per memorizzare informazioni e impostazioni.
Visto che ogni tabella o gruppo di tabelle è connessa ad una funzione

specifica, le analizzerò in base a questo tipo di logica.
- 33 -

4.2.1. Gestore web multisito (web, setup)

Una parte del motore che funziona automaticamente è quella che
gestisce l’installazione e l’inizializzazione di un sito web. Il motore
phpGolem è infatti stato creato tenendo a mente la possibilità che più
siti possano essere installati su un server utilizzando lo stesso
database. Per questo motivo esiste una classe nel framework che
associa il nome identificativo del sito (impostato nel file di
configurazione) ad un ID memorizzato in una tabella, che viene
utilizzato da tutte le estensioni per tenere separati i dati specifici per i
diversi siti web.
Lo schema della tabella web è il seguente:
web
wid int (key)
idname varchar(50)
Name varchar(255)
URL varchar(255)
Enabled int
Description varchar(255)
Date date
Time time
IP varchar(15)
Questa tabella è stata progettata in modo da tenere traccia

dell’associazione nome e id corrispondente (wid), aggiungendo dei
dati facoltativi in modo da poter identificare più facilmente un sito
web. Inoltre viene anche registrata la data di attivazione.
Il campo wid è utilizzato in modo uniforme su tutto il database in

modo da identificare univocamente uno specifico sito web.
La funzione di questa tabella è naturalmente molto più rilevante nel

caso della gestione di più siti con una unica base dati. Inoltre
utilizzando un indice numerico al posto di una stringa all’interno delle
- 34 -

tabelle è consentito un notevole risparmio di spazio e una migliore

velocità di ricerca durante le query.
E’ da sottolineare che questa funzionalità di gestione separata è

studiata in modo da consentire una struttura centralizzata parziale:
l’utilizzo del parametro wid ($WEB_ID nel codice) è facoltativo per le
estensioni e questo consente la creazione di siti contenenti sia
componenti strettamente separate sia parti comuni gestite in
simultanea su tutti i siti.
Ad esempio è possibile creare un motore di ricerca che effettui la
scansione sull’intero database, sapendo poi distinguere la fonte da cui
una singola voce è stata prelevata.
Oppure è possibile registrare gli utenti globalmente, mentre i diritti di
questi son assegnati localmente.
Inoltre, quando la tabella in questione non viene rilevata, il gestore

web carica in memoria un oggetto che compie il setup del sito,
inizializzando le tabelle e configurando il primo avvio.
4.2.2. Gestore estensioni (ext)

La gestione delle estensioni viene realizzata da un oggetto che fa
uso della seguente tabella
ext
extid int (key)
wid int
Extension varchar(20)
Name varchar(20)
FileName varchar(50)
Path varchar(255)
Mode smallint
Sort int
Questa contiene tutti i dati necessari alla gestione delle estensioni

che sono state attivate e che quindi sono operative sul sito web.
- 35 -

E’ importante notare che questa tabella non memorizza le estensioni

nel senso risretto del termine, ma dispone una tupla per ogni classe
PHP che l’estensione possiede e istanzia, in modo da avviarle
dinamicamente in fase di runtime.
Questo comportamento verrà comunque spiegato nella parte
riguardante l’architettura delle estensioni.
Inoltre per garantire flessibilità al codice e al motore stesso vengono

memorizzati i files in modo da tenere traccia del path relativo rispetto
alla root del sito: sebbene quindi le estensioni siano progettate per
essere poste in una precisa locazione, queste possono essere in
realtà eseguite da qualunque directory.
Oltre ai dati essenziali è rapidamente riconoscibile la chiave wid

riguardante l’identificativo del sito web in esecuzione: siti differenti
che si appoggiano alla stessa base dati possono quindi caricare e
gestire in modo indipendente le estensioni.
Il campo sort infine è una colonna che si può utilizzare se una

estensione ha deve essere avviata prima di un’altra dal motore, in
modo da garantire la priorità di esecuzione.
4.2.3. Gestione utenti, gruppi e diritti (user, auth)

La parte di gestione degli utenti risulta essere quella più complessa
da un punto di vista del database, in quanto ogni utente è relazionato
sia ai gruppi a cui appartiene sia ai diritti che possiede.
Per questo motivo sono necessarie ben cinque tabelle: users, rights,
groups, r2ug, u2g, che definiscono al loro interno gruppi, utenti, diritti
e le interconnessioni fra gli stessi.
- 36 -

users
uid int (key)
User varchar(32)
Pass varchar(32)
Nick varchar(50)
EMail varchar(60)
Note varchar(80)
SessionHash varchar(32)
LastLogin datetime
La tabella users (utenti del sito) memorizza tutti i dati di registrazione

dell’utente, in forma minimale: questo perché si è preferito progettare
una base dati ridotta sotto questo aspetto, eventualmente ampliabile
tramite una estensione che a questo punto può costruire una JOIN fra
le due (o più) tabelle.
Inoltre vi è distinzione fra i dati di login (user/pass) ed il nome

utilizzato dal motore pubblicamente, che invece è memorizzato nella
cella Nick. Questo garantisce la possibilità da parte degli utenti di
cambiare il proprio nick visualizzato senza dover mutare i dati di
registrazione.
L’e-mail è memorizzata per realizzare possibili controlli durante la

creazione dell’account, oppure per mandare successivamente
segnalazioni.
Gli ultimi due campi sono utilizzati dal motore e non sono modificabili
direttamente: SessionHash memorizza un hash MD5 variabile che
viene utilizzato per l’identificazione univoca dell’utente, in modo da
aumentare la sicurezza.
LastLogin invece è un semplice campo che viene aggiornato
all’ultima data ed ora di visita di quel preciso utente.
- 37 -

groups
gid int (key)
wid int
Name varchar(30)
La tabella dei gruppi non richiede molti dati, è sufficiente il nome ed

una eventuale descrizione. Ma è importante sottolineare che mentre
gli utenti sono globalmente disponibili a tutti i siti che usano lo stesso
db, i gruppi sono indipendenti (è utilizzato il campo wid).
rights
rightid int (key)
wid int
Extension varchar(20)
Key varchar(20)
Values tinyint
La tabella dei diritti viene gestita in modo consistente con le

estensioni: ogni diritto appartiene infatti ad una specifica estensione,
per questo motivo ne è esplicitato il nome.
Il campo Key è quindi una stringa che definisce il tipo di diritto che
quella estensione utilizza. E’ importante notare che al momento
dell’attivazione di una nuova estensione viene creato un diritto base
con campo Key vuoto, che rappresenta il minimo livello di
autenticazione per l’accesso al componente appena inserito.
Il campo Values è infine utilizzato per impostare che tipologia di diritti

è possibile assegnare. Si tratta infatti di una flag che definisce che
tipo di selezione mostrare: il default è 2, ovvero due valori fra cui
scegliere che saranno quindi “consentito” e “vietato”.
Infine vi sono le tabelle che gestiscono le relazioni: la prima fra utenti

e gruppi (u2g) mentre la seconda fra diritti e utenti o gruppi (r2ug).
- 38 -

u2g
ugid int (key)
uid int
gid int
Questa tabella è di comprensione piuttosto immediata: associa utenti

con gruppi, in un rapporto di molti a molti.
r2ug
rugid int (key)
rightid int
uid int
gid int
Level tinyint
Questa tabella associa un utente o un gruppo con un diritto. Si è

realizzata una tabella unica per entrambi in modo da non disperdere
troppo i dati per una operazione semplice come questa: nel caso di un
gruppo, il campo uid sarà zero, il contrario nel caso di un utente.
E’ importante notare come r2ug memorizza anche un livello di

accesso per uno specifico diritto (Level). E’ infatti possibile
specificare una scala numerica quando una estensione utilizza un
diritto, in modo da realizzare una maggiore granularità.
4.2.4. Gestione dell’architettura del sito (arch)

La gestione dell’architettura del sito è affidata ad un componente del
framework piuttosto complesso che genera una struttura gerarchica di
layouts all’interno dei quali vengono effettuati dei collegamenti con dei
moduli pubblici delle estensioni (vedremo poi meglio più avanti il
funzionamento).
I primi sono gestiti dalla tabella arch, i collegamenti da arch_binds.
- 39 -

arch
archid int (key)
parentarchid int
wid int
Ref varchar(30)
Template varchar(255)
SubTemplate varchar(255)
Type tinyint
Qui si nota un campo autoreferenziale che è parentarchid, in modo da

poter costruire una gerarchia su n livelli di tuple, che corrispondono ai
layout possibili.
Il campo Ref è invece utilizzato per richiamare lo specifico layout e
renderlo operativo: va infatti a corrispondere con il campo l (L
minuscola) nella querystring dell’URL.
I due campi Template e SubTemplate definiscono quale grafica deve
essere utilizzata sulla pagina, mentre il campo Type specifica se si
tratta di un layout normale o di quello di default (esisterà quindi una
sola chiave con valore 1), ma è stato denominato in questo modo per
rendere possibili anche future evoluzioni.
arch_binds
archbindid int (key)
archid int
Tag varchar(64)
x varchar(20)
fx varchar(64)
Param varchar(128)
Access tinyint
La tabella collega ogni archid a molte tuple, ognuna contenente un

riferimento ad un Tag specifico esistente nel layout specificato in
arch.
Questo viene quindi posto in relazione con un modulo pubblico di una
estensione (x, fx, rappresentano estensione e funzione): questa parte
verrà spiegata più avanti quando si delineerà la parte di architettura.
- 40 -

Il campo Param è utile per aggiungere delle variabili di configurazione

aggiuntive al modulo che si dovrà poi chiamare a runtime.
E’ indicato anche un campo Access per specificare il grado di

visibilità che il modulo in questione avrà: ad esempio potrà essere
reso visibile solamente agli utenti registrati, per visualizzare una
scritta con i messaggi ricevuti.
4.2.5. Gestione della configurazione (config)

Un’altra parte del framework è dedicata alla gestione di un sistema
globale di configurazione, in modo da disporre di un luogo condiviso
da tutte le estensioni per salvare singole variabili.
config
keyid int (key)
wid int
x varchar(20)
Key varchar(64)
Value varchar(128)
DefValue varchar(128)
OptValue varchar(128)
La tabella memorizza il sito a cui corrispondono queste variabili (wid):

essendo le estensioni dipendenti dal sito in cui girano, anche le
variabili corrispondenti devono esserlo.
Il campo x costituisce il nome interno dell’estensione alla quale è
associata una Key, in modo analogo ai diritti, contenente il nome del
valore di configurazione.
I tre campi successivi servono all’assegnazione del valore: il primo,

Value, definisce il valore attuale della variabile di configurazione,
DefValue il suo valore di default, mentre OptValue contiene una
stringa speciale utilizzata per realizzare un elenco di possibilità
alternative fra cui scegliere.
- 41 -

E’ autoesplicativo il campo Description, che spiega lo scopo della

variabile di configurazione a cui appartiene.
4.3. Filesystem
Questo livello include sia la strutturazione del framework sul sito web,
sia i files che questo utilizzerà durante il suo funzionamento.
La struttura rispecchia, con alcune aggiunte, gli insiemi definiti

nell’architettura generale. Abbiamo infatti tre directory che contengono
i tre livelli sopra esposti.
1. ext, contenente tutte le estensioni
2. golem, contenente tutti i files di funzionamento del framework
3. files, contenente tutti i files che potranno essere utilizzati
durante il funzionamento
In aggiunta a queste parti fondamentali è necessario organizzare

anche altri elementi, per motivi tecnici e di semplificazione della
gestione.
Ad esempio, è necessaria la presenza di un file indice (index.php)
che avvii il file default per la gestione (golem.paginator.php) e che
quindi si occupi di avviare tutta la procedura di generazione della
pagina.
E’ anche necessario un modo per accedere alla pagina di

amministrazione che, per motivi di semplicità, in questo caso è una
sottocartella denominata admin: questo per semplificare la
digitazione dell’URL da parte di un utente.
- 42 -

Sono anche state separate due funzionalità

che a rigor di logica potrebbero essere
incluse nella sottocartella files. Il motivo è
fornire una maggiore prominenza a queste
parti che sono di maggiore importanza per
l’utente che deve gestirle.
La prima è la cartella templates che
contiene, separatamente, tutti i layout e le
grafiche utilizzabili a runtime dal motore, in
modo da averle a disposizione con
immediatezza e facilità.
La seconda è la cartella pages, che fornisce
un modo semplice per realizzare pagine
statiche e renderle disponibili all’interno del
motore.
E’ importante notare che queste ultime due

cartelle sono spostabili e modificabili,
assieme ad altri dati, da parte del file di
configurazione (_globals.php), il quale, fra
le varie cose, contiene il nome del sito e i
fondamentali dati di connessione al
database.
E’ quindi essere possibile unificarle spostandole sotto la directory dei
files.
4.4. Framework
Il framework è l’aspetto più importante di tutto il sistema. In questo
caso si tratta di un insieme di classi che collaborano fra di loro e
offrono una serie di funzionalità, solo dal punto di vista logico.
Infatti nessun componente ha mai la possibilità di un output diretto
verso l’utente, che viene invece gestito, come vedremo più avanti,
tramite le estensioni.
- 43 -

Unica eccezione è lo script di generazione pagina, che dato il suo

scopo molto particolare esula dalla struttura a classi.
Ogni classe del framework è quindi dedicata ad un preciso scopo, in

modo da avere una separazione logica dei vari compiti.
Operativamente il framework è disponibile nell’istante in cui viene

incluso il file golem.php, contenuto nella cartella golem: questo
- 44 -

passaggio molto semplice rende disponibile tutto il livello, pronto

all’uso.
Per rendere completamente operative tutte le funzionalità è
ovviamente necessario procedere all’inizializzazione della classe di
gestione del database e all’avvio del metodo di aggancio del sito con
la propria web ID.
4.4.1. Web handler

Il gestore, o handler, web (golem.web.php) è la classe che
sincronizza il nome identificativo del sito specificato nel file di
configurazione con l’id web (wid) che verrà utilizzata all’interno del
motore.
In questo caso web va inteso come rete nel senso originale del
termine: infatti non fa altro che organizzare una rete di più siti
collegati allo stesso database.
Vi è quindi una separazione che consente di avere accesso ad un

solo database tramite siti distinti, con la possibilità di mantenere la
divisione per tutti i dati memorizzati che riguardano uno solo dei web
connessi.
In questo modo è possibile realizzare strutture anche piuttosto
complesse: un database unico per ricercare le informazioni, per
registrare gli utenti e operazioni simili, e un network che si diversifica
su siti dedicati ad attività differenti.
Inoltre questa classe funziona da primer per l’eventuale setup: se

all’avvio non viene rilevata la struttura di tabelle nel database, viene
caricata dinamicamente la classe setup (in modo che occupi memoria
e potenza di calcolo solo nello specifico caso) e avviata.
La classe quindi crea il database vuoto secondo lo schema prima
spiegato e genera tutti i parametri di configurazione iniziali,
aggiungendo anche l’utente di amministratore (unico utente
disponibile al setup).
- 45 -

La classe setup, inoltre, svolge la funzione di aggiornare il database

e gli eventuali parametri di configurazione nel caso venga updatato il
motore phpGolem sul server web su cui gira.
4.4.2. Extensions handler

Questo gestore è forse l’elemento più importante di tutto il framework
perché svolge il compito cruciale di gestire il funzionamento delle
estensioni.
Come è già stato accennato, le estensioni sono dei programmi a tutti

gli effetti, contenuti in pacchetti che si appoggiano sul livello
framework per funzionare.
Il gestore (golem.ext.php) non fa altro che inizializzare le estensioni a

runtime, fornendo anche una serie di funzioni per poterle manipolare
come unità: aggiunta, installazione, eliminazione.
E’ quindi il componente che fornisce il punto di aggancio ed è quindi il
fulcro dell’esecuzione delle estensioni, stabilendo e organizzando
tutta la struttura logico-funzionale.
La parte di aggiunta è piuttosto complessa ma sequenziale: per

aggiungere una estensione è sufficiente infatti specificarne la
posizione nel filesystem e il suo nome:
1. Viene istanziato l’oggetto di interfaccia, in modo da potere
accedere a tutti i suoi metodi e alle sue variabili di
configurazione.
2. Questo permette l’accesso ad alcune variabili interne di
configurazione, fra cui fondamentale l’elenco delle altre
eventuali classi a cui fa riferimento (XClasses).
3. Sia l’estensione, ovvero la sua interfaccia, che le classi così
reperite vengono quindi inserite nel database. E’ un passaggio
essenziale perché consente successivamente di istanziare sia
l’interfaccia che le classi di logica in seguito ad una semplice
query sul database.
4. Quindi vengono inseriti i diritti di default, richiamando la
specifica classe del framework che procederà all’aggiunta.
- 46 -

5. L’ultimo passaggio consiste nel richiamare una possibile

funzione all’interno dell’oggetto di interfaccia per consentire
all’estensione stessa di eseguire uno script al momento
dell’inserimento.
A runtime poi, per ogni caricamento della pagina, vengono estratte le

estensioni attive (e relative classi di logica) dal database, per poterle
inizializzare.
1. Il processo non fa altro che istanziare tutti gli oggetti relativi a
ciascuna delle estensioni.
2. Aggancia ad esse il file di lingua specificato nel file di
configurazione del sito.
3. La funzione di inizializzazione utilizza le funzionalità di PHP per
consentire alle classi di logica di funzionare fra di loro: vengono
infatti resi globali tutti gli oggetti qui creati, tranne l’interfaccia
(che deve rimanere specifica per l’estensione).
Vedremo più avanti nel capitolo come sono strutturate e come

funzionano le estensioni.
Il gestore è peraltro strutturato in modo da caricare dinamicamente

le estensioni la prima volta che ne viene fatta richiesta: in questo
modo se il framework viene caricato ma utilizzato solo nelle sue
funzionalità base, non vengono dedicate risorse di calcolo e di
memoria per caricare anche tutte le estensioni.
4.4.3. Users handler

Il gestore degli utenti è in realtà diviso per questioni organizzative in
due oggetti distinti: il primo è il gestore utenti propriamente detto
(golem.user.php) mentre il secondo è il gestore delle autenticazioni e
dei diritti (golem.auth.php).
Il primo gestisce l’utente correntemente loggato nel sistema,

associando ad esso sia i dati inseriti nel database, sia rendendo
disponibili una serie di dati volatili che vengono memorizzati nel
cookie. Questo è molto utile per gestire impostazioni di configurazione
- 47 -

marginali ed eventuali variabili per la realizzazione di interfacce più

intelligenti, senza per questo appesantire il database.
Inoltre la gestione di questi valori è condotta in modo omogeneo con il
gestore di configurazione (vedi più avanti): questo comporta che se
un valore non è memorizzato in modo unico per l’utente, viene
ricercato il default nelle impostazioni globali del sistema.
Il secondo invece è di maggiore importanza perché effettua tutti i

controlli di sicurezza.
Durante la login, se i dati inseriti sono corretti, genera un hash MD5
che viene memorizzato sia nel database sia nel cookie. Questo
procedimento rende molto più sicura l’identificazione dell’utente ed
elude molti tipi di attacco che potrebbero essere diretti verso il
sistema.
Risponde, inoltre, direttamente a tutte le richieste di verifica dei
diritti di accesso, controllando se sono stati forniti sia a livello di
utente che a livello di gruppo.
L’ultima funzione che assolve è quella di inserire nel sistema altri
diritti in modo che siano resi disponibili.
4.4.4. Architecture handler

Il sistema dell’architettura (golem.arch.php) è gestito in modo
particolare su phpGolem: è un approccio sistematico ma flessibile per
la generazione di sistemi strutturati di pagine web, il tutto
configurabile a runtime.
L’architettura è organizzata in modo

gerarchico. Vi sono una serie di layout,
ciascuno corrispondente ad un preciso design
e all’organizzazione della pagina mostrata agli
utenti.
I layout sono organizzati tramite una struttura
gerarchica in modo che un sottoalbero erediti
dalla sua radice tutte le caratteristiche che
questa possiede.
- 48 -

Ad esempio è possibile avere tre pagine dipendenti dalla home (la

pagina principale del sito), che utilizzano la stessa grafica (il campo
Template della tabella) ma un differente layout di pagina
(SubTemplate).
In questo modo si minimizza la duplicazione di tutti i files accessori
alla pagina HTML (grafica, CSS, javascript, …), mantenendo
comunque la possibilità di gestire differenti strutture.
Ogni layout definisce quindi al suo interno, oltre al template da

utilizzare, anche il riferimento alle parti del motore che dovranno
essere attivate e a come saranno posizionate.
Infatti il gestore dell’architettura estrae dal file della struttura del
template (SubTemplate) tutti i tag relativi al layout (#LAYOUT.*#) e
consente di associare a ciascuno di questi uno dei possibili moduli
pubblici delle estensioni.
- 49 -

La parte operativa dell’associazione è poi eseguita dal gestore del

template che, una volta ricevute le associazioni dal componente
dell’architettura, esegue i moduli pubblici delle estensioni e li
sostituisce, come vedremo, all’interno del template.
Questo tipo di organizzazione consente quindi di gestire l’architettura

del sito in modo intuitivo e completamente dinamico, strutturando a
runtime tutta una possibile gerarchia di layout e grafiche differenti.
Inoltre, gestisce in modo altrettanto flessibile i contenuti dinamici
forniti dalle estensioni: è possibile sostituire rapidamente una
funzionalità con un’altra, senza dover minimamente toccare il
template grafico o senza dover mettere mano al codice sorgente.
Un altro vantaggio è l’ereditarietà che questo sistema comporta: un

figlio può condividere con il padre grafica, design e moduli, e può
sostituirne a piacere alcuni secondo le necessità del layout che si sta
costruendo.
4.4.5. Configuration handler

Questa classe (golem.cfg.php) svolge una funzione piuttosto
semplice: mette a disposizione uno spazio condiviso in cui salvare
variabili di configurazione, rendendole eventualmente modificabili
tramite un’estensione.
Le variabili sono associate alle estensioni, quindi per richiedere un

valore preciso si specifica l’estensione a cui appartiene e il suo nome.
Questo semplifica la gestione e contemporaneamente si uniforma alla
gestione dei diritti, che è anch’essa centrata sulle estensioni.
E’ quindi possibile creare nuove variabili di configurazione, salvare e

leggere i valori.
4.4.6. Template handler

Il gestore del template (golem.template.php) è un elemento molto
importante per il design del sito web. Esso gestisce la separazione
- 50 -

fra codice e presentazione, fornendo una serie di metodi per poter

utilizzare dei template testuali separati.
Sebbene l’utilizzo primario sia la generazione di pagine HTML o

XHTML, questo oggetto gestisce in modo indipendente dal contenuto
il file con cui lavora, in modo che si possano generare, secondo
eventuali necessità, pagine XML, testuali, RTF, o in generale
qualunque formato file testuale.
Il meccanismo di funzionamento è piuttosto semplice: il gestore non

struttura un vero e proprio sistema di scripting, ma effettua semplici
sostituzioni e separazioni di codice.
Questa opzione è stata preferita in quanto è più semplice per un
grafico o un designer realizzare template corretti, senza la necessità
di possedere conoscenze di programmazione o imparare un ulteriore
linguaggio di script.
Il template handler quindi carica uno specifico template e automatizza

alcuni processi su questo, in modo che possa essere utilizzato dal
motore.
Vi sono tre strutture che il gestore riconosce all’interno dei template
e su cui può operare:
1. tag
2. sezioni
3. inclusioni
I tag sono delle stringhe di testo delimitate da cancelletti (#stringa#)

che vengono gestiti tramite sostituzione diretta. Quindi si può
richiedere di sostituire il tag “content” (#CONTENT#) con la variabile
PHP $output.
Es.
<a href=”#LINK#”>#NAME#</a><br />
- 51 -

Le sezioni sono invece un modo di separare, all’interno di uno stesso

file template, diverse parti così che possano essere richiamate in
modo indipendente l’una dall’altra.
Sono delimitate da una coppia di stringhe che aprono e chiudono la
sezione, pensate in modo che siano nascoste secondo la normale
sintassi HTML/XHTML:  e .
E’ quindi possibile richiamare una sezione dal template e sostituire al
suo interno tutti i tag richiesti, per poi mostrare la pagina così
generata all’utente finale.
Es.

<div class="article">
<div class="iconBox">#ICON#</div>
<h1>#TITLE#</h1>
<h2>#NICK# - #DATE# - #TIME#</h2>
<div class="body">
#TEXT#
</div>
</div>

Le inclusioni sono invece un modo di inserire all’interno di uno

stesso template sezioni prelevate da più files differenti.
Essenzialmente funzionano incorporando il file incluso dentro quello
chiamante, da un punto di vista logico, creando un unico corpo.
La sintassi utilizzata è una riduzione delle Server Side Includes
secondo lo standard del server web Apache: .
Vi è un’unica limitazione: al momento il motore gestisce un solo livello
di inclusioni. Quindi non è possibile creare strutture nelle quali un file
ne chiama un secondo e questo ne richiama un terzo: quest’ultimo
non verrebbe letto.
- 52 -

Es.



Queste strutture offrono sicuramente un livello di flessibilità inferiore

rispetto ad un linguaggio di scripting ad hoc (come può essere ad
esempio Smarty, o la scrittura diretta di PHP nell’HTML) ma possiede
il vantaggio di essere piuttosto semplice da apprendere e da
utilizzare.
4.4.7. Interface handler

Questo componente (golem.int.php) raggruppa tutto un insieme di
funzioni, a volte anche piuttosto eterogenee, ma che contribuiscono a
gestire a vari livelli l’interfaccia utente comune di phpGolem.
Vengono infatti semplificate al suo interno tramite funzioni una serie di

chiamate ripetitive e di operazioni che semplificano la vita di uno
sviluppatore, fornendo strutture già pronte e uniformi per la gestione.
Ad esempio tutti i tag dei form HTML (<form>) sono uniformati tramite
una unica funzione che in questo modo è facile da utilizzare e
memorizzare.
Inoltre ognuna delle funzioni del gestore fa utilizzo di sezioni

specifiche nel template, in modo da essere uniformi per lo
sviluppatore e personalizzabili come presentazione.
4.4.8. Script di generazione pagina

Questa componente (golem.paginator.php) è stata lasciata per ultima
nella disamina perché non è strutturata come una classe,
analogamente alle altre, ma è invece uno script.
Infatti questo file contiene il codice che gestisce l’algoritmo
necessario alla generazione della pagina finale: come è stato più volte
ripetuto, phpGolem è un framework. Per questo motivo è un
- 53 -

componente che può essere sostituito con un altro script equivalente,

senza per questo influenzare il comportamento del framework.
Naturalmente vi sono alcune operazioni che bisogna effettuare in

ogni caso, come la connessione al database e l’inizializzazione del
web, ma successivamente a queste è possibile poi utilizzare il
framework come si preferisce.
Lo script di default è costituito da una sequenza di operazioni che

richiamano i vari componenti di golem in modo da costruire la pagina
che viene richiesta dall’utente (client).
1. Una pagina è richiesta al sito gestito dal motore phpGolem.
2. Viene inizializzata la connessione al database SQL (MySQL)
3. Viene inizializzato l’ambiente web di riferimento, collegando la
stringa identificativa del sito dal file di configurazione con l’ID
web nel database. Viene eventualmente inizializzata la struttura
di tabelle necessaria a phpGolem per funzionare.
4. Viene eseguita, se disponibile, la funzione di inizializzazione su
ognuna delle etensioni. Le estensioni vengono caricate
dinamicamente al loro primo utilizzo: solitamente in questo
momento.
5. Viene verificato l’utente che sta aprendo la pagina: nel caso sia
loggato nel sistema viene verificato il suo hash MD5. Se non
combacia con quello nel database viene sloggato.
6. Viene inizializzata l’architettura del sito, caricando il layout
corretto per la pagina che è stata richiesta e collegando i vari
moduli pubblici delle estensioni con i tag sul file del template.
7. Vengono chiamati tutti i moduli caricati nel layout della pagina
ed eseguiti, inserendo l’output nella posizione corretta.
8. La pagina finale è restituita all’utente.
- 54 -

- 55 -

4.4.9. Struttura dell’URL

Le estensioni sono il mattone base costituente il motore, fattore che
va a riflettersi su molte altre componenti e strutture logiche del
sistema. Si è già visto ad esempio che la gestione dei diritti e quella
dei valori di configurazione richiedono il nome dell’estensione di
appartenenza come identificativo.
L’URL (universal resource locator, o URI, universal resource identifier)

è costruito sulla stessa logica estensione-centrica.
Esistono, infatti, alcuni parametri nella stringa URL definiti
nativamente nel framework phpGolem che permettono l’accesso alle
interfacce delle estensioni.
Il primo parametro è x (da eXtension) e costituisce il nome

dell’estensione che verrà utilizzata nel corpo della pagina.
Il secondo parametro è fx (da function) e va a definire quale funzione
(metodo) si vuole richiamare all’interno dell’oggetto di interfaccia che
è stato specificato con la x. Questo è naturalmente opzionale: se non
specificato viene utilizzato il suo valore di default.
L’ultimo parametro è l (L minuscola, da Layout) ed è il parametro

utilizzato per l’accesso ad un preciso punto dell’architettura del sito:
questo corrisponde al nome che è stato dato ad un singolo layout
nella configurazione della gerarchia delle pagine, tramite l’estensione
apposita.
La querystring dell’URL sarà quindi costituita nel seguente modo:

?l=list&x=cms&fx=show
Sono ovviamente accettabili altri parametri e, contemporaneamente,
nessuno di questi è obbligatorio: nel caso di assenza, verranno
utilizzate tutte le impostazioni di default.
- 56 -

4.5. Estensioni
Come si è potuto notare le estensioni sono il fulcro operativo intorno
al quale si svolgono le operazioni e il mattone base con cui si
costruiscono le applicazioni con golem.
Le estensioni risultano essere strutturate su più livelli, in modo da

fornire la stessa flessibilità strutturale di un programma standalone.
Ognuna di queste infatti, pur essendo un unico pacchetto logico, può
essere ulteriormente suddivisa su tre livelli distinti.
1. Interfaccia
2. Business Logic
3. Dati (database e files)
1. La parte di interfaccia è l’elemento che fornisce un unico punto

accentrante la gestione di tutte le funzionalità di interazione con
l’utente.
Si tratta infatti dell’unico oggetto che nel framework ha la
possibilità di generare output diretto: questo garantisce una
migliore organizzazione dei contenuti, separando gli elementi di
presentazione da quelli logici. Contemporaneamente,
accentrando in questo unico elemento tutte le interazioni con
l’utente vi è un maggiore controllo sulla sicurezza.
2. La parte di logica è un livello che contiene unicamente un
insieme di classi che vengono automaticamente istanziate dal
gestore delle estensioni, denominate XClasses (eXtensions
Classes).
E’ importante notare che oltre a costituire il livello di business
logic per l’estensione stessa, queste classi formano un insieme
di librerie condivise all’interno di tutto il motore (dichiarazione
global di PHP).
In questo modo è possibile realizzare più estensioni separate,
gestite in modo autonomo e distinto, ma eventualmente
interconnesse: questo garantisce una migliore strutturazione del
codice, scalabilità e riusabilità.
- 57 -

Vi è uno svantaggio teorico di questo approccio: le classi

devono essere subito istanziate in oggetti. E’ però abbastanza
chiaro che se l’estensione è caricata molto probabilmente è
anche in uso: rischia di essere più pesante un sistema per
avviare ad hoc gli oggetti che l’autoistanziazione.
Al contrario questo approccio costituisce un notevole vantaggio
per lo sviluppatore, che ha a disposizione in modo semplice ed
immediato tutte le classi del framework assieme a tutte le classi
di logica condivise dalle estensioni, in modo uniforme e
consistente.
3. Inoltre vi è il livello di accesso ai dati: questi possono essere
sia files che tuple nel database, sia locali (ovvero residenti
all’interno dell’estensione stessa) sia globali (ovvero disponibili
a tutto il motore).
Infatti è possibile utilizzare per la presentazione o dei files
HTML e CSS residenti nel pacchetto stesso oppure usufruire di
elementi comuni prelevati dal template.
In modo similare l’estensione può utilizzare un suo spazio
all’interno del database (eventualmente connettendosi ad un
server differente) oppure reperire i dati dalla base dati di golem
stesso, anche se in quest’ultimo caso sarebbe preferibile
utilizzare il framework stesso per accedervi.
Questa strutturazione su tre livelli è anche sufficientemente flessibile

da non generare un overhead eccessivo nel caso fosse necessario
utilizzare estensioni piuttosto piccole: è possibile infatti realizzarne
una contenente all’interno della sola interfaccia tutti gli elementi
necessari al suo funzionamento.
All’opposto, è possibile programmare una estensione che funzioni
unicamente da libreria di classi condivisa, senza alcun elemento di
interfaccia.
- 58 -

Dal punto di vista fisico l’estensione di phpGolem è strutturata come

una singola cartella che contiene tutti gli elementi utili al suo
funzionamento ed è costituita, nel caso più semplice, da un singolo
file che svolge tutte le operazioni di interfaccia.
Nel caso più completo, invece, una estensione pur rimanendo sempre
auto-contenuta all’interno della sua cartella è costituita da:
- 59 -

• un file di interfaccia (che possiede lo stesso nome della

cartella)
• più files di logica, che costituiscono il corpo di funzionalità
puramente funzionali, ovvero sprovviste di una interfaccia
• più files di presentazione, ovvero files html, css, javascript, che
andranno a costituire la parte
grafica dell’interfaccia
• più files contenenti le lingue, per il
supporto nativo a più idiomi,
localizzate in una sottocartella
In particolare l’unico file vincolante è,

come già intuibile, quello che costituisce
l’interfaccia: poiché al suo interno
definisce anche le variabili di
configurazione dell’estensione.
Tutti gli altri elementi sono invece a
discrezione dello sviluppatore sotto ogni
punto di vista.
4.6. Come sono perseguite le linee guida

Inizialmente sono state definite delle linee guida molto precise: dopo
tutta la disamina analitica del motore è quindi possibile comprendere
come queste siano state perseguite.
4.6.1. Estensibilità
L’estensibilità è quindi il fulcro attorno al quale è stato sviluppato il
progetto: primariamente, è stato sviluppato un nucleo pensato come
framework, in modo da fornire un livello base su cui costruire.
In secondo luogo, è stato fornito un sistema gestionale per
organizzare in modo logico e coerente l’eterogeneità dei programmi
sviluppabili, in modo da rendere la struttura non solo estensibile, ma
anche fortemente modulare.
- 60 -

4.6.2. Flessibilità
Lo stesso concetto di estensioni, così strutturato, garantisce anche
una notevole flessibilità.
Questo perché la singola estensione garantisce al suo interno
l’esistenza di più livelli distinti, che forniscono un ottimo livello di
separazione funzionale delle varie entità logiche.
Inoltre, tutto il motore è pensato con questa separazione in mente in

modo da rendere indipendenti fra di loro la progettazione grafica
dell’interfaccia (presentazione) dalla la realizzazione tecnica del sito
web (nonché l’eventuale sviluppo addizionale).
In questo modo un designer non ha bisogno di istruirsi su nozioni
programmative riguardanti le modalità di inserimento del proprio
lavoro all’interno del sito. Allo stesso modo lo sviluppatore può
prendere gli elementi di presentazione ed organizzarli, così come
sono stati forniti.
4.6.3. Semplicità di sviluppo

La semplicità di sviluppo è ottenuta sicuramente tramite
l’incorporazione delle funzioni più spesso utilizzate all’interno del
framework, ma non solo: il concetto di estensione, logicamente
separata, consente allo sviluppatore di scegliere lo stile di sviluppo
che più preferisce, qualunque sia il suo grado di competenze
tecniche.
In questo modo non è necessario imparare un certo tipo di

strutturazione logica per iniziare a programmare, ma semplicemente
poche strutture formali, che risultano comunque essere di facile
comprensione.
4.6.4. Semplicità di uso

Il motore è pensato tentando di rendere l’interfaccia di
amministrazione il più possibile intuitiva.
- 61 -

E’ stata studiata una serie di linee guida (esposte nei requisiti) in

modo da organizzare il lavoro in modo semplice, evitando l’obbligo di
apprendere altre nozioni.
La navigazione è gestita su due livelli, in modo chiaro e separato,
distinguendo le componenti di navigazione dallo spazio dedicato
all’operazione che si sta svolgendo.
Inoltre la pacchettizzazione delle estensioni contribuisce ad una
facile aggiunta e rimozione delle funzionalità.
4.6.5. Riuso
Ogni estensione ha un unico elemento vincolante, come si è visto,
che è la classe di interfaccia. Tutte le XClasses risultano invece
indipendenti dalla struttura organizzativa di phpGolem e sono quindi
riutilizzabili ovunque come classi separate.
Inoltre, a runtime sono tutte istanziate a oggetti ed efficacemente
condivise fra di loro. Questo minimizza la riscrittura di codice non solo
all’interno della stessa extension, ma su tutto il sistema che si sta
realizzando.
- 62 -

5 . Us e r vi e w
Il programma phpGolem si delinea quindi come un framework

estensibile per applicazioni web, orientato maggiormente verso la
creazione di un CMS.
Sebbene il motore sia strutturato essenzialmente come un framework,

viene fornito in modo da essere a tutti gli effetti un content
management system orientato ad un target di sito personale, blog, o
piccolo e medio portale.
Valutiamo quindi primariamente questo approccio operativo

nell’analisi del punto di vista dell’utente.
5.1. Installazione
Si è cercato di semplificare il più possibile la procedura di
installazione, in modo che possa essere utilizzata anche da utenti
meno esperti.
Vi sono cinque passi da effettuare per installare phpGolem:

1. Configurazione: bisogna impostare alcuni valori fondamentali
nel file di configurazione, denominato _globals.php e
localizzato nella root del sito. Al suo interno si possono
configurare svariati parametri, ma essenzialmente bisogna
inserire i dati per:
a. $G_ENV[web_idname], che è il nome identificativo del
sito web che si sta installando. Questo serve per il
corretto funzionamento del componente che gestisce il
supporto multisito.
- 63 -

b. $G_DB, che serve per fornire i dati essenziali affinché il

motore sappia dove e possa collegarsi al database SQL
necessario al suo funzionamento.
2. Upload: una volta configurato è ovviamente necessario

uploadare tutti i files del motore sullo spazio che si ha a
disposizione per il sito web.
3. Diritti: è fondamentale ricordare che la cartella files/ ha la
necessità di avere i diritti in scrittura: al suo interno infatti
verranno salvati almeno tutti i files di caching del motore, cosa
fondamentale e che riduce i tempi di esecuzione di oltre un
ordine di grandezza.
4. Prima esecuzione: la prima esecuzione provvede a creare tutti
i gli elementi necessari all’esecuzione del motore, creando le
tabelle e caricando i dati minimali di esecuzione. E’ importante
che in questa fase l’utente abbia attivati i cookie, in quanto verrà
automaticamente loggato come amministratore.
5. Admin: una volta loggati come amministratori web, si può
procedere ad attivare e configurare il motore.
a. Il primo passo da seguire è abilitare le estensioni
necessarie. Di sicuro serve una di quelle uploadate per la
gestione degli utenti, in modo da rendere accessibile
l’interfaccia di login (senza la quale non si può entrare nel
pannello di amministrazione, come è chiaro).
b. Successivamente è fortemente consigliabile cambiare la
password di default (utente wa, pass wa).
6. Customizzazione: una volta completati questi primi passaggi, si
può procedere alla strutturazione effettiva del sito, configurando
le varie estensioni, aggiungendo eventuali template o altre
estensioni, secondo le necessità.
- 64 -

I passaggi possono sembrare molti ma è unicamente a causa del

dettaglio con cui sono stati descritti. Dopo avere capito cosa bisogna
fare, si procede con estrema rapidità dal passo 1 al passo 6: la fase
più lunga è naturalmente l’ultima dove si deve dare forma al sito
finale.
Questa è la prima pagina che appare appena si è completata

l’installazione al primo avvio del framework, che fornisce le
spiegazioni essenziali per procedere al passo successivo.
- 65 -

5.2. Estensioni
L’ordinamento delle varie voci relative alle estensioni nei menu segue
un raggruppamento logico basato sulla loro funzionalità.
Il primo gruppo ad esempio mostra i nomi secondo i vari passaggi di
configurazione di un sito, dal basso all’alto (extensions, configuration,
architecture). Il secondo gruppo invece è orientato alla gestione degli
utenti e dei gruppi. Il terzo invece mostra le varie operazioni di
gestione per le funzionalità di CMS.
5.2.1. Extensions
Questa estensione è quella caricata di default dal motore e la prima
disponibile su un sistema appena installato.
Infatti lo scopo che persegue è fornire l’interfaccia alle componenti del
framework per la gestione delle altre estensioni: attivazione,
disattivazione e setup.
Le operazioni sono molto semplici, realizzate cercando di rendere

molto lineari eventuali modifiche: l’interfaccia presenta una lista di
tutte le estensioni che sono state messe a disposizione durante la
fase di upload del sito, fornendone il nome e una breve descrizione,
unitamente all’indicazione della versione attualmente in uso.
E’ quindi possibile tramite la semplice pressione di un tasto attivarle
se disattivate (e viceversa) ed eventualmente installare e configurare
tabelle e valori di configurazione aggiuntivi.
Questa estensione non svolge molte altre operazioni. Si sta

comunque pensando di costruire in futuro un repository (libreria)
online di tutte le estensioni esistenti unitamente ad un sistema di
aggiornamento e di installazione remota.
- 66 -

5.2.2. Configuration
La pagina di configurazione fornisce un modo uniforme per modificare
alcuni valori di configurazione sia del framework che delle singole
estensioni.
Si tratta di una lista che visualizza nome, descrizione e valori delle

varie variabili, suddivise fra globali (ovvero del framework) oppure di
una singola estensione.
In alto vi è infatti una combobox che consente di filtrare i valori
secondo queste separazioni. Il nome qui riportato è peralto
coincidente con quello delle estensioni stesse, in modo da facilitarne il
riconoscimento.
- 67 -

5.2.3. Architecture
Questo modulo presenta una visualizzazione gerarchica della
struttura ereditaria dei vari layout presenti su un sito.
E’ facile intuire come le foglie ereditano dai nodi padre, in modo
ricorsivo.
- 68 -

L’aggiunta di un nuovo elemento si effettua tramite il pulsante in alto,

che apre la pagina apposita. Questa pagina sarà la stessa utilizzata
per la modifica.
Nell’aggiunta vi sono solamente i dati per il layout: è richiesto infatti il
padre, il nome e i template a cui appartiene. In più è presente una
combobox che specifica se è il layout da utilizzare come default del
sito.
Appena inserito un nuovo nodo, verranno resi disponibili tutti i tag di

layout presenti sul template, fornendo la possibilità di associarli ad
uno specifico modulo pubblico delle estensioni.
Una combobox per ogni tag specificherà l’elenco dei moduli
disponibili, mentre una seconda il suo livello di accesso (tutti, solo
amministratori, solo utenti registrati, un gruppo specifico).
Infine un campo di testo specificherà le impostazioni per il modulo
selezionato, se ve ne sono. Per queste bisognerà però consultare la
documentazione dell’estensione a cui appartiene.
- 69 -

5.2.4. Groups
I gruppi sono un modo per riunire più utenti all’interno di un solo
insieme, in modo da poter associare a questi una serie di diritti
comuni.
Questa estensione fornirà quindi una lista di tutti i gruppi esistenti,

elencandoli alfabeticamente per nome e visualizzando l’eventuale
descrizione.
- 70 -

Sarà possibile modificare i diritti associati a ciascuno di essi: i diritti

sono divisi ancora una volta per estensione (generalmente, anche se
si possono aggiungere anche chiavi) e con un colore associato a
ciascun raggruppamento in modo da distinguerli intuitivamente.
5.2.5. Users
Anche per gli utenti vi è una visualizzazione analoga a quella dei
gruppi, con la differenza dovuta al numero potenziale di questi: vi è
infatti, oltre alla lista anche un campo di ricerca che permette di
trovare rapidamente un nominativo specifico.
Nella lista è inoltre specificata chiaramente l’e-mail dell’utente per
poterlo contattare rapidamente.
Vi sono alcuni pulsanti: oltre a quello di modifica per cambiare i dati

associati con un nome vi sono sia quello per accedere alla pagina di
assegnazione dei diritti sia quello dei gruppi.
La prima è del tutto simmetrica a quella mostrata per i gruppi, poiché
di fatto vengono visualizzati gli stessi diritti.
La seconda permette di assegnare ad un utente da zero a più gruppi,
in modo che possa ereditare i privilegi da più di uno di questi.
- 71 -

Vi è naturalmente anche la possibilità di aggiungere nuovi utenti

tramite una voce nel menu in alto, ad esempio nel caso di un sito
aziendale (non vi sarà quindi la possibilità di iscrizione pubblica).
5.2.6. Articles
La parte di gestione degli articoli è forse una delle più ricche a livello
di interfaccia per il compito importante che deve svolgere, in quanto
sarà uno dei componenti più spesso utilizzati.
Si presenta, a seconda delle impostazioni di default, come una lista

singola o doppia con in testa un campo di ricerca. Questa differenza
si ottiene anche premendo l’icona disponibile sulla barra orizzontale in
fondo a destra. E’ utile perché consente di avere due visualizzazioni
distinte: o solamente i propri documenti oppure in contemporanea
anche le pubblicazioni di altri autori (due colonne).
Ogni elemento delle liste è costituito da un’icona rappresentativa

dello stato dell’articolo, il suo titolo e la data di pubblicazione, la
categoria (topic) di appartenenza e l’autore. Vi è anche un estratto
che ne sintetizza il contenuto.
In alto nella barra orizzontale vi è oltre al pulsante per cambiare la

modalità di visualizzazione anche la voce per aggiungere un nuovo
articolo. Come sempre, la pagina di modifica è la stessa di quella di
creazione.
- 72 -

In questa pagina si seleziona il topic di appartenenza, il titolo, un

estratto del testo e il testo dell’articolo. Per quest’ultimo è disponibile
un’interfaccia WYSIWYG (what you see is what you get) in modo che
non sia necessaria alcuna conoscenza di HTML o altri metalinguaggi
(Wiki, RDF, etc) per poter formattare il testo. Infatti si presenta tramite
un paio di toolbar simili a quelle che possiamo trovare in un editor
testuale.
A fondo pagina sono presenti alcune opzioni aggiuntive, fra cui la più
importante è sicuramente quella di abilitazione dell’articolo: se è
attivo, l’articolo è pubblicato e quindi visibile da parte di tutti.
Vi è anche un campo per poter segnalare alcuni tag (che verranno

utilizzati nelle ricerche per migliorare la corrispondenza), dove si
potranno inserire delle parole chiave separate da spazi.
Infine vi è una combobox che visualizza lo stato dell’articolo. In

questo modo si può lavorare in un ambiente collaborativo, con un
amministratore che gestisce la pubblicazione mentre gli altri possono
- 73 -

unicamente scrivere gli articoli e segnalare quando lo stesso è pronto

per essere visualizzato sul sito.
5.2.7. Topics
L’interfaccia di questa estensione è costruita in modo analogo a
quella dell’architettura, trattandosi di fatto di un’altra struttura
gerarchica ad albero.
Vengono visualizzati i topic e i sottotopic, segnalando con una icona

lo stato degli stessi.
Tramite una voce nella barra orizzontale si può creare un nuovo
topic, accedendo anche in questo caso alla stessa interfaccia che si
avrebbe modificandone uno esistente.
- 74 -

Qui si può specificare naturalmente il padre e il nome, con in più

anche la possibilità di definire il grado di visibilità dello stesso. Infatti
è possibile nascondere un topic dalla visualizzazione pubblica nelle
liste impostandolo come nascosto (‘hidden’), opzione che lo
manterrebbe comunque accessibile direttamente. Al contrario
l’opzione blocco (‘locked’) impedirebbe qualunque accesso, inclusa la
visione degli articoli ad esso associati.
5.2.8. Comments
L’estensione commenti è gestita tramite una lista cronologica
discendente, visualizzante tutti gli ultimi commenti effettuati. Questo
aspetto è stato progettato in modo da poter visualizzare sempre gli
ultimi commenti inseriti per fini di moderazione (modifica o
cancellazione degli stessi).
Questa estensione è costruita in modo flessibile: è infatti possibile

associare un commento a qualunque coppia di valori estensione/id
numerico. In questo modo qualunque extension si realizzi potrà
rapidamente arricchirsi di un sistema di commenti, come è il caso del
gestore degli articoli.
- 75 -

Nella lista vengono quindi visualizzati i nomi delle estensioni di

appartenenza del singolo commento, oltre al commento stesso e ai
dati dell’autore (nome, mail, IP).
Come già accennato si potrà cancellare o modificare un commento,
nel caso eventuale che sia ritenuto offensivo o fuori luogo.
Vi è anche, in testa, un semplice campo di ricerca, in modo da poter

filtrare i commenti inseriti.
5.2.9. Files
Il motore files è un componente importante per la gestione sia di un
sito generico sia di un CMS, in quanto il file è la principale unità logica
su cui si lavora.
Questo motore presenta quindi una interfaccia per accedere ai file

contenuti nella sottocartella files/, rendendo disponibili le principali
operazioni per lavorare su di essi.
L’interfaccia si presenta come una lista di files e cartelle, distinte da

una icona rappresentativa e fornisce le funzionalità di upload,
- 76 -

rinomina, cancellazione e tagging, oltre alla fondamentale

visualizzazione.
La navigazione e l’apertura dei file viene fatta clikkando sull’icona

rappresentativa, in quando il click (doppio) sul nome è associato
all’evento di rinominazione del file. Questo è stato studiato per
raggiungere un compromesso fra il supporto dei browser e l’intuitività
di manipolazione dei files.
L’upload e la creazione di una nuova cartella vengono fatte tramite
un campo in fondo alla lista dei files, attivato premendo una icona
specifica sui due lati della stessa, una per ogni funzione.
Un aspetto un po’ particolare è la gestione dei tag, attuata tramite una

riga piccola appena sotto il nome del file. I tag vengono utilizzati per
poter effettuare ricerche rapide (o selezioni) su più files.
Un tag non è altro che una parola chiave: l’utente quindi può
specificare alcune parole di questo tipo al fine di poter raggruppare
più files assieme tramite l’uso dello stesso tag.
In pratica potremo associare “mela” ad un file di testo e ad una
immagine, potendoli visualizzare assieme in un secondo momento
attraverso una ricerca con tale parola.
- 77 -

6 . S p e r i m e n t a z i on e
La sperimentazione pratica è un utile passaggio per testare il

funzionamento del framework e del CMS. Aiuta ad individuare ed
eventualmente risolvere le problematiche che potrebbero insorgere,
può quindi apportare miglioramenti al sistema.
In questo capitolo analizzeremo passo a passo la creazione di un sito

web, utilizzando come struttura base su cui costruirlo phpGolem
versione 0.4.
6.1. Sito in oggetto

Il sito che è stato progettato per fornire un esempio operativo è quello
ufficiale di phpGolem stesso.
E’ stata fatta questa scelta perché ha consentito di concentrarsi sugli
elementi logici, d’interfaccia e implementativi piuttosto che sul
perseguimento dei requisiti forniti da un cliente.
6.2. Metodologia di progettazione

La metodologia qui utilizzata è quella delineata da R. Polillo nel libro
“Il check up dei siti web”, in quanto realizzare un sito web utilizzando
un modello di sviluppo delineato a partire da delle linee guida che
definiscono la qualità di un sito significa mantenere sempre
un’attenzione particolare all’usabilità generale del sito per l’utente
finale.
Procederò ora definendo tutti i vari step specificati nel libro in

questione, utilizzandoli però dal punto di vista della realizzazione
invece che da quello di analisi.
- 78 -

6.3. Definizione requisiti
6.3.1. Analisi della concorrenza

Il progetto phpGolem è di base un framework e, per definizione, un
software simile risulta essere sviluppato soprattutto da tecnici che ne
realizzano la logica e il funzionamento: per questo motivo, tutti i
numerosi siti di questo tipo si focalizzano più sul dettaglio operativo
che sulla usabilità del prodotto stesso.
Risultano quindi essere spesso poco curati dal punto di vista della
navigazione, poiché elencano in modo povero tutta una serie di
contenuti, di operazioni e di funzionalità. Questo risulta essere più
dispersivo che efficiente.
Prendiamo per esempio il sito di PHPNuke (www.phpnuke.org), uno

dei primi motori ampiamente diffusi all’interno della community
opensource che si è sviluppato non tanto per la sua efficienza,
usabilità o efficacia, ma piuttosto perché basato su una logica banale
e perché son stati sviluppati innumerevoli addon. I siti PHPNuke sono
facilmente riconoscibili perché hanno “imposta” dal motore la struttura
header + 3 colonne che, sebbene abbastanza lineare, risulta essere
limitante per le applicazioni reali.
Il sito è anonimo: una colonna sulla destra descrive con termini
generici varie funzionalità presenti all’interno del sito, mentre sulla
sinistra abbiamo un menu di “Categorie” che poco guidano l’utente
(categorie di cosa?).
La pagina centrale è essenzialmente utilizzata per le news.
Passiamo a PostNuke (www.postnuke.com), il fratello più importante,

nato da una diramazione di PHPNuke. La grafica in questo caso è
migliorata, perché riunisce vari argomenti in box colorati, ma non
viene sfruttata efficacemente: il quantitativo di box sulla prima pagina
è enorme e risulta essere non meno dispersivo. Inoltre, la barra in alto
porta a svariati sottositi, ma tramite nomi che sono poco indicativi per
un utente generico: richiamano a funzionalità specifiche del motore
- 79 -

stesso. La strutturazione in sottositi, invece, aiuta maggiormente

l’utente a orientarsi, sebbene in modo non eccessivamente chiaro.
Un altro motore abbastanza valido che si sta affermando nell’ultimo

periodo è Xoops (www.xoops.org), anch’esso opensource. Il difetto
primario è che alla stregua degli altri motori CMS cade nell’errore di
fornire troppe voci nella prima pagina: utile per chi è utente
abitudinario ma disorientante per un utente occasionale. Comunque, il
sito è meglio curato, dividendo piuttosto bene le numerose
informazioni e riuscendo a non essere eccessivamente dispersivo: è
indubbio che sia piuttosto difficile gestire un’enorme mole di
informazioni in poco spazio, ma probabilmente sono state spese
poche energie in questa direzione.
Mambo (www.mamboserver.com) possiede un sito pulito e semplice

veicolante tutte le informazioni essenziali suddivise con chiarezza. Ha
una barra di navigazione in alto con le sezioni principali, il logo
pienamente in vista, un box che descrive in modo rapido cosa è
Mambo, fornendo i link per il download e un secondo box variabile
che in questo momento manda all’iscrizione della newsletter. La
pagina prosegue quindi con le ultime news e un menu sulla destra, in
un layout a due colonne.
La pagina iniziale del sito di Drupal (www.drupal.org) è piuttosto ben

organizzata e utilizza i colori in modo efficace: ha un menu di
navigazione orizzontale in alto del colore caratteristico del motore (blu
mare) con il logo chiaramente in evidenza, mentre il corpo della
pagina è costituito da differenti box localizzati e colorati secondo lo
scopo che ciascuno di questi persegue.
Cosa sia Drupal e i principali link (informazioni, features, screenshots
e demo) è sintetizzato in poche parole nel box più evidente come
colorazione (arancione, l’unico colore caldo della pagina). Un box
laterale segnala l’ultima versione disponibile e i link che portano alle
sezioni di personalizzazione del motore (che essendo modulare, si
basa moltissimo su queste parti).
- 80 -

Il resto della pagina è invece intonato con il blu caratteristico ed è

costituita da un elenco di news e da qualche box informativo.
Passando a qualcosa di più modesto come target, come WordPress

(www.wordpress.org), si nota un sito semplice, chiaro e lineare: la
prima pagina spiega cosa è WordPress, con alcuni punti chiave
evidenziati a lato (layout 2 colonne). Per ottenere informazioni
aggiuntive è necessario accedere alla sottosezione specifica,
facilmente navigabile dalla toolbar in alto.
Si vede chiaramente come sia stata prestata attenzione al contenuto,
senza andare a sovraccaricare l’utente di informazioni inutili,
veicolando invece i testi essenziali al visitatore e visualizzando
correttamente la modalità di navigazione.
Probabilmente questo accade perché WordPress è un motore per la
gestione di contenuti principalmente di tipo weblog.
Indubbiamente questa è una analisi sommaria di alcuni siti di sistemi

web analoghi e potrebbe essere svolta con un maggiore dettaglio e
perizia. Ma il punto centrale è avere una idea d’insieme di cosa si
trovi sulla rete per poter trarre eventualmente il meglio da ognuno e
non fare errori banali che rischierebbero di compromettere l’efficacia
di un sito.
Fra quelli esposti, Drupal e secondariamente WordPress e Mambo
appaiono come i più efficaci nel veicolare le informazioni. Sono
semplici ed immediati, ma è evidente che non sono poveri di
contenuti.
In particolare, è chiaro che l’aumento della complessità del sito che
riscontriamo in certi prodotti non è correlato all’aumento delle feature:
questo è ampiamente dimostrato da Drupal o WordPress, che sono
prodotti molto ampi ma in grado di veicolare chiaramente le
informazioni.
Sia inoltre chiaro che in questa analisi si è tenuto conto soprattutto

della prima pagina e ci si è addentrati nei siti lo stretto necessario,
trascurando inoltre di scendere nello specifico del motore che ognuno
- 81 -

di quei siti utilizza, ma che non è di nostro interesse in questa parte

del documento.
6.3.2. Obiettivi generali

Il sito di phpGolem è essenzialmente uno strumento che veicola la
distribuzione e la documentazione sul framework e sul CMS. Esso
fornisce una serie di strumenti per poterlo usare in modo efficiente e
funzionale.
Gli obiettivi primari del sito sono essenzialmente:

• fornire informazioni sul motore
• fornire aggiornamenti periodici sul motore
• fornire la documentazione di uso
• consentire il download del motore
E’ fondamentale esprimere con chiarezza sulla prima pagina una

sintesi su cosa sia il prodotto che viene veicolato dal sito, in modo
sintetico così da fare capire all’utente di cosa si tratti.
Successivamente vi dovrà essere una pagina o sezione interna al sito
che delinei tutte le feature e spieghi in modo esauriente tutto quello
che un utente vuol sapere sul motore, per capire se è di suo interesse
oppure no.
Il linguaggio deve essere chiaro e non dispersivo, schematico e
possibilmente accompagnato da immagini esplicative (vedi ad
esempio le presentazioni dei prodotti Apple).
Il sistema è in continuo sviluppo ed aggiornamento, quindi è

importante che un utilizzatore del software possa rapidamente
controllare se vi sono novità rilevanti, aggionamenti o
miglioramenti, con la possibilità di apportare contributi sotto forma di
consigli o informazioni.
Inoltre dovrà essere fornita all’interno del sito un’ampia

documentazione, facilmente sfogliabile sia in ordine logico che
tramite un motore di ricerca.
- 82 -

La documentazione dovrà riguardare sia l’aspetto operativo, destinato

ad un utente comune o un utilizzatore della parte backoffice, sia
l’aspetto dello sviluppo, ovvero un utente programmatore o
amministratore che invece deve curare anche parti più tecniche.
Il motore di ricerca sarà studiato per essere semplice ma al contempo
fornire una buona rilevanza: il campo di ricerca sarà così limitato ad
uno, unico, capace però di trovare in modo preciso il materiale
ricercato.
Dovrebbe essere disponibile una FAQ (Frequent Asked Questions),

per consentire di trovare risposta rapida ed immediata alle domande
più frequenti senza dover ragionare nei termini più formali degli
articoli disponibili nella documentazione. Anche questa sezione dovrà
essere ricercabile.
Fondamentale sarà poi una pagina in cui poter scaricare il codice di

phpGolem. Si avrà anche una sintesi di tutto il necessario per poter
iniziare. Questa è naturalmente una sezione molto rilevante in quanto
è il passo primario da eseguire per poter installare il software.
Accanto ai primari vi è anche un obiettivo secondario: veicolare

eventuali discussioni inerenti ad uno specifico argomento, proposto
come news o articolo. Si disporrà anche un blog di sviluppo nel quale
proporre temi ordinati cronologicamente riguardanti il motore stesso.
Anche questi dovranno essere facilmente ricercabili.
6.3.3. Utenti
Il sito sarà realizzato tenendo conto delle seguenti categorie di utenti:
1. visitatore occasionale
2. visitatore che cerca informazioni dettagliate
3. utente del framework che cerca informazioni
4. sviluppatore che cerca informazioni
La parte di amministrazione avrà essenzialmente le seguenti figure da

considerare:
- 83 -

1. lo sviluppatore del motore

2. eventuali content editor
3. eventuali sviluppatori
Il visitatore occasionale è una persona che è giunta sul sito di

phpGolem e non sa probabilmente di cosa tratta. Dovrà quindi trovare
con rapidità una sintesi di cosa sia il software ed eventuali
informazioni aggiuntive.
Se interessato dovrà riuscire facilmente a trovare informazioni più
dettagliate, che nel caso di un utente non esperto dovranno essere
spiegate in modo semplice e senza utilizzare un linguaggio tecnico.
Il visitatore che cerca informazioni dettagliate è una persona che

probabilmente conosce già cosa sta cercando, ma vuole soddisfare
rapidamente la sua curiosità in merito a qualche domanda specifica.
In questo caso dovrà poter trovare una FAQ capace di rispondere alle
domande più comuni e dovrà poi successivamente avere accesso ad
una documentazione più dettagliata.
Se il visitatore è già un utente del framework potrebbe rientrare in

due sottocategorie.
La prima riguarda un utente che deve lavorare, per qualche ragione,
sulla parte di amministrazione del motore, in quanto probabilmente gli
è stata data una parte del motore in gestione. Dovrà quindi poter
trovare risposta ai suoi dubbi da un punto di vista strettamente
operativo, in modo che impari rapidamente ad utilizzare le funzionalità
alle quali è stato adibito.
La seconda è un utente già esperto che deve implementare o
configurare qualcosa sul motore: in questo caso dovrà poter trovare
informazioni più tecniche, orientate ad una utenza già esperta o
comunque capace di gestire un sistema simile.
La documentazione quindi dovrà organizzare in modo separato la
parte operativa di un utente del backoffice rispetto alla parte più
tecnica di una persona che invece deve gestire il sistema.
- 84 -

Uno sviluppatore ha già phpGolem installato e deve iniziare a

lavorarci, per creare una estensione oppure fare utilizzo in qualche
modo del framework. Potrebbe essere anche un designer o un grafico
che si trovi a dover progettare l’interfaccia.
Queste figure dovranno quindi poter trovare tutto quello che interessa
loro per poter iniziare e/o proseguire il lavoro che devono svolgere.
La documentazione dovrà essere chiara e orientata agli scopi da
raggiungere.
Più figure importanti sono quindi da tenere in considerazione: il

visitatore occasionale, il visitatore che cerca informazioni dettagliate,
l’amministratore del sito che usa phpGolem e il tecnico di un sito
analogo.
6.3.4. Requisiti di architettura

La struttura deve essere naturalmente di facile navigazione, in modo
da poter essere percepita in modo semplice dall’utente.
In particolare è stata scelto un layout diviso in tre elementi:
1. macro navigazione: toolbar orizzontale
2. micro navigazione: toolbar verticale
3. corpo della pagina in rilievo
La barra orizzontale di navigazione è semplice e posizionata appena

sotto il logo. Ha poche voci al suo interno, chiare e distintive, che
rappresentano le sezioni principali del sito. Queste saranno: Home,
FAQ, Manual, Blog e Download.
E’ importante che siano ben visibili e facilmente accessibili. I nomi

dovrebbero essere sufficientemente chiari anche per un utente che
non conosca i contenuti del sito e che magari sta solo cercando
informazioni.
La micro navigazione è invece costituita da una barra verticale.

Questa è localizzata sul lato destro e contiene tutte le voci inerenti
alla sezione in cui si trova.
- 85 -

Deve essere sufficientemente grande in modo da consentire

l’inserimento non solo di singole voci di menu, ma anche elementi più
complessi, come immagini, frasi o box.
Sarà posizionato a destra, fattore che fornisce una minore visibilità
percettiva alla stessa: si è infatti preferito dare un rilievo al corpo della
pagina in modo che possa fornire una spiegazione ed eventualmente
guidare in una successiva scelta nel menu.
In homepage verrà presentata unicamente la sintesi degli articoli che

verranno aperti clikkandoci sopra. La medesima cosa accadrà anche
per le FAQ e le pagine del Manuale.
6.3.5. Requisiti di comunicazione

Il sito sarà realizzato in tonalità di blu (con l’ausilio dei neutri bianco e
nero) in modo da essere conforme con il colore del pannello di
amministrazione, che utilizza il blu come colore di evidenziazione.
Dovrà essere preminente sull’intestazione il nome (e l’eventuale logo

se verrà definito) assieme alla definizione sintetica di cosa sia
phpGolem: “extensible web framework”.
Lo stile grafico sarà semplice, capace di guidare la persona sui

contenuti senza distrarla con eccessivi abbellimenti, pur evitando un
sito scarno o vuoto. Il tratto sarà moderno in quanto si tratta di un
prodotto informatico.
Il layout è preferibile fisso, centrale. Questo perché si sta

diffondendo l’uso di dispositivi widescreen che rendono difficoltosa la
lettura di lunghe righe di testo. Allo stesso modo il testo seppure
limitato ad un layout fisso dovrà avere dimensioni e stile adeguato per
consentire una agevole lettura sul web.
6.3.6. Requisiti funzionali

Vi è una unica funzionalità pubblica oltre ai contenuti: la possibilità
data agli utenti di commentare gli articoli e le news inserite.
- 86 -

Questo dovrà essere realizzato tramite un semplice form posto a

fondo testo, senza richiedere alcuna registrazione, in modo che
chiunque possa contribuire con le proprie idee o le proprie critiche.
L’operazione è semplice: un form in cui inserire nome, testo ed

eventuali mail e sito. Una volta inviato il commento sarà inserito in
fondo.
E’ anche importante che vengano memorizzati i dati fissi dell’utente

dopo la prima volta che li ha scritti: in questo modo egli non dovrà
ogni volta immettere le stesse informazioni e potrà concentrarsi sul
testo del commento.
6.3.7. Requisiti di contenuto

I contenuti dovranno essere adatti all’utente che li dovrà consultare e
tutti dovranno essere accompagnati da una breve sintesi
La homepage avrà quindi un testo iniziale breve che spiegherà lo

scopo del sito e del motore che propone, unitamente ad un articolo
più esteso che possa rispondere esaurientemente a quali siano gli
scopi precisi che si prefigge questo Framework e CMS web.
Le news visualizzate saranno poi prelevate dal blog e dagli annunci di
nuove versioni.
Le FAQ dovranno essere esplicative cercando di evitare terminologie

troppo complesse, in quanto si tratta di domande che solitamente
vengono poste da persone non esperte.
Il Manuale invece potrà addentrarsi in dettaglio, sempre in

connessione con le conoscenze si stima abbia dell’utente quando
arriva a quella parte della documentazione, collegando anche
argomenti differenti che potrebbero essere inerenti.
Il Blog sarà libero, in quanto tratterà informazioni di eterogenee

organizzate secondo le necessità dell’autore nel periodo di tempo in
cui vengono inserite.
- 87 -

Il linguaggio dovrà essere ovunque informale, evitando un tono

troppo confidenziale. Tutti i contenuti del sito saranno redatti in
inglese.
E’ di particolare rilevanza per gli annunci di nuove versioni inserire

nella sintesi le novità essenziali o gli avvisi di sicurezza, mentre
l’articolo dovrà contenere sia una spiegazione per esteso dei
cambiamenti, sia un elenco più formale e dettagliato di tutte le
modifiche.
6.3.8. Requisiti di gestione

Il sito sarà mantenuto dagli sviluppatori, che ne monitoreranno il
corretto funzionamento e ne gestiranno l’inserimento dei contenuti.
Sebbene si tratti al momento di un sito personale, dovrà essere

possibile l’inserimento nello staff di altre persone in caso di necessità.
6.3.9. Requisiti di accessibilità

Il sito dovrà essere realizzato in modo da risultare leggero a caricarsi,
nell’ordine massimo dei 100kb circa per una pagina normale.
Dovrà essere inoltre estremamente compatibile con ogni browser e

fornire validazione HTML o XHTML. I browser da testare saranno:
Internet Explorer 6, Firefox 1, Safari 2 e Opera 8, che attualmente
coprono circa il 98% dei browser (WebSideStory, US survey, 10
maggio 2005).
L’accessibilità per gli screen reader sarà perseguita tramite l’uso di

sintassi HTML idonea assieme all’uso univoco di CSS per
l’impaginazione, in modo che la pagina sia correttamente organizzata
anche senza aver caricato alcun foglio di stile.
- 88 -

6.3.10. Requisiti di usabilità

Il sito dovrà essere facilmente navigabile e senza una struttura
complessa. Questo si otterrà con normali operazioni di ricerca delle
informazioni, in modo che si possa verificare in quanto tempo sia
possibile reperire una singola informazione.
Sarà anche verificata la rapidità di aggiornamento di uno specifico

articolo, in modo da poter correggere eventuali inesattezze oppure
aggiornare alcuni articoli in un tempo molto ridotto.
Si può valutare l’usabilità tramite una metrica molto semplice e

meccanica, che per quanto poco significativa è comunque utile ed è
da tenere in considerazione: è il numero di click necessari per
giungere ad un risultato, calcolato secondo la via più logica per
eseguire un certo procedimento.
Questo significa che se due operazioni si possono svolgere in due
modi distinti –cosa che andrebbe comunque evitata– si deve
considerare quello più intuitivo, ovvero quello che un utente medio
tenderà a preferire o trovare più in fretta.
Verrà inoltre fatto testare il sito ad un ventaglio di utenti in modo da

valutare se lo svolgimento, almeno delle funzionalità base, sia
semplice da eseguirsi.
In particolare verranno analizzate le funzionalità espresse nella
sezione utenti, in modo da verificarne la loro efficacia.
6.4. Web design

Questa parte della realizzazione del sito è importante perché
consente di avere una giusta visione di quale sarà la navigabilità del
sito finale, la sua struttura e come verranno organizzati i contenuti.
E’ una fase di rilievo perché consente di capire quali siano le priorità

dal punto di vista della percezione del sito da parte dell’utente.
- 89 -

In questa parte è quindi utile studiare l’alberatura del sito, il layout

delle pagine e realizzare, successivamente, un prototipo di
navigazione su cui poter fare considerazioni ed eventualmente
preliminari test di usabilità.
L’alberatura del sito è fondamentalmente su due livelli: la homepage

in effetti è la radice in quanto prima pagina che viene aperta, anche
se dal punto di vista della gerarchia è a pari livello con le altre macro
sezioni.
Di conseguenza in questa disamina la homepage come ipotetico
livello zero, in quanto è chiara la sua importanza preminente.
Quindi abbiamo un primo livello costituito dalle sezioni del sito: Home,
FAQ, Manual, Blog, Downloads.
Ognuna di queste avrà, sul menu verticale, diverse liste che saranno
contestuali all’ambiente in cui ci si trova.
La Home avrà infatti un elenco di vari link riguardanti il progetto in
generale e delle eventuali informazioni che un utente occasionale
potrebbe richiedere.
FAQ e Manual saranno organizzate in modo analogo: disporranno
infatti di un campo di ricerca e sul menu appariranno tutte le voci alle
quali sarà possibile accedere.
Blog sarà organizzato come la homepage di un blog: lista di articoli,
con eventuali ultimi commenti e informazioni sull’autore sul lato
destro.
Download non conterrà ulteriori sottosezioni, ma dovrà fornire
indicazioni esaurienti sullo scaricamento e l’installazione successiva
del motore.
Il secondo livello è costituito da eventuali sottosezioni del sito stesso,

che solitamente è composto da singoli articoli: o una pagina con una
news, oppure una singola entry del blog o un singolo articolo del
manuale.
Queste sono pagine molto omogenee anche se foglie dell’albero di
sezioni molto differenti fra di loro.
- 90 -

Le pagine sono organizzate su un layout uniforme, costituito da una

intestazione contenente il menu, più due colonne, una per i contenuti
del sito e l’altra per il sottomenu che riguarda la sezione in cui ci si
trova.
Vi sono in più due possibilità che risultano opzionali in rapporto alla
pagina che si sta visualizzando. La prima consiste in un’ulteriore
suddivisione su due colonne all’interno del corpo della pagina, in
modo da veicolare sinteticamente un maggiore numero di
informazioni.
La seconda è un box informativo in testa al corpo della pagina, per
fornire eventuali informazioni utili o news importanti.
Il successivo prototipo di navigazione non sarà il sito effettivo già

comprensivo di grafica e contenuti, bensì una serie di pagine
collegate che visualizzeranno la disposizione spaziale dei vari
elementi utili alla navigazione.
6.5. Visual design

Sotto questo punto di vista è stato scelto un look moderno, con un
impianto a layout fisso.
I colori, come precisano i requisiti, sono basati su diverse tonalità di
blu: questo consentirà anche in futuro di dare maggiore rilevanza ad
eventuali avvisi in quanto ogni altro colore si noterà.
- 91 -

Successivamente è stato anche realizzata una seconda versione per

il logo, in grado considerare anche la necessità di distinguere le due
componenti, framework e CMS.
Questo logo richiama l’idea del golem, mantenendo i toni di azzurro
originali e disponendo di una logica che consente di specificare il
nome “framework” o “cms” sotto il nome stesso.
- 92 -

6.6. Sviluppo del software

Il software utilizzato è quello delineato all’interno di questo intero
documento, quindi non vi è molto altro da aggiungere.
In particolare, il sito realizzato, non utilizza estensioni oltre a quelle
fornite di default con phpGolem CMS.
Sebbene ci fosse la possibilità di aggiungere qualche funzionalità
specifica dedicata al sito realizzato in modo da migliorarne alcuni
aspetti, si è preferito concentrarsi sulle feature già disponibili.
6.7. Redazione dei contenuti

I contenuti per il sito saranno inseriti pian piano durante il suo
funzionamento in quanto l’aggiornamento è, al momento, gestito da
una sola.
Sarà comunque preparata una serie di documenti da inserire, in modo

che il sito possa partire già con una buona base documentativa. In più
vi saranno aggiornamenti in itinere che verranno fatti al sistema e
che quindi comporteranno una segnalazione esauriente sulle pagine
del sito.
Il sito non fornirà, in un primo tempo, alcun documento differente da

HTML puro. Sarà possibile che, appena il manuale si stabilizzerà in
una forma esauriente, venga costituito un PDF scaricabile per una
consultazione offline dei documenti. Questo sarà utile anche in
connessione a versioni specifiche del framework, nel caso di cambi
strutturali, per avere una documentazione disponibile anche per gli
utenti della vecchia release software.
6.8. Il risultato
Il sito prodotto aderisce a tutte le linee guida precedentemente
definite e sarà disponibile sul sito www.digitalhymn.com
(golem.digitalhymn.com), da dove sarà possibile scaricarlo, reperire
- 93 -

informazioni aggiuntive più aggiornate e specifiche tecniche più

dettagliate.
La homepage si presenta in questo modo:
Come si nota è stato realizzato un layout a tre colonne in modo da

proporre parallelamente tutte le notizie e gli articoli più recenti,
fornendo anche, nella parte alta, la descrizione sintetica che rimanda
ad una spiegazione più esauriente.
L’intestazione mostra il titolo e il logo, uniti alla definizione del motore,

sotto forma di breve “slogan”. Come già accennato è stato realizzato
un nuovo logo che probabilmente apparirà in una futura intestazione
del sito.
In alto è sempre disponibile, a fianco del menu principale, il box di

ricerca globale sul sito, in modo da averlo sempre a disposizione su
ogni pagina in cui ci si trova.
- 94 -

La pagina delle FAQ si mostra in modo sintetico, con una descrizione

iniziale molto breve. E’ immediatamente visibile il box di testo per
eseguire ricerche nella sezione in cui ci si trova.
Sulla destra è disponibile l’elenco delle FAQ in modo da poter avere
un colpo d’occhio sull’elenco delle domande già presenti.
Procedendo nella navigazione è possibile leggere la FAQ ricercata o

prescelta che verrà mostrata in modo uniforme agli altri articoli ed alle
news presenti nel sito, dando la disponibilità di commentare.
La possibilità di inserire commenti è utile perché permette ad

eventuali domande di essere poste in un luogo consono e suddivise in
modo tematico. Eventuali esperti potranno quindi rispondere, in modo
da arricchire l’articolo al quale si riferiscono. Questo è analogo a
quanto avviene già su siti come php.org.
- 95 -

La pagina del Manuale è costruita in modo analogo alle FAQ,

mostrando un box di ricerca e accompagnandolo con una breve
descrizione e con il menu laterale che presenta una sorta di indice
degli articoli presenti.
Vi sono le ultime due sezioni.

La prima è il Blog che ha una struttura simile a quella di un weblog
standard con l’aggiunta del menu superiore. Esso si trova all’interno
di un sito più ampio che offre una serie di servizi aggiuntivi.
La seconda è quella dei Download, sezione che risulta essere

abbastanza esplicativa: consente di scaricare il codice del software
phpGolem. Qui vengono anche sintetizzate alcune informazioni utili
come promemoria che specificano i requisiti del programma assieme
alla versione che si sta scaricando e ad alcune eventuali informazioni
collaterali.
- 96 -

- 97 -

7 . Ri f e r i m e n t i e b i b l i o gr a fi a
7.1. Riferimenti
A List Apart
http://www.alistapart.com
All Things Bru (Codewitch)

http://www.codewitch.org
Apache
http://www.apache.org
Apple Human Interface Guidelines

http://developer.apple.com/documentation/UserExperience
Bob Boiko, “Content Management Bible”

http://bibliophile.ischool.washington.edu/cmdomain
IIS
http://www.microsoft.com/WindowsServer2003/iis
Leeander
http://www.leeander.com
Mozilla Firefox
http://www.mozilla.org/products/firefox
MySQL
http://www.mysql.com
- 98 -

OmniGraffle
http://www.omnigroup.com/applications/omnigraffle
OpensourceCMS.com
http://www.opensourcecms.com
Pear
http://pear.php.net
PHP
http://www.php.net
R. Polillo
http://www.rpolillo.it
Smarty
http://smarty.php.net
WebSideStory
http://www.websidestory.com
Wikipedia
http://www.wikipedia.org
7.2. Bibliografia
Design emozionale
D. A. Norman, Apogeo 2004
Il check up dei siti web

R. Polillo, Apogeo 2004
- 99 -

Progettazione e Sperimentazione Di Un Framework Estensibile Per Applicazioni Web

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Progettazione e Sperimentazione Di Un Framework Estensibile Per Applicazioni Web

Caricato da

Copyright:

Formati disponibili

UNIVERSITÀ DEGLI S TUDI DI MILANO BICOCCA

FACOLTÀ DI SCIENZE M ATEMATICHE FISICHE E N ATURALI

SUPERVISORE: Chiar.mo Prof. R. Polillo

Relazione della prova finale di:

Anno Accademico 2004/2005

4.2.1. Gestore web multisito (web, setup) .................................... 34

6.3. Definizione requisiti .......................................................... 79

Questo elaborato delinea i vari passi di realizzazione di un sistema

Lo scopo è quindi dare una spiegazione esauriente delle fasi iniziali di

Il progetto software realizzato è una piattaforma aperta per la

Successivamente (settembre 2003) questo progetto è stato

Quando si è giunti alla maturità della versione 0.3 (gennaio 2004) si è

La versione di phpGolem 0.4 è quella qui presa come riferimento e ne

1.3. Organizzazione del lavoro

In questa fase si è realizzata una versione navigabile di un sito web

Nel frattempo, si procedeva alla realizzazione di una interfaccia più

Successivamente si è proceduto ad una analisi di tutto il materiale

1.4. Struttura dell’elaborato

Nella seconda parte, Requisiti del sistema phpGolem (cap 4),

La terza parte, Architettura generale del sistema phpGolem (cap

Infine c’è la parte di Sperimentazione (cap 7) che prendendo ad

Vediamo quindi di entrare nella questione, definendo prima le

2.1.1. Cos’è un Content Management System (CMS)

Un content management system è quindi una struttura software che è

informazioni anche notevole e, spesso, riguardante media differenti,

L’operazione di gestire informazione in modo collaborativo può

Come si può vedere l’ambito di utilizzo di questi software può variare

2.1.2. Cos’è un Framework

Quindi, fondamentalmente un framework risulta essere un

Questo livello software, come è stato specificato può fornire più o

Il framework si distingue quindi da una libreria in quanto quest’ultima

2.2. Tratti comuni: così fan tutti

Il target scelto da phpGolem è quindi condiviso da altri motori: si

Oltre alle caratteristiche che definiscono la tipologia del programma,

In secondo luogo, tutti sembrano aver compreso come sia

2.3. Tratti distintivi: analisi dei vari motori

Per questo motivo ho delineato sostanzialmente quattro profili:

con il sito sono poche o comunque occasionali (i.e. punto-

Ho utilizzato il termine portale invece di sito, più generico, perché

ognuna utilizza un differente host per lavorare, sebbene non vi sia

Dal punto di vista

Per la parte amministrativa

paradigmi e logiche differenti.

PostNuke rappresenta l’evoluzione di PHPNuke da parte di uno staff

verticale con popup a un menu orizzontale, che mi è sembrato meglio

In definitiva Xoops è un sistema più giovane di PHPNuke, si fonda su

il pannello di gestione di un singolo elemento, ma non è sensibile il

secondo le proprie necessità. In effetti Drupal è la base sulla quale

Il motore che è stato realizzato è stato progettato partendo da alcuni

3.1. Linee guida

In questo caso la flessibilità è garantita dal perseguimento

Di conseguenza, pur lasciando libertà allo sviluppatore, il

Per queste motivazioni è stato scelto il nome “golem”, con il prefisso

Il motore è sviluppato integralmente in lingua inglese per garantirne la

3.2. Tipologie di utenti

3.2.1. Framework developer

Ha bisogno quindi delle conoscenze base su come realizzare

3.2.2. Framework user

3.2.3. Backoffice user

Potenzialmente, l’orientamento di questa parte del lavoro è di tipo

3.2.4. Public site user

Tutte queste tipologie di utenti sono tenute in considerazione nella

3.3. Requisiti di architettura