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. 2.1.2.

Cos’è un Content Management System (CMS) ................... 10 Cos’è un Framework......................................................... 11

2.2. Tratti comuni: così fan tutti ................................................ 12 2.3. Tratti distintivi: analisi dei vari motori................................. 13 2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.3.5.

PHPNuke ......................................................................... 14 Xoops .............................................................................. 16 Mambo ............................................................................ 18 Drupal.............................................................................. 19 WordPress ....................................................................... 20

3. Requisiti del sistema phpGolem............................................ 22 3.1. Linee guida....................................................................... 22 3.2. Tipologie di utenti ............................................................. 24 3.2.1. 3.2.2. 3.2.3. 3.2.4.

Framework developer ....................................................... 24 Framework user ............................................................... 25 Backoffice user ................................................................ 25 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. 4.2.2. 4.2.3. 4.2.4. 4.2.5.

Gestore web multisito (web, setup) .................................... 34 Gestore estensioni (ext).................................................... 35 Gestione utenti, gruppi e diritti (user, auth) ........................ 36 Gestione dell’architettura del sito (arch)............................. 39 Gestione della configurazione (config) ............................... 41

4.3. Filesystem ........................................................................ 42 4.4. Framework ....................................................................... 43 4.4.1. 4.4.2. 4.4.3. 4.4.4. 4.4.5. 4.4.6. 4.4.7. 4.4.8. 4.4.9.

Web handler..................................................................... 45 Extensions handler ........................................................... 46 Users handler................................................................... 47 Architecture handler ......................................................... 48 Configuration handler ....................................................... 50 Template handler ............................................................. 50 Interface handler .............................................................. 53 Script di generazione pagina ............................................. 53 Struttura dell’URL ............................................................. 56

4.5. Estensioni ........................................................................ 57 4.6. Come sono perseguite le linee guida ................................. 60 4.6.1. 4.6.2. 4.6.3. 4.6.4. 4.6.5.

Estensibilità ..................................................................... 60 Flessibilità ....................................................................... 61 Semplicità di sviluppo ....................................................... 61 Semplicità di uso .............................................................. 61 Riuso ............................................................................... 62

5. User view ............................................................................... 63 5.1. Installazione ..................................................................... 63 5.2. Estensioni ........................................................................ 66 5.2.1. 5.2.2. 5.2.3. 5.2.4. 5.2.5. 5.2.6. 5.2.7. 5.2.8. 5.2.9.

Extensions ....................................................................... 66 Configuration ................................................................... 67 Architecture ..................................................................... 68 Groups............................................................................. 70 Users............................................................................... 71 Articles ............................................................................ 72 Topics.............................................................................. 74 Comments ....................................................................... 75 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. 6.3.2. 6.3.3. 6.3.4. 6.3.5. 6.3.6. 6.3.7. 6.3.8. 6.3.9. 6.3.10.

Analisi della concorrenza .................................................. 79 Obiettivi generali .............................................................. 82 Utenti............................................................................... 83 Requisiti di architettura ..................................................... 85 Requisiti di comunicazione................................................ 86 Requisiti funzionali ........................................................... 86 Requisiti di contenuto ....................................................... 87 Requisiti di gestione ......................................................... 88 Requisiti di accessibilità.................................................... 88 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. puntoinformatico). 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 motore è strutturato per favorire modo che ogni estensione possa classi così che siano disponibili in

libertà allo sviluppatore, il questo processo, facendo in esportare le proprie librerie e 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 idname Name URL Enabled Description Date Time IP

int (key) varchar(50) varchar(255) varchar(255) int varchar(255) date time 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 wid Extension Name FileName Path Mode Sort

int (key) int varchar(20) varchar(20) varchar(50) varchar(255) smallint 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 User Pass Nick EMail Note SessionHash LastLogin

int (key) varchar(32) varchar(32) varchar(50) varchar(60) varchar(80) varchar(32) 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 wid Name Description

int (key) int varchar(30) varchar(128)

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 wid Extension Key Values Description

int (key) int varchar(20) varchar(20) tinyint varchar(30)

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 uid gid

int (key) int 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 parentarchid wid Ref Template SubTemplate Type

int (key) int int varchar(30) varchar(255) varchar(255) 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 archid Tag x fx Param Access

int (key) int varchar(64) varchar(20) varchar(64) varchar(128) 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 wid x Key Value DefValue OptValue Description

int (key) int varchar(20) varchar(64) varchar(128) varchar(128) varchar(128) 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. #NAME#


- 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. 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 (

) 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 amministrazione il più possibile intuitiva.

- 61 -

rendere

l’interfaccia

di

 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 nell’analisi del punto di vista dell’utente.

approccio

operativo

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 è discendente, visualizzante aspetto è stato progettato ultimi commenti inseriti cancellazione degli stessi).

gestita tramite una lista cronologica tutti gli ultimi commenti effettuati. Questo in modo da poter visualizzare sempre gli per fini di moderazione (modifica o

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 visualizzazione.

e

tagging,

oltre

alla

fondamentale

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 -