Sei in Home page » Documentazione » WebGUI, un C.M.S. per tutti.

Soluzione integrata di telefonia su internet a banda larga.
Cerca su questo sito:  

Vuoi essere aggiornato in tempo reale su tutto quello che mi succede giorno per giorno?
Visita il mio nuovo blog

WebGUI, un Content management system per tutti.

Dott. Emiliano Bruni, info/at/ebruni_dot_it
Copyright © 2005 Emiliano Bruni

Ultima modifica: 2005/03/17
Licenza Creative Commons

Abstract.

La soluzione ideale per la realizzazione e l'aggiornamento di contenuti web in ambiente collaborativi o comunque da parte di "non addetti ai lavori", necessità dell'utilizzo di un Content management system. Di questi ambienti se ne analizzano le caratteristiche salienti per trattare quindi l'installazione e le proprietà principali di uno di essi: WebGUI.

I Content Management System

Il mondo della comunicazione è stato certamente rivoluzionato dall'avvento di Internet, uno strumento che fornisce l' opportunità di essere un elemento "attivo" della rete diventando un fornitore oltre che un fruitore di informazioni e notizie. Per questo sono sempre più quei siti in cui il carattere dinamico consiste nel rapido e costante aggiornamento dei propri contenuti.

E cosi capita sempre più spesso, che chi deve aggiungere e mantenere tali contenuti, spesso non ha o non può avere nulla a che fare con il mondo dell'HTML. Per rendere autonomi questi autori, si fa quindi sentire la necessità di fornire un insieme di strumenti di facile utilizzo per la pubblicazione e gestione di contenuti web-based.

E' in questo contesto che hanno ragione di essere quei sistemi detti Content Management System o C.M.S.

Questi prodotti si interpongono tra l'autore e il server Web permettendo di eseguire operazioni di manutenzione e gestione del sito in maniera semplice e naturale. Si parte quindi dalle problematiche di generazione delle singole pagine HTML alle varie problematiche accessorie che si accompagnano sempre alla pubblicazione di una nuova pagina. La visualizzazione della stessa da un dato giorno ad un dato giorno, l'aggiornamento automatico del menu e della mappa del sito per rendere conto delle nuove pagine inserite, indispensabili restrizioni all'accesso dei contenuti ai soli utenti autorizzati sono solo alcune delle operazioni da dover necessariamente eseguire in un ambiente web-based di tipo collaborativo. Se il tutto non è supportato da un C.M.S., tutte queste operazioni andrebbero eseguite a mano.

Ma cos'è un C.M.S.? Non esiste una sua definizione ufficiale e si preferisce descriverlo enumerando le caratteristiche comuni che un sistema deve avere per essere definito tale.

Un C.M.S. deve inevitabilmente possedere un componente per la generazione e modifica dei contenuti via browser, che non richieda conoscenze dell'HTML o di altre nozioni tecniche. Gli autori possono cosi inserire le notizie direttamente all'interno del browser in un editor WYSIWYG.

Il sistema deve quindi provvede a pubblicare automaticamente la notizia, il giorno definito dall'autore, impaginandola automaticamente all'interno del layout grafico standard del sito. Contestualmente deve generare automaticamente le voci di menu ed i link opportuni per permettere l'accesso e la navigazione all'articolo stesso.

Un'altra caratteristica comune è data dal fatto che un singolo articolo può essere presente in diverse pagine del sito anche con formati differenti. Si pensi, per esempio, alla possibilità di avere, automaticamente, sulla home page, per ogni nuova notizia inserita, un abstract della stessa di modo che, ogni modifica, si ripercuota automaticamente sul contenuto della prima pagina.

Inoltre, tutti i C.M.S. devono avere un potente sistema per mantenere coerente la navigazione tra le varie pagine anche nel caso di pesanti ristrutturazioni.

Ovviamente è lapalissiano che alla base di tutto non può mancare un sistema di autenticazione dell'utente sia per la parte di pubblicazione sia per la parte di visualizzazione dei contenuti al fine di riconoscere i diversi privilegi degli amministratori, degli autori e dei semplici fruitori del sito.

Usualmente, poi, i sistemi C.M.S. gestiscono anche l'archiviazione e la traccia delle varie modifiche eseguite sulle pagine cosi da permettere eventualmente di tornare indietro o avere lo storico delle modifiche apportate ai singoli elementi che compongono il portale.

Presupposto comune a tutto questo, l'estrema facilità di utilizzo di tutti questi strumenti di modo da permettere la gestione delle varie operazioni anche ai non addetti ai lavori.

Un prodotto con queste caratteristiche si adatta quindi perfettamente a tutte quelle situazioni in cui la manutenzione e gestione dei contenuti del sito va messa in mano ad autori "non informatici" o anche in tutte quelle situazioni in cui la manutenzione manuale risulta difficile in quanto il sito ha una struttura di tipo collaborativo con un numero elevato di autori.

Si va quindi da siti semplici in cui l'autore, non programmatore, vuole gestire da solo i contenuti senza passare per un web designer fino a portali con filosofia giornalistica e, più in generale, con filosofia di tipo collaborativo.

Con tutti i pregi fin qui elencati, i C.M.S. hanno però una pesante lacuna. Non sono completamente adatti all'utilizzo professionale da parte dei programmatori. Questi, più scaltri degli utenti normali, vorrebbero avere, si tutta la flessibilità offerta loro dalle funzionalità appena citate di un C.M.S. nella generazione di un sito, ma anche la possibilità di programmare nuove funzionalità per estendere il panorama degli strumenti già offerti per meglio adattarli alle loro esigenze particolari.

A sopperire a questa carenza ci pensano gli Application Program Framework (A.P.F.) a cui appartengono tutti quei prodotti che basano le proprie fondamenta sulle caratteristiche tecniche basilari di un C.M.S. senza avere però già precostruita la parte di interfaccia "user friendly" verso l'autore di contenuti. Anzi, tali sistemi vengono spesso usati come base per costruire dei C.M.S. da affidare ad utenti meno esperti.

Un prodotto a metà strada tra la semplicità di alcuni C.M.S. e l'integrabilità ed espansibilità degli A.P.F. è WebGUI, un sistema opensource distribuito dalla Plain Black che, nel panorama dei C.M.S., si pone in evidenza per alcune caratteristiche peculiari prima fra tutte il fatto che oltre ad avere, come vedremo, tutte le caratteristiche di un completo C.M.S. ha alcune proprietà che lo portano a sfociare nella famiglia degli A.P.F rendendolo quindi adatto sia a utenti inesperti che a utenti professionali. Si vedrà infatti che in WebGUI, per risolvere esigenze particolari, è abbastanza semplice estendere le funzionalità già presenti tramite la creazione di plugins chiamati assets (risorse).

Nel prosieguo di questo articolo vedremo in dettaglio perché WebGUI è la scelta ideale nel panorama dei C.M.S, come installarlo e alcune peculiarità generali. Nei prossimi articoli impareremo ad usarlo come content creator e vedremo come estendere le sue funzionalità.

Installazione

Quali sono i requisiti necessari per avere un installazione di WebGUI funzionante?

Appoggiandosi a prodotti come Apache Web Server, Perl come linguaggio di programmazione, e su MySQL come piattaforma di database preferenziale, esso gira su tutti quei sistemi operativi su cui esistono porting per questi prodotti.

Benché non strettamente necessario, è consigliabile far girare WebGUI all'interno dell'ambiente generato dal modulo mod_perl che integra il compilatore Perl direttamente all'interno del server Web in modo da ottenere il massimo in termini di efficienza e velocità.

Oltre a questi prodotti, WebGUI richiede la presenza di tutta una serie di moduli Perl prelevabili direttamente dal Comprensive Perl Archive Network.

Sulla piattaforma Windows® oltre a poter installare tutti questi elementi separatamente è previsto un setup chiamato Zip'N'Go, presente sul sito di Sourceforge, che installa in un colpo solo tutto, dal server Web, al Perl, al database, ai moduli richiesti fino ad installare WebGUI stesso. Ovviamente è consigliabile utilizzare questa installazione su macchine che non hanno già installato Apache, Perl o MySQL in modo da evitare conflitti con i prodotti già presenti.

C'è comunque da dire, a proposito del mondo Microsoft, che sono reperibili, su Internet, istruzioni su come far girare WebGUI anche sotto Microsoft® Internet Information Server con Microsoft® SQL Server come motore di database.

Quello che ora interessa a noi è vedere come si installa WebGUI su una macchina Linux tralasciando ovviamente l'installazione dei prodotti più standard quali Apache, Perl e Mysql.

Come prima cosa installiamo i seguenti moduli del CPAN richiesti da WebGUI:

  • LWP

  • DBI

  • DBD::mysql

  • Digest::MD5

  • Date::Calc

  • Time::Hires

  • HTML::Parser

  • Archive::Tar

  • Compress::Zlib

  • IO::Zlib

  • SOAP::Lite

  • Cache::Cache

  • Image::Magick

Tutti questi moduli possono essere installati dalla linea di comando come

perl -MCPAN -e 'install NOME::DEL::MODULO

Questo comando installerà anche tutte le eventuali dipendenze proposte.

Baseremo questa installazione sull'ultima versione attualmente (marzo 2005) disponibile, la 6.5.2. Questa è una versione beta che annoverà però moltissime differenze e migliorie rispetto alla attuale versione stabile e per questo si preferisce fare riferimento a questa beta e non alla stabile.

Andremo quindi a scaricare da Sourceforge e, seguendo lo standard usato dai programmatori di WebGUI, creiamo una directory /data nella root del nostro server con il comando

mkdir /data

Decomprimiamo il file scaricato in questa directory tramite il comando

tar -zxvC /data -f webgui-x-y-z.tar.gz

Questo comando esplode tutti i file della distribuzione all'interno di una directory chiamata WebGUI. Questa directory contiene alcune sottocartelle, in particolare: la directory etc con il file di configurazione, la directory lib contenente le librerie e i plugin di WebGUI, la directory sbin con alcuni utili scripts e la directory www che contiene la parte "pubblica" di WebGUI.

Passiamo ora a creare il database d'appoggio dei dati di WebGUI tramite il comando

mysql -p -e "create database WebGUI"

e aggiungiamo un utente con tutti i permessi sul database appena creato

mysql -p -e "grant all privileges on WebGUI.* to webgui@localhost identified by 'password'"

Facciamo rileggere a MySQL i nuovi permessi aggiornati

mysql -p -e "flush privileges"

e creiamo infine le tabelle e i dati di base di WebGUI tramite lo script presente nella directory /data/WebGUI/docs/create.sql

mysql -uwebgui -ppassword WebGUI < /data/WebGUI/docs/create.sql

Siamo ora pronti a configurare WebGUI. Andiamo nella directory /data/WebGUI/etc e rinominiamo il file WebGUI.conf.original nel file WebGUI.conf e editiamo, in questo file i seguenti valori: sitename con l'elenco dei nomi a cui risponde il nostro sito come

sitename = www.example.com, example.com

e le variabili dsn, dbuser e dbpass con i dati per l'accesso al database come

dsn = DBI:mysql:WebGUI
dbuser = webgui
dbpass = password

Le altre variabili possono essere lasciate inalterate a meno che non si sia installato WebGUI in un percorso differente da quello qui esposto. In tal caso i percorsi all'interno di WebGUI.conf vanno adattati di conseguenza inoltre andranno adattati i percorsi presenti nei file sbin/preload.perl e www/index.pl.

Sempre in sbin/preload.perl e, solo se non si usa Apache ver. 2.x, andrà commentata la riga use ModPerl::Registry () e rimosso invece il commento dalla riga use Apache::Registry.

Nella directory sbin esiste uno script che verifica la configurazione fin qui impostata. Tramite lo script /data/WebGUI/sbin/testEnvironment.pl vengono eseguite tutta una serie di controlli, tra cui la verifica della presenza dei moduli richiesti. Questo script installa automaticamente i moduli mancanti, collegandosi direttamente al sito del CPAN. Una volta che siano stati scaricati tutti i moduli eventualmente mancanti, si giunge infine a ottenere il suddetto test corretto:

# cd /data/WebGUI/sbin/; perl ./testEnvironment.pl

WebGUI is checking your system environment:

Operating System ......................... Linuxish
WebGUI Root .............................. ..
Perl Interpreter ......................... OK
LWP module ............................... OK
HTTP::Request module ..................... OK
HTTP::Headers module ..................... OK
Digest::MD5 module ....................... OK
DBI module ............................... OK
Avalable database drivers ................ ExampleP, Proxy, Sponge, Sybase, mysql
HTML::Parser module ...................... OK
Archive::Tar module ...................... OK
IO::Zlib module .......................... OK
Compress::Zlib module .................... OK
Net::SMTP module ......................... OK
Cache::Cache module ...................... OK
SOAP::Lite module ........................ OK
XML::Simple module ....................... OK
Time::HiRes module ....................... OK
Image::Magick module ..................... OK
WebGUI modules ........................... OK

Found config file ........................ WebGUI.conf
Verifying file ........................... OK
Uploads folder ........................... OK
Database driver .......................... OK
Database connection ...................... OK

Latest version ........................... 6.5.0-beta OK

Testing complete!

Si noti alla fine dello script la verifica, dal sito di WebGUI, dell'ultima versione rilasciata e il confronto con la configurazione locale.

Passiamo quindi ad adattare la configurazione del nostro server Web. Innanzitutto dobbiamo cambiare la variabile DocumentRoot per farla puntare alla directory pubblica di WebGUI. Cerchiamo quindi nell'httpd.conf la riga che configura la directory pubblica del nostro server web e modifichiamola in

DocumentRoot /data/WebGUI/www

Andiamo poi a cercare la direttiva Directory associata alla vecchia DocumentRoot tipo

<Directory /var/www/html>

e cambiamola come

<Directory /data/WebGUI/www>

Dentro questa direttiva, aggiungiamo il codice per far girare WebGUI sotto mod_perl con le seguenti righe:

<IfModule mod_perl.c>
<Files ~ "\.(pl)$">
SetHandler perl-script
PerlHandler ModPerl::Registry
</Files>
</IfModule>
Options +ExecCGI

Al posto della riga PerlHandler ModPerl::Registry va usata la riga PerlHandler Apache::Registry se non stiamo usando l'Apache2.

Infine, aggiungiamo, se già non presente, il file index.pl all'interno dei file di indice delle directory

DirectoryIndex …. index.pl

e precarichiamo tutti i moduli richiesti da WebGUI in modo che i vari processi di Apache possano condividere tali moduli senza doverli caricare ognuno

PerlRequire /data/WebGUI/sbin/preload.perl

Per completare l'installazione è necessario creare il file di log di WebGUI

touch /data/webgui.log

dando i permessi di scrittura all'utente di Apache

chown apache:apache /data/webgui.log

e dando gli stessi permessi anche alla directory di upload di modo che l'Apache possa salvare i file uplodati dagli utenti

chown apache:apache /data/WebGUI/www/uploads

A questo punto la nostra installazione dovrebbe essere completata. Aprendo la home page della nostra macchina locale dovremmo essere in grado di vedere la nostra installazione funzionante.

Caratteristiche generali di WebGUI

