• Nella riga 1 il motore di Rewrite viene abilitato.
• La riga 2 serve per gestire la localizzazione in inglese. Quando Apache riceve un URL composto da “en/” più una qualsiasi stringa che termina con “.php” memorizza tutta la stringa nella variabile $1. Poi il secondo blocco della di-rettiva alla riga 2 dice ad Apache che l’URL così individuato va tradotto in $1 concatenato a “.php?lang=en”. Il comando [QSA] stabilisce che eventuali parametri GET presenti dopo il nome della pagina .php individuata debbano essere aggiunti a quelli esistenti (cioè lang).
• La riga 3 funzione allo stesso modo, ma serve per gestire la lingua italiana. Il parametro [L] dice ad Apache che quella direttiva è l’ultima del file.
Ma perché in URC si utilizza il ModRewrite per gestire il multilingua? La risposta è semplice: per utilizzare dei file di script PHP univoci (un’unica pagina per tutte le lingue) ed evitare di dover inserire in ogni link (o URL) presente all’interno del programma il riferimento al parametro GET lang. In sostanza bisogna fare in modo che tutti gli script PHP possano recuperare l’indicazione con la lingua impostata dall’utente per visualizzare i testi dei contenuti nella lingua scelta. Chiaramente ci sono diversi modi per farlo ed alcune varianti consistono nell’utilizzare i Cookie o le sessioni PHP[3]. Ma il modo più semplice ed elegante per trasportare questo tipo di impostazione senza bisogno di scrivere ulteriore codice PHP, è usare il parametro GET in abbinata al ModRewrite. Vediamo subito perchè.
Ad esempio, consideriamo l’URL “en/setup/setup.php?comando=insert”; in base alle regole viste in precedenza (riga 2 dell’esempio) l’URL viene tradotto in “setup/se-tup.php?lang=en&comando=insert”. In sostanza, come è facile intuire, l’indicazione della lingua viene prelevata dal percorso dell’URL ed inserita come parametro GET. Il vantaggio nell’uso di questo meccanismo sta nel fatto che tutti i link della we-bapp potranno far uso di URL relativi, al fine di trasportare implicitamente proprio nell’URL richiesto l’indicazione della lingua impostata (senza bisogno di ricorrere al parametro GET lang in modo esplicito). Quindi se è stata impostata la lingua ingle-se, stiamo visitando la pagina “en/index.php” e in questa pagina siamo in presenza di un link che punta alla pagina “setup/setup.php”, nel percorso del link possiamo inserire l’URL relativo “./setup/setup.php”. Il browser alla pressione del link, essen-do l’URL di tipo relativo, punterà alla pagina “en/setup/setup.php”, trasportanessen-do implicitamente anche l’impostazione della lingua. Chiaramente sia la pagina “en/in-dex.php” che la pagina “en/setup/setup.php” nelle directory della webapp a livello fisico non esistono, poiché il prefisso “en/” è solo virtuale; a livello fisico esistono le pagine “index.php” e “setup/setup.php” che sono proprio quelle che vengono preleva-te da Apache dopo aver applicato il ModRewripreleva-te. Tali pagine potranno recuperare la lingua impostata dall’utente leggendo il contenuto della variabile GET lang.
5.3 L’ambiente e le tecnologie client-side
Dopo aver presentato i linguaggi e le tecnologie utilizzate in ambito server, analiz-ziamo quelle usate dalla webapp di URC in ambito client.
5. L’INTERFACCIA UTENTE WEB-BASED 85
UNOX fin dalle prime fasi di sviluppo del sistema ha voluto fare in modo che l’applicativo di interfaccia venisse realizzato con le più moderne tecnologie utilizzate in ambito Web, seguendo lo stile imposto dall’ormai famoso Web 2.0.
Nel Web 2.0 molte delle applicazioni web che vengono sviluppate fanno uso di linguaggi lato client in modo tale da rendere le pagine dinamiche sotto il profilo della presentazione dei dati. Con il termine “dinamiche” non si intende che le pagine debbano contenere animazioni o effetti grafici particolari, ma che gli elementi e i contenuti presenti nella pagina possano essere modificati e aggiornati in tempo reale senza dover ricaricare di volta in volta la pagina stessa. Ad esempio, se l’utente preme un pulsante per inserire un nuovo programma di cottura, con il vecchio stile di programmazione vi erano due possibilità:
• apertura nella stessa finestra del browser di un’apposita pagina (HTML o PHP) contenente un form HTML;
• apertura della stessa pagina in una nuova finestra del browser.
La prima soluzione è senza dubbio da preferire alla seconda, in quanto l’apertura di nuove finestre aumenta lo stress dell’utente durante la sua esperienza di navigazione. Ma in ogni caso nemmeno la prima soluzione è ideale, in quanto l’apertura di una nuova pagina nella stessa finestra del browser comporta la chiusura dei contenuti precedentemente visualizzati.
Per evitare di incorrere in questi inconvenienti e per rendere l’applicazione più veloce ed intuitiva, ciò che può essere fatto è che il nuovo form di inserimento del programma di cottura compaia all’interno della stessa pagina, ad esempio tramite la comparsa di un nuovo apposito riquadro.
Per riuscire ad implementare tale meccanismo occorre però ricorrere a linguaggi di programmazione lato client, i quali permettono di manipolare gli elementi HTML presenti nella pagina.
Come vedremo in seguito, la webapp di URC fa largo uso di tutte queste tecniche, al fine di rendere l’applicazione più intuitiva e semplice da utilizzare.
5.3.1 I fogli di stile CSS
Un aspetto presente in tutte le webapp di ultima generazione (e più in generale in tutto il Web moderno) è l’uso dei fogli di stile CSS (Cascading Style Sheets). Fino a qualche anno fa, infatti, il layout, i colori e gli stili della pagina venivano inseriti direttamente nel codice HTML. Oggigiorno invece si preferisce fare in modo che il codice HTML definisca solo la struttura della pagina a livello di blocchi di contenuti, delegando ai CSS la parte di definizione dello stile (colori, font, bordi, margini, posizionamenti, ecc).
Le regole per comporre il CSS sono contenute in un insieme di direttive (Recom-mendations) emanate a partire dal 1996 dal W3C.
A titolo esemplificativo, un estratto di foglio di stile utilizzato dalla webapp di URC è il seguente:
86 5.3. L’AMBIENTE E LE TECNOLOGIE CLIENT-SIDE
1 /∗∗∗∗∗ GENERALI ∗∗∗∗∗/
2 body { background−c o l o r :#F9F9F9 ; text −a l i g n : l e f t ; padding : 20 px 0px 0px 0 px ; f o n t : 1 2 px verdana , sans −s e r i f ; c o l o r :#000000; }
3 body a { t e x t −d e c o r a t i o n : none ; f o n t : 12 px verdana , sans−s e r i f ; c o l o r :#0066FF ; }
4 body a : h over { t e x t −d e c o r a t i o n : none ; background−c o l o r :#CCDDFF; f o n t : 12 px verdana , sans −s e r i f ; c o l o r :#0066FF ; }
5 body a img { b o r d e r : 0 ; }
6 h2 { t e x t −d e c o r a t i o n : none ; f o n t : 15 px verdana , sans−s e r i f ; c o l o r :#000000; background : none ; }
7 . mexOk { width :80%; margin : 2 0 px auto 20 px auto ; padding : 5 px ; f o n t : 1 2 px verdana , sans −s e r i f ; c o l o r :#336600; background−c o l o r :#EAFFDF ; b o r d e r : 1 px dashed #336600; t e x t −a l i g n : c e n t e r ; d i s p l a y : none ; }
8 . mexErr { width :80%; margin : 2 0 px auto 20 px auto ; padding : 5 px ; f o n t : 1 2 px verdana , sans −s e r i f ; c o l o r :#B74900 ; background−c o l o r :#FFDFB0 ; b o r d e r : 1 px dashed #B74900 ; d i s p l a y : none ; }
Nonostante vi sia quindi una standardizzazione delle regole, la più grande pro-blematica connessa all’uso dei CSS sta nella compatibilità cross-browser.
Ciò significa che browser diversi possono interpretare il codice CSS in modi total-mente diversi; il risultato è che la maggior parte delle volte la pagina presenta delle problematiche di layout che rendono difficile (se non impossibile) l’interpretazione dei contenuti da parte dell’utente. L’unico modo per risolvere il problema è effettua-re un’attenta analisi di debug con svariati test di compatibilità della webapp grazie a diversi browser durante tutta la fase di sviluppo dell’applicazione. Questa attività durante le fasi di sviluppo di URC è stata svolta pesantemente, per garantire una piena compatibilità dell’applicazione con tutti i più diffusi browser web nel pieno rispetto delle specifiche analizzate alla sezione 2.3 del testo.
5.3.2 JavaScript, jQuery e AJAX
Nella webapp di URC JavaScript viene usato in modo massiccio per la gestione dinamica di tuti i contenuti che compongono le pagine.
Anche JavaScript, però, un po’ come avviene per i CSS, presenta alcune proble-matiche nella compatibilità cross-browser. Sebbene le caratteristiche del linguaggio siano ben definite, alcune funzioni possono avere esiti e comportamenti diversi in browser diversi o, a volte, addirittura in versioni diverse dello stesso browser.
Inoltre la scrittura di determinate funzioni, come la selezione di un elemento DIV1 di una pagina HTML, possono richiedere più righe di codice, soprattutto in virtù di quanto appena detto (per la necessità di verificare la famiglia di browser che sta eseguendo lo script). Questa problematica si aggrava quando si vogliono applicare degli effetti grafici alle pagine.
Par tale motivo negli ultimi anni, complice inoltre la diffusione sempre più capil-lare di JavaScript all’interno delle pagine web, sono nati diversi framework (scritti per l’appunto in JavaScript) che permettono di risolvere tutte queste problematiche. Questi framework contengono in sostanza una serie di API che permettono di
5. L’INTERFACCIA UTENTE WEB-BASED 87
gere una gamma di funzioni scrivendo poche righe di codice. Il punto di forza di queste librerie è la piena compatibilità cross-browser di tutte le API.
Il framework più popolare, completo e performante è jQuery[5]. Tramite l’uso della libreria jQuery è possibile con poche righe di codice effettuare molte operazioni, come ad esempio ottenere l’altezza di un elemento, o farlo scomparire con effetto dissolvenza. Anche la gestione degli eventi è completamente standardizzata e gestita automaticamente assieme alla loro propagazione: è possibile ad esempio fare in modo che una determinata funzione JavaScript venga richiamata alla pressione di un tasto.
Figura 5.1: Interazione dei componenti AJAX paragonati alla staticità di un’applicazione web tradizionale.
L’oggetto principale di nome jQuery è genericamente utilizzato tramite il suo alias, il carattere $, per mantenere uniformità con la libreria Prototype (altro fra-mework JavaScript).