Al termine della guida, dovremmo avere a nostra disposizione un discreto bagaglio di strumenti con i quali elaborare un sorgente XML in un qualsiasi formato testuale.
In questa lezione esamineremo due casi reali di utilizzo particolarmente interessanti per la quantità di lavoro che consentono di risparmiare.
Un frontend flessibile con XSLT
La motivazione principale che ha spinto verso l’adozione di linguaggi di stile è la separazione della logica (o più semplicemente i dati) dalla presentazione all’interno di una pubblicazione Web.
Tradizionalmente, infatti, i programmatori dimostrano una scarsa propensione per lo stile di un sito, così come i producer mancano talvolta delle conoscenze necessarie a comunicare con il backend di una applicazione.
Con l’introduzione dei Cascading Style Sheet (CSS) si è in grado di associare, ad elementi arbitrari della pagina, uno stile definito secondo una sintassi differente da HTML. I CSS possono essere contenuti nel documento stesso, oppure in un file esterno comune a più pagine, risultando pertanto di più rapida manutenzione.
Al di là del vantaggio pratico, il motivo principale di questa separazione è ripulire il codice delle pagine di tutti quegli elementi che non descrivono i dati, ovvero quelli inerenti l’aspetto che questi dovrebbero avere una volta visualizzati. In questo modo si ottiene una quantità di codice inferiore in dimensioni e più significativa dei dati rappresentati.
Con un foglio di stile CSS è quindi possibile cambiare radicalmente l’aspetto di una pagina, posizionare precisamente o nascondere elementi di essa; non è tuttavia possibile eseguire alcuna modifica sostanziale sul loro contenuto. Per questo sono state introdotte le trasformazioni di stile XSL, all’interno delle quali XSLT esegue di fatto la traduzione dei contenuti.
Se questa tecnologia fosse esistita negli anni in cui i siti avevano spesso le tre versioni con-frames, senza-frames e solo-testo (per scarsità di banda ed evoluzione incontrollata di HTML e dei browser), si sarebbero potuti ridurre ad un terzo i costi in termini di tempo di un qualsiasi aggiornamento.
Ora i tempi sono cambiati e tuttavia le problematiche si sono solamente trasformate: le differenti versioni da realizzare sono diventate le pagine HTML per il sito Web, le card WML per il sito Wap, la versione cHTML per l’I-mode di Wind, il PDF delle pagine per una stampa di qualità e molte altre ancora. XML è il principale strumento per riuscire a sopravvivere a tutto questo.
Senza fare accademia, è opportuno ricordare quanto la strategia attualmente più diffusa per la realizzazione di siti Web è il consueto modello a tre strati (three tier model) che suddivide l’applicazione nelle seguenti componenti:
- un frontend (strato di presentazione o "presentation tier") costituito da pagine HTML statiche e da quelle prodotte dinamicamente da un linguaggio di scripting (ASP, JSP, PHP, …);
- uno strato intermedio (strato della logica, "middle tier" o "business tier") costituito appunto dal linguaggio di scripting che incorpora la logica dell’applicazione;
- un backend, (strato dei dati o "data tier") costituito in genere da un database relazionale, che contiene i dati da organizzare all’interno della pubblicazione Web.
I fogli di stile CSS si posizionano nel primo strato, paritetici alle pagine statiche per quanto utili nella realizzazione di un sito graficamente consistente.
L’opportunità che ci viene offerta con XSLT è rappresentata invece dall’inserimento tra i primi due strati di un ulteriore livello di astrazione.
All’interno di questo modello esteso, il linguaggio di scripting non è più costretto ad avere a che fare con il linguaggio di destinazione (come abbiamo visto non più ristretto al semplice HTML) e si può invece concentrare sull’interazione con il backend, avendo semplicemente cura di restituire al primo strato una lingua franca: XML.
All’interno dello strato intermedio è possibile a questo punto selezionare quale sia il foglio di stile XSLT da associare ai dati prodotti (basandosi sui MIME types consentiti specificati nella richiesta http oppure configurando differenti indirizzi di accesso alla risorsa) e istanziare la trasformazione che restituirà la pagina finale per i differenti media che potrebbero richiederla.
Il primo strado descritto sopra prende forma nella finestra di browser dell’utente e viene pertanto definito lato-client; il linguaggio di scripting è invece attivo sulla macchina che gestisce la richiesta dell’utente, di conseguenza lato-server. Per il fatto di inserirsi tra questi due strati, la trasformazione XSLT può essere eseguita in entrambi indifferentemente, come vedremo nelle prossime lezioni.