Iniziamo a prendere confidenza con il nostro futuro sito navigando un po' tra le pagine già presenti nel sito di esempio.

La prima cosa che un occhio esperto nota e che tutte le pagine visitate hanno un URL che contiene la stringa index.pl e infatti, avrete già potuto osservare come questo file sia praticamente l'unico presente nella directory pubblica di WebGUI. Il file index.pl viene chiamato gateway ed è proprio l'utilizzo di un unico gateway che conferisce a tutto il sito un aspetto più omogeneo. L'output di tutte le pagine richieste dovrà sempre passare per questo gateway che tenderà a uniformare il loro stile allo stile di generale del sito.

Un'altra cosa che salta all'occhio è che le varie pagine sono richiamate senza passare parametri nella query string ossia in quella parte dell'URL che alcune volte avrete visto presente dopo l'indirizzo e separata da questo da un punto interrogativo.

Infatti, a differenza di altri prodotti, i parametri che definiscono la pagina che si intende visualizzare nel browser, non vengono passati tramite la query string producendo indirizzi non mnemonici tipo

http://www.example.com/index.pl?pagina=id_mia_pagina

ma simulando un effetto "a directory" per cui una pagina del nostro sito potrebbe essere

http://www.example.com/index.pl/mia_pagina

Questo produce sicuramente degli URL più canonici e mnemonici e non causa inoltre problemi ai motori di ricerca che riescono a indicizzare correttamente le pagine del nostro sito.

In alto poi, non passano inosservati i campi per l'inserimento dello username e della password sintomo che, come accennato in precedenza, WebGUI permette l'accesso alle risorse distinte per utente.

Un visitatore del sito, fintanto che non si sia autenticato tramite questa finestra, viene sempre associato ad un particolare utente a privilegi zero chiamato, non a caso visitor. Questo utente, come anche tutti gli altri utenti registrati, viene associato automaticamente ad un gruppo chiamato Everyone.

Una volta autenticati si entra di diritto anche nel gruppo degli utenti registrati (Registered users).

E' quindi possibile essere associati simultaneamente anche ad altri gruppi come, per esempio, ai Content Managers che è il gruppo di utenti che, di default, possono aggiornare i contenuti del sito, o al gruppo Admins a cui appartengono tutti coloro i quali hanno un accesso completo a tutte le risorse e le gestioni del sito.

Quindi, se per esempio, una pagina è configurata per essere visibile dal gruppo Everyone vuol dire che essa è pubblica ed è quindi visibile da chiunque, anche da chi non si è autenticato, in quanto anche questi utenti appartengono al gruppo Everyone. Se è impostata per essere visibile solo al gruppo dei Registered users allora solo chi si è autenticato la potrà vedere.

Esistono altri gruppi impostati di default con differenti privilegi ma, seguendo la filosofia Unix, è sempre possibile crearne altri per distinguere ulteriormente tra i vari permessi di accesso.

Sempre prendendo a prestito la filosofia Unix-like, tutte le password sono salvate nel sistema con codifica MD5 per cui, nel caso che una password venga persa, neanche WebGUI potrà recuperarla e ne genererà, su richiesta, una ex-novo, inviandola un'unica volta alla casella di posta elettronica impostata sul profilo dell'utente

Il profilo utente inoltre non contiene solo la casella di posta elettronica ma può contenere qualsivoglia informazione si desidera salvare. Esso infatti è completamente personalizzabile e gerarchizzabile fino a definire cosa è obbligatorio e cosa no e che tipo di dati contiene il singolo elemento. E' quindi possibile generare uno schema di profilo utente nel modo più selettivo possibile.

Dalla teoria alla pratica.

Iniziamo quindi ad utilizzare il nostro nuovo sito entrando nel mondo di WebGUI come amministratore del sito. Esiste già un utente con questi privilegi ed ha sempre username admin e password 123qw. Ovviamente, soprattutto su un sito accessibile da Internet, è cosa buona e giusta cambiare immediatamente tale password.

Non appena autenticati, si nota subito che, oltre al classico link per il logout e al link sul nome utente che porta alla gestione del proprio profilo utente, appare un altro link con la dicitura "turn admin on". Questo link, che non appare solo perché si è amministratori del sito ma appare anche a tutti gli utenti che hanno il permesso di manutenzione sui contenuti della pagina, converte la modalità di utilizzo della pagina da sola visualizzazione in modifica.

In tale modalità, vediamo apparire tutta una serie di elementi che, nella normale visualizzazione del sito non appaiono. In particolare sono due le caratteristiche su cui ora vogliamo soffermarci.

La prima sono i due menu che sono apparsi in alto e che ci permetteranno, quello a sinistra di aggiungere nuovi elementi (assets) alla pagina mentre quello a destra raccoglie tutti i possibili strumenti di tipo amministrativo.

La seconda novità è rappresentata da quelle barre di bottoni che dividono la zona centrale della pagina in elementi distinti.

Analizziamo i pulsanti che compongono queste barre. Il primo bottone da sinistra non è in realtà un componente attivo, ma solo un identificativo che individua a quale particolare componente fa riferimento la barra. Per esempio la prima barra dall'alto è la barra di gestione della pagina nella sua globalità mentre le altre barre sono le barre per la configurazione dei singoli assets con cui la pagina è composta.

A parte questo primo bottone, gli altri eseguono delle operazioni sull'elemento corrispondente. Per esempio, il secondo cancella, previo conferma, l'elemento mettendolo però in un cestino da cui è sempre possibile recuperarlo. Per fare questo e, in ogni caso, per gestire il cestino, è disponibile una voce nella console amministrativa.

Il terzo bottone viene usato per la modifica dei contenuti del asset mentre i successivi due permettono di spostarlo verso l'alto o verso il basso relativamente agli altri assets presenti. Il tasto "cut" e quello "copy" spostano o copiano questo elemento nella clipboard mentre il successivo crea, sempre nella clipboard, uno shortcut dell'elemento. L'ultimo pulsante serve per spostare l'elemento con il drag&drop del mouse.

Analizziamo, per un momento, la clipboard di WebGUI per chiarire le differenze tra i tre pulsanti che hanno a che fare con essa. Accessibile dal menu superiore sinistro, una volta che essa non sia vuota, è una zona di memoria ove è possibile porre degli elementi già esistenti che vanno, in un qualche modo, copiati su di un'altra pagina.

Premendo il pulsante di cut, di paste o quello dello shortcut si otterrà che andando nel menu della clipboard troveremo l'asset corrispondente identificato dallo stesso titolo che ha l'asset originale.

Spostandoci su di un'altra pagina e cliccando questo elemento della clipboard ci ritroveremo con una copia dell'elemento di partenza su questa nuova pagina. La differenza tra il cut e il copy sta nell'ovvio fatto che l'elemento copiato sparisce dalla pagina iniziale nel primo caso. La differenza tra il copy e lo shortcut è lievemente più sottile. Con il copy, i due elementi sono all'inizio identici ma è possibile modificare successivamente ambedue senza che l'altro subisca modifiche. Con lo shortcut, l'elemento copiato non è modificabile nel contenuto ma, se si modifica l'originale, la copia si aggiorna automaticamente con le modifiche eseguite.

La clipboard è anche raggiungibile dalla console amministrativo e qui è possibile eseguire ulteriori operazioni su di essa quale, per esempio, la cancellazione di eventuali elementi ivi copiati ma mai incollati.

Concetti generali sugli assets e sulle pagine di WebGUI.

Nel tentativo di aggiungere una nuova pagina al nostro sito, veniamo a scoprire una delle caratteristiche che rende grande WebGUI. Ogni elemento usabile dagli autori del sito è una risorsa (asset).

Gli assets sono tutta una serie di elementi visuali HTML preconfigurati e pronti all'uso. La pagina stessa è un tipo di asset che vedremo viene chiamato layout. Un immagine è un altro tipo di asset chiamato image, un elemento per eseguire votazioni un altro asset chiamato poll e cosi via.

Vedremo nel prossimo articolo in dettaglio ognuno di queste risorse e che vantaggi portano il fatto che tutti siano "imparenti" fra di loro ma possiamo subito dividere gli assets in due sotto categorie: quelli che possono essere contenitori per altri assets e quegli elementi isolati che non possono ossia contenere altri assets.

Alla prima categoria appartengono solo due risorse: il layout e il folder. Queste due risorse possono infatti contenere degli assets "figli" e si distinguono solo per il modo in cui mostrano questi "figli". Mentre il layout mostra direttamente l'html prodotto da ogni singolo figlio, il folder mostra un elenco di links che puntano ad ogni singolo "figlio".

Da un punto di vista dell'utente, il "layout" è sostanzialmente una pagina con differenti risorse, il "folder" può essere invece visto come una cartella che contenga le diverse sottorisorse.

Ovviamente, essendo layout e folder essi stessi degli assets è possibile che un folder possa essere un figlio di un "layout" o di un altro folder o un layout essere un figlio di un folder. Un layout può inoltre essere un figlio di un altro layout ma in questo caso diviene una sottopagina della pagina padre formando cosi una struttura gerarchica di navigazione delle pagine evidenziata nella mappa del sito e nel menu di navigazione laterale e superiore. WebGUI infatti raggruppa le pagine in una struttura gerarchica per cui se, trovandoci su di una data pagina, ne aggiungiamo una ulteriore, questa verrà aggiunta come sottopagina della pagina precedente e ciò verrà evidenziato nel menu laterale e nella mappa del sito da una indentatura della nuova pagina rispetto alla prima.

Andiamo quindi a trattare il contenitore principale di WebGUI: una pagina web o, in altri termini, una risorsa di tipo layout. Questa viene aggiunta nel sito, tramite la voce layout nel primo menu in alto.

Agendo su tale voce apparirà una schermata con una serie di tab. Prendiamo subito confidenza con essa in quanto, visto che tutto è un asset e che la pagina stessa è un asset, alcuni elementi di questa pagina saranno comuni anche agli altri assets.

Il primo tab contiene le proprietà generali della pagina. Innanzitutto è possibile impostare il titolo della pagina che genererà i tag <TITLE> e <H1> dell'HTML che verrà inviato all'utente. Si può quindi impostare il titolo del menù ossia il testo che verrà automaticamente inserito nel menù a sinistra ed è possibile specificare un valore più mnemonico che sarà passato al gateway index.pl per la navigazione a questa pagina. Il campo titolo viene preso come valore di default se il titolo del menu non è impostato. Se l'url non viene impostato WebGUI ne generà uno coerentemente con la posizione della nuova pagina e utilizzando il titolo come base per la costruzione dell'url.

Nel secondo tab viene definita la modalità con cui questa pagina viene visualizzata. La pagina non viene, per esempio, aggiunta nel menù a sinistra e nella mappa del sito se è attivo il flag hide from navigation.

Ovviamente la voce open in new window creerà dei link a questa pagina che la restituiranno in una nuova finestra del browser. Si possono poi  assegnare alla pagina i modelli grafici predefiniti. Come già accennato infatti, una delle caratteristiche dei C.M.S. è che la grafica viene definita in dei modelli predefiniti e questi vengono poi applicati ai vari elementi al fine di ottenere un aspetto grafico più omogeneo. L'elemento "style template" definisce proprio in quale ambiente grafico verrà incastrata la pagina ossia qual'è, per questa pagina, l'impostazione grafica di quello che le sta intorno dagli elementi laterali, superiori e inferiori al foglio di stile. Usualmente, in un sito, tutte le pagine utilizzano un unico style template ma nulla vieta di avere una sezione del sito con un layout più o meno differente. Alle pagine di questa sezione può quindi essere applicato uno style template differente.

La seconda impostazione definisce quale style template utilizzare nella modalità printable. Ogni pagina può infatti contenere un link che rende la pagina stampabile ossia formattata in modo tale da essere stampata "senza fronzoli" dall'utente. Il printable style configurato dovrà quindi puntare ad un template che definisce un contesto grafico più "semplice".

L' impostazione template di questo tab definisce la formattazione della parte centrale della pagina definendo in che modo potranno essere aggiunti gli assets. Lo standard è una modalità ad una sola colonna verticale ma sono già predefiniti modelli a due e tre colonne di diversa larghezza o modelli più complessi con sezioni orizzontali e verticali differenti. Ovviamente è molto semplice estendere questi modelli in base alle proprie esigenze.

Il terzo tab, chiamato security, contiene i possibili vincoli di questa pagina. Quindi una data di pubblicazione e di cancellazione automatica della pagina, la definizione di chi è l'autore della pagina, qual è il gruppo che può vedere questa pagine e chi può, oltre all'autore, editarla.

L'ultimo tab contiene alcune proprietà che influenzano l'header della pagina HTML generata. Innanzitutto nel campo synopsis si può dare una breve descrizione testuale del contenuto della pagina che viene, per esempio, letta dai vari motori di ricerca e che verrà da essi mostrata ai navigatori quale "riassunto" della pagina. Nel campo Extra HEAD è possibile poi aggiungere un qualsiasi header personalizzato che verrà aggiunto inalterato nella pagina ritornata al browser.

[ Manca la spiegazione di cosa sia un prototipe e un package ]

Note sul funzionamento interno di WebGUI

Vediamo macroscopicamente cosa succede in WebGUI quando un browser richiede una certa pagina del sito.

Tutte le richieste di pagine del sito vengono intercettate dallo script index.pl che, per questo motivo, è stato identificato come gateway. Questo script dirotta la richiesta al modulo WebGUI (lib/WebGUI.pm) che la analizza e la invia alla risorsa richiesta.

Supponendo che la richiesta sia proprio quella di ottenere una pagina del sito, questa viene dirottata dal modulo WebGUI al modulo WebGUI::Asset::Wobject::Layout (lib/WebGUI/Asset/Wobject/Layout.pm) che ottiene dal database l'elenco e il contenuto di tutti i assets figli inseriti nella pagina dall'autore.

Il contenuto delle pagine, gli assets, e le proprietà degli assets stessi non sono salvati sul filesystem ma su tabelle del database. Quindi, per ogni risorsa della pagina viene eseguito l'asset corrispondente WebGUI::Asset::XXX (lib/WebGUI/Asset/XXX.pm) che, in base ai dati presenti sul database, ritornera il proprio specifico blocco HTML. Tutti questi blocchi, assieme al modello di base della pagina vengono passati ad un modulo di templating chiamato WebGUI::Template (lib/WebGUI/Template.pm), che provvede ad assemblare il tutto e ritornare il BODY della pagina. Questo, incapsulato nell'HEAD viene ritornato al browser con lo stile definito.

Conclusioni

In questo articolo abbiamo analizzato alcune delle caratteristiche generali di C.M.S e in particolare di WebGUI. Abbiamo visto come installarlo e una panoramica sulle proprietà dell'oggetto layout ossia dell'oggetto che fa da modello nella creazione di una pagina del nostro sito in WebGUI.

Nel prossimo articolo vedremo come riempire tali pagine con gli strumenti offerti da WebGUI: gli assets.

JavaScript Menu Courtesy of Milonic.com





 Copyright© 1997-2006 Emiliano Bruni Online dal 16/08/1998 con visitatori Scrivimi all'indirizzo: