Consiglio Nazionale delle Ricerche - PUMA

C
Consiglio Nazionale delle Ricerche
Web Forms
Oltre l’HTML
M. Tesconi, A. Marchetti, F. Ronzano, S. Minutoli
IIT TR-09/2005
Technical report
Aprile 2005
Iit
Istituto di Informatica e Telematica
WEB FORMS
OLTRE L’HTML
Maurizio Tesconi, Andrea Marchetti, Francesco Ronzano, Salvatore Minutoli
Istituto di Informatica e Telematica, Area della Ricerca CNR
via G. Moruzzi 1, 56124 PISA, Italy
{Maurizio.Tesconi,Andrea.Marchetti,Salvatore.Minutoli}@iit.cnr.it – [email protected]
INDICE
Introduzione .......................................................................................................................................3
Verso le form HTML .........................................................................................................................4
Le form HTML...................................................................................................................................4
Lo scripting lato server per la gestione delle web form ...................................................................11
I linguaggi di scripting lato client e il loro impiego nella gestione delle web form.........................15
XForms e la standardizzazione e diffusione dell’XML ...................................................................21
Esempio di uso di XForms ...........................................................................................................27
Web Forms 2.0: la proposta di standard del Web Application Technology Working Group..........30
Le web form: soluzioni proprietarie.................................................................................................42
Microsoft ......................................................................................................................................42
Le pagine Web Form e la tecnologia ASP.NET ......................................................................42
Info Path ...................................................................................................................................44
Adobe ...........................................................................................................................................44
Adobe Form Designer 6.0 ........................................................................................................44
Macromedia..................................................................................................................................45
Macromedia Flash MX: le Form..............................................................................................45
Apache Cocoon e il framework Cocoon Forms ...............................................................................47
Apache Cocoon ............................................................................................................................47
Cocoon: il control flow ................................................................................................................50
Il framework Cocoon Forms ........................................................................................................53
Cocoon Forms: definizione delle form.....................................................................................54
Cocoon Forms: binding di un documento XML ......................................................................56
Cocoon Forms: flowscript e pipeline per la gestione delle form .............................................56
Esempio di uso di Cocoon Forms ............................................................................................60
Linguaggi XML per la definizione dell’interfaccia utente delle applicazioni .................................67
Mozilla: EXtensible User-interface Language.............................................................................71
Esempio di organizzazione di un file XUL..............................................................................75
Microsoft: EXtensible Application Markup Language................................................................79
Esempio di organizzazione di un file XAML. .........................................................................84
XUL versus XAML: l’evoluzione delle interfacce utente delle applicazioni web ......................86
Conclusioni.......................................................................................................................................89
Bibliografia.......................................................................................................................................91
Introduzione
Negli ultimi anni si è avuta una forte diffusione e un sempre più largo uso del
web per effettuare operazioni spesso molto differenti tra di loro, dalla ricerca di
informazioni all’interno di Internet, al commercio elettronico o anche a servizi bancari
e multimediali. Per compiere tali operazioni e quindi per far sì che le potenzialità del
web aumentino notevolmente è necessario, non solo poter spedire le informazioni
richieste dall’utente attraverso la rete, ma anche poter ricevere i dati di vario tipo
immessi dall’utente stesso. A tal fine vengono utilizzate le web form: con tale termine
si indicano in generale tutti i differenti tipi di tecnologie adoperate per permettere agli
utenti del web di inserire, e trasmettere ad un server, le informazioni necessarie per
la richiesta di un servizio.
In questo studio si intende analizzare rapidamente l’evoluzione delle tecnologie
finora adoperate per trattare le form nel web, per poi esaminare in maggiore dettaglio
le soluzioni più recentemente proposte riguardanti l’acquisizione e la gestione
dell’input degli utenti su web.
Nei capitoli iniziali si individuano i motivi che hanno portato, agli inizi degli anni
’90, all’introduzione delle form nell’HTML[6], linguaggio già allora universalmente
utilizzato per pubblicare e scambiare informazioni nel Web e prosegue con una breve
trattazione delle caratteristiche fondamentali delle stesse form. Vengono poi affrontati
gli sviluppi delle tecnologie di gestione dei moduli elettronici fino agli inizi del nostro
decennio: sono quindi considerati sia l’uso dello scripting lato server che
l’introduzione dei linguaggi di scripting lato client in riferimento alle form.
Nei capitoli successivi si considerano quindi in maggiore dettaglio le soluzioni
attualmente adoperate per richiedere e ricevere adeguatamente i dati inviati dagli
utenti nell’ambito dei servizi e delle applicazioni web. Questo viene fatto descrivendo
e valutando le caratteristiche di tali tecnologie con l’obiettivo di poterle paragonare tra
di loro. In alcuni casi verranno forniti dei semplici esempi pratici.
In tale contesto, vengono descritte le nuove proposte di tecnologie open
standard per la gestione dell’input degli utenti del web, tra cui XForms[10] del World
Wide Web Consortium[5] e il progetto Web Forms 2.0[20] del Web Hypertext
Application Technology Working Group[19]. Viene quindi presentato il framework
Cocoon Forms[25], per la gestione delle form delle applicazioni web sviluppate
appoggiandosi alla servlet Cocoon[22], una potente piattaforma di gestione di servizi
web basata fortemente sull’XML[11] e le tecnologie ad esso correlate, di cui viene
fornita una breve descrizione. Sono quindi considerate le principali tecnologie
proprietarie attualmente diffuse per la gestione delle form sul web. Infine vengono
analizzati i nuovi linguaggi di definizione dell’interfaccia utente per applicazioni web
(User Interface Definition Languages), utilizzati per definire l’interazione con l’utente
stesso in quella che, con buone probabilità, sarà la nuova generazione di
applicazioni di rete.
Verso le form HTML
Agli albori del web siti che non utilizzavano dati immessi dall’utente erano la
norma e fornivano un flusso di informazioni spesso statiche, che si muovevano
prevalentemente in un’unica direzione, da server a client, con poche possibilità di
effettiva interazione e una maggiore difficoltà di consultazione e individuazione delle
informazioni stesse.
Agli inizi degli anni novanta, con l’esplosione del Web e con la diffusione
dell’HTML[6] quale linguaggio universalmente utilizzato per pubblicare e scambiare
informazioni nel Web stesso, si è manifestata l’esigenza di una maggiore interattività
nell’uso di tale nuovo canale di comunicazione. Ciò si poteva ottenere dando la
possibilità agli utenti di immettere e inviare informazioni. Per fronteggiare tale
necessità, nel 1993 il World Wide Web Comsortium (W3C)[5] introdusse all’interno
delle specifiche HTML 2.0[7], le web form. Attraverso questi nuovi elementi del
linguaggio era possibile definire delle pagine web con cui reperire dati di vario tipo
immessi dall’utente.
Le successive versioni delle specifiche HTML hanno fondamentalmente
mantenuto, con pochi cambiamenti, le modalità con cui venivano incluse nella pagine
web le form fino ad arrivare alla versione 4.01 dell’HTML[8] che risulta essere l’ultima
versione non XML–based.
Le form HTML
Le principali caratteristiche delle form HTML, facendo riferimento alle specifiche
HTML 4.01 del World Wide Web Consortium, si possono descrivere come segue.
Le form HTML sono dei moduli elettronici che è possibile includere nelle pagine
web HTML; per mezzo di una form si può richiedere l’immissione di dati agli utenti del
web. Tali informazioni sono raccolte localmente dal browser e, di solito, inviate
attraverso la rete ad un server che le gestirà opportunamente.
Le form si presentano come un insieme di vari elementi, detti controlli, ognuno
dei quali serve per permettere all’utente di immettere determinate informazioni o di
effettuare una particolare azione. Ogni controllo è identificato per mezzo di un nome
specificato dall’attributo “name”; alla maggior parte dei controlli è possibile assegnare
un valore iniziale per mezzo dell’attributo “value”.
Per permettere una buona versatilità relativamente alle modalità di richiesta di
immissione di informazioni agli utenti del web, nelle specifiche delle form HTML viene
definito un cospicuo numero di controlli. Molti di questi controlli e vari loro attributi
non erano presenti nelle prime versioni dell’HTML che includevano le form (2.0 e
versioni immediatamente successive), sia perché tale estensione dell’HTML era
appena stata introdotta in queste versioni e molti dei miglioramenti aggiunti nel
seguito non erano ancora stati definiti, sia anche e soprattutto poiché non erano
ancora stati introdotti i linguaggi di scripting lato client1 (JScript[41] e JavaScript[35]).
Infatti con l’avvento della possibilità di definire degli script lato client, molte delle
caratteristiche dei controlli delle form HTML sono state modificate per permettere la
gestione della compilazione dei moduli elettronici e delle verifiche di validità dei dati
immessi direttamente sul client servendosi di opportuni script; essi consistono in
righe di codice interpretate a tempo di esecuzione e opportunamente strutturate per
interagire con gli elementi della form, controllandone, localmente sul client, la
compilazione. Tutti gli elementi che rappresentano dei pulsanti, così come il
meccanismo degli eventi e la loro gestione, sono stati aggiunti nelle specifiche delle
form HTML conseguentemente all’introduzione dello scripting lato client e del
Document Object Model[14], per poterne sfruttare le potenzialità.
I controlli definiti nelle specifiche delle form HTML 4.01 sono i seguenti:
•
BUTTON: permette l’inserimento nella form di un bottone che se attivato (ad
esempio tramite un click del mouse), provoca una determinata azione.
Esistono tre differenti tipi di bottoni: quelli “submit” che quando attivati inviano i
dati contenuti nella form, i bottoni “reset” utilizzati per resettare i valori di tutti i
controlli al loro stato iniziale ed i bottoni “push” adoperati per attivare delle
determinate funzioni definite tramite degli script lato client.
•
INPUT: tale elemento permette di specificare numerose tipologie di controlli
per mezzo del valore assegnato all’attributo “type”. Quest’ultimo può
assumere i seguenti valori:
¾ text campo per l’immissione di testo su singola linea;
1
I linguaggi di scripting lato client e il loro uso in relazione alle web form sono descritti
dettagliatamente nel capitolo “I linguaggi di scripting lato client e il loro impiego nella gestione delle
web form”.
¾ password campo per l’immissione di password (uguale al precedente ma i
caratteri digitati vengono visualizzati tutti con lo stesso simbolo, di solito un
asterisco per preservarne la segretezza);
¾ checkbox casella di selezione (è possibile selezionarla e deselezionarla a
piacimento);
¾ radio simili ai checkbox ma di solito riuniti in gruppi di due o più radio
button che condividono lo stesso valore dell’attributo “name” e tra i quali è
possibile selezionarne uno solo;
¾ submit crea un bottone per l’invio dei dati inseriti nella form;
¾ image determina un bottone sul quale verrà visualizzata un’immagine
indicata dal valore dell’attributo “src” dell’elemento <input>;
¾ reset crea un bottone per resettare i valori di tutti i controlli della form al
loro stato iniziale;
¾ button crea un bottone utile per attivare delle determinate funzioni definite
tramite degli script lato client;
¾ hidden definisce un controllo della form che non sarà renderizzato dallo
user agent;
¾ file permette all’utente di selezionare un file il cui contenuto sarà spedito in
rete assieme alle altre informazioni raccolte tramite la form.
•
SELECT: tale controllo permette di creare dei menù per presentare all’utente
differenti possibilità tra cui poter scegliere. Le varie scelte possibili (option)
possono
essere
raggruppate
logicamente
per
permettere
una
migliore
renderizzazione del controllo allo user agent (optgroup).
•
TEXTAREA: tale controllo permette di definire una casella di testo su più linee,
per raccogliere dei dati immessi dall’utente. E’ possibile indicarne le dimensioni
relativamente al numero di righe e di colonne che devono essere visualizzate.
Tutti i controlli presenti all’interno di una form, rappresentati ognuno da un
particolare elemento, devono essere inseriti all’interno dell’elemento <form> , che
funge da contenitore. Esso contiene gli attributi necessari a determinare le modalità
di spedizione dei dati raccolti per mezzo della form. In particolare è possibile definire
l’URI tramite il quale identificare il processo al quale inviare i dati collezionati
(attributo “action”), il metodo del protocollo HTTP che deve essere usato per inviare i
dati della form (attributo “method”), il tipo di codifica con la quale devono essere
elaborati i dati raccolti (attributo “enctype”) ed il tipo di set di codifica dei caratteri da
adoperare (attributo “accept-charset”). Nel caso in cui vengano inviati per mezzo
della form dei file si può indicare (attributo “accept”) una lista di tipi MIME di file di cui
è consentito l’upload.
E possibile associare una etichetta ad ogni controllo della form per mezzo
dell’elemento <label>, nel caso in cui non sia stata già definita direttamente
all’interno del controllo stesso. Grazie all’etichetta viene fornito del testo che
caratterizza la funzione del controllo nella form.
I vari controlli della form possono essere raggruppati logicamente grazie
all’elemento
<fieldset>; in tal modo l’user agent potrà visualizzare in maniera
omogenea (magari includendoli tutti in una determinata casella) i controlli di un
particolare gruppo. L’elemento <legend> permette di specificare una intestazione da
associare ad un certo gruppo di elementi.
Vi è la possibilità di definire l’ordine di selezione progressiva, per mezzo del
tasto di tabulazione, dei vari controlli della form, specificando per ogni elemento
l’attributo “tabindex”, assegnandogli un numero intero compreso tra 0 e 32767. L’user
agent selezionerà i controlli in base al valore crescente di tale numero specificato per
ogni controllo.
Per agevolare la selezione dei controlli della form è possibile determinare per
ogni controllo un tasto di accesso rapido che permette di selezionare il controllo
stesso se premuto contemporaneamente al tasto ALT (attributo “accesskey”).
Relativamente agli elementi <input> e <textarea> è contemplata la possibilità di
aggiungervi l’attributo “readonly” per impedirne la modifica da parte dell’utente,
rendendoli di sola lettura.
I vari controlli di una form possono essere disabilitati, escludendoli così dagli
elementi attivi della form stessa, per mezzo dell’aggiunta dell’attributo “disabled”.
Quando deve essere inviata una form vengono analizzati tutti i controlli che la
compongono e definiti quelli “successful” ovvero validi per l’invio dei dati immessi al
server. I controlli “successful” devono necessariamente essere posizionati all’interno
dell’elemento <form> ed avere l’attributo “name” definito. Controlli disabilitati,
checkbox, radio button e opzioni di un menù non selezionate costituiscono dei
controlli non “successful”, della presenza dei quali non vi sarà traccia tra i dati inviati,
raccolti per mezzo della form. I controlli nascosti (“hidden”) seppur non renderizzati
dallo user agent risultano essere “successful”. Dopo aver identificato tutti i controlli
“successful” di una form da inviare viene costruito e strutturato il form data set,
ovvero l’insieme dei dati da inviare. Quest’ultimo consiste in una lista di coppie
nome/valore relative ad ogni singolo controllo.
Il form data set viene poi codificato secondo il metodo di codifica specificato del
valore dell’attributo “enctype” dell’elemento <from>. Sono definiti i seguenti due
metodi di codifica:
1.
“application/x-www-formurlencoded”: nel form data set tutti gli spazi bianchi
sono sostituiti dal carattere “+” ed i caratteri non alfanumerici dalla codifica ASCII
esadecimale su due cifre preceduta dal carattere “%”. Ogni coppia nome/valore è
separata da quelle adiacenti per mezzo del carattere “&” ed ogni nome è separato
dal corrispondente valore dal carattere “=”. Questo metodo di codifica è utilizzato di
default.
2.
“multipart/form-data”: la precedente codifica è inefficiente per inviare grandi
quantità di caratteri non ASCII o dati binari (upload di file). In tale nuovo metodo di
codifica vengono create delle sezioni ognuna delle quali contiene i dati relativi ad
un controllo “successful”. Ognuna di queste parti è preceduta da un header
(intestazione) che ne determina, oltre al campo “content-disposition” che assume il
valore “form-data”, il nome del controllo riferito e il tipo MIME dei dati contenuti. Con
tale codifica è obbligatorio utilizzare il metodo POST del protocollo HTTP per
inviare i dati della form.
Dopo essere stati codificati, i dati vengono spediti al processo su server che ne
gestisce la ricezione, riferito tramite l’URI specificato dall’attributo “action”
dell’elemento <from>; l’attributo “method” di questo stesso elemento determina il
metodo di invio dei dati della form; GET o POST sono i metodi del protocollo HTTP
che possono essere adoperati. Il metodo GET è di solito usato, così come indicato
anche nelle specifiche del protocollo HTTP, quando l’invio dei dati della form non
comporta modifiche ai dati presenti sul server, ovvero nel caso in cui effettuare più
volte di seguito la stessa operazione di spedizione delle informazioni raccolte tramite
una form, equivale ad averla effettuata una sola volta; in tale situazione la form viene
detta idempotente. Il metodo GET può ad esempio essere utilizzato se, per mezzo di
una form, si vuole effettuare un’interrogazione remota ad un database; tale
operazione infatti non comporta alcuna modifica alla base di dati e non genera alcun
problema se viene ripetuta più volte di seguito. Il metodo POST al contrario viene
adoperato quando i dati inseriti nella form causano delle modifiche sul sistema a cui
vengono inviati i dati stessi; ad esempio viene usato il metodo POST se l’invio della
form provoca la modifica di un database, la conferma di un acquisto on-line,
l’iscrizione ad un determinato servizio di rete, etc. Le precedenti sono tutte operazioni
che se ripetute più volte possono ottenere di volta in volta risultati diversi, o in alcuni
casi ottenere una segnalazione di errore; in tal caso la form viene detta non
idempotente.
Nella seguente illustrazione viene mostrato come un browser web (nel caso
particolare Microsoft Internet Explorer 6) renderizza una form contenente i principali
controlli che possono essere adoperati nelle form HTML.
Lo scripting lato server per la gestione delle web form
(metodi di passaggio dei dati del protocollo HTTP)
Agli inizi degli anni ’90, periodo nel quale il web era in forte crescita ed
espansione e l’HTML, da poco standardizzato, rappresentava già il linguaggio base
per lo scambio di informazioni in rete, gran parte delle pagine web disponibili erano
statiche, ovvero contenevano informazioni memorizzate su server su determinati file
di cui era possibile richiedere la trasmissione per consultarli da postazioni remote.
L’aggiornamento
delle
informazioni
contenute
nelle
pagine
web
avveniva
normalmente rieditando il file sul quale era memorizzato il documento HTML stesso;
ciò richiedeva molto tempo e impegno agli sviluppatori di contenuti ed applicazioni
web. Oltretutto con le pagine web statiche non è possibile includere informazioni che
variano con rapidità o che sono selezionate da una particolare richiesta dell’utente; si
pensi al caso in cui tramite web si vogliano richiedere notizie sul numero di posti
rimasti liberi su un treno, sulle quotazioni di alcuni titoli di borsa o più semplicemente
sul numero di utenti che hanno visitato un determinato sito. Tali informazioni sono
soggette a variazioni molto frequenti e sarebbe impossibile gestirle e divulgarle con
delle pagine web statiche. Lo stesso problema si presenta se si vuole dare la
possibilità all’utente web di effettuare delle ricerche su degli archivi (si pensi ad un
motore di ricerca) o, più in generale, di richiedere delle informazioni in relazione a
particolari condizioni di ricerca e selezione dei dati. Una eventuale risposta a
richieste di questo genere varia a seconda dei parametri di ricerca specificati e
sarebbe impossibile da organizzare col meccanismo delle pagine web statiche.
Per rispondere a tali nuove esigenze del web, nella prima metà degli anni ’90, è
stato introdotto l’uso delle pagine web dinamiche, che non risiedono fisicamente su
un server, memorizzate su file, ma vengono generate dinamicamente ad ogni
richiesta da parte di un client; in questa maniera tali pagine possono contenere
informazioni aggiornate poiché reperite al momento della richiesta da parte del client,
andando a consultare eventualmente database o altre fonti di dati opportunamente
aggiornate per determinare il contenuto informativo del documento HTML che verrà
spedito.
E’ possibile generare le pagine web dinamiche sul server per mezzo di
opportuni programmi detti script che possono essere definiti utilizzano un qualsiasi
linguaggio di programmazione, come ad esempio Perl, il C, il C++ o anche Python,
tutti linguaggi di programmazione general purpose. Ogni volta che un client richiede
una pagina web dinamica, il server che riceve la richiesta ricerca e manda in
esecuzione lo script preposto a generarla; la pagina generata, che consiste
nell’output dell’esecuzione dello script, è raccolta in input dal server web stesso il
quale la invia in risposta al client. Tramite uno script è quindi, ad esempio, possibile
collegarsi con un database per reperire delle informazioni da includere nella pagina
web generata, o anche accedere sul server a particolari risorse sempre col fine di
reperire informazioni per definire in maniera dinamica i contenuti del documento
HTML costruito. Con il passare del tempo le applicazioni rese disponibili via web
sono divenute via via sempre più sofisticate rendendo necessaria la realizzazione di
script sempre più complessi. I linguaggi di programmazione come C, C++ (compilati),
Perl e Python (interpretati), seppur di alto livello, essendo di tipo general purpose, si
sono rivelati spesso non adeguati allo sviluppo di questi script.
Nel 1994 è stato ideato un nuovo linguaggio di scripting server-side che
consente lo sviluppo sia di siti generati dinamicamente, sia di applicazioni che
incorporano connessioni a database e data processing: il PHP[69] - Hypertext
PreProcessor. Per definire la generazione dinamica di documenti per il web, il PHP
permette di includere il proprio codice tra gli elementi del markup HTML consentendo
di definire con più immediatezza e rapidità le operazioni da compiere e il layout per le
pagine web generate. Tale linguaggio, a differenza di quelli di tipo general purpose
precedentemente menzionati, è stato concepito appositamente per supportare lo
sviluppo di siti ed applicazioni web dinamiche, infatti la sua struttura e le sue funzioni
rispondono perfettamente alle esigenze ed alle necessità degli sviluppatori di questo
settore. Il PHP è stato sviluppato quale software open source, è gestito da un
cospicuo numero di sviluppatori che lo aggiornano costantemente, si interfaccia con i
più diffusi database management system, opera totalmente con elaborazioni sul
server ed è disponibile per varie piattaforme. Per questi motivi attualmente il PHP è
uno dei linguaggi più usati per lo sviluppo di contenuti web dinamici ed applicazioni
web elaborate.
Anche la Microsoft ha sviluppato la tecnologia Active Server Pages (ASP)[44]
per la creazione di pagine web dinamiche; questa soluzione è ovviamente
proprietaria e disponibile solamente per piattaforme Microsoft. Le Active Server
Pages, attualmente incluse nella piattaforma .NET della Microsoft, permettono di
creare applicazioni web caratterizzate dalla gestione dinamica dei contenuti delle
pagine, ottenuta utilizzando uno stile di programmazione dichiarativo affiancato
dall’uso di linguaggi di scripting quali VBscript, JScript (simile a JavaScript), Python e
altri. Numerose sono anche le classi di oggetti disponibili per script ASP. Tale
soluzione resta però connessa all’ambiente Microsoft, alla piattaforma Windows
server, quindi proprietaria. Il PHP è spesso preferito per la gestione di contenuti web
dinamici sia poiché è open source, ma anche perché risulta molto potente ed
efficiente nelle elaborazioni.
La generazione di pagine web dinamiche può essere anche guidata da
parametri particolari definiti dall’utente al momento della richiesta di determinate
informazioni; ad esempio, si può voler dare la possibilità di effettuare particolari
ricerche su un database agli utenti che accedono ad un certo sito web, permettendo
loro di specificare le informazioni da ricercare e le modalità con cui la ricerca stessa
deve aver luogo o con cui i risultati devono essere notificati. Tali informazioni di solito
vengono reperite per mezzo delle web form, le quali permettono di ricevere i dati
immessi da un utente e di inviarli, opportunamente strutturati, al server. Le stesse
form HTML permettono di raccogliere dei dati immessi dall’utente tramite il usando
un formato prestabilito all’interno di messaggi HTTP, ad un server che li utilizza per
elaborazioni proprie, coinvolgendo magari ulteriori applicazioni.
Le pagine dinamiche, come è stato detto, vengono generate dinamicamente, in
risposta alla richiesta del client da programmi detti server script che vanno in
esecuzione sul server stesso. Nel caso in cui l’elaborazione delle pagine dinamiche
dipende dai dati immessi dall’utente web tramite una form, vi è la necessità di
passare in input allo script tali informazioni per permetterne l’accesso durante
l’esecuzione dello script stesso. Il server web che riceve i dati opportunamente
codificati dal client deve quindi interfacciarsi con lo script per comunicarglieli.
Il Common Gateway Interface – CGI[70] è uno standard che regola come
vengono invocati da parte del server web gli script e definisce le modalità di
passaggio allo script dei parametri, eventualmente immessi dall’utente tramite form.
L’interfaccia CGI determina una serie di variabili predefinite, dette variabili
d’ambiente, settate con valori opportuni dal server per raccogliere tutti i dati inviati dal
client, le quali vengono così passate come parametri di esecuzione allo script. Se le
informazioni contenute nella form HTML, opportunamente codificate, sono inviate al
server utilizzando il metodo GET del protocollo HTTP[18], queste saranno passate
allo script per mezzo della variabile d’ambiente QUERY_STRING, altrimenti nel caso di uso dei
metodi POST o PUT, i dati verranno inviati allo script su standard input. Lo script durante le proprie
elaborazioni accederà opportunamente alle variabili d’ambiente ed eventualmente
leggerà i dati ricevuti sullo standard input e ne utilizzerà il contenuto per generare
dinamicamente la pagina HTML; essa verrà immessa sullo standard output prima di
terminare l’esecuzione dello script e intercettata dal server che la invierà in risposta
al client, gestendo eventualmente l’aggiunta dell’header HTTP prima di spedirla. Gli
script lato server sono attualmente molto usati soprattutto nelle situazioni in cui vi è la
necessità di consultare, per rispondere alle richieste del client, informazioni reperibili
localmente sul server. Le form HTML sono tuttora il mezzo più usato sul web per
raccogliere i parametri da passare agli script su server; Google, uno tra i più noti
motori di ricerca, fa uso di server script elaborati adoperando Python.
Utilizzando degli script lato server aumentano notevolmente le potenzialità del
web, ma tale metodo di gestione e generazione delle pagine web in relazione ai dati
forniti in input dall’utente presenta anche alcuni evidenti svantaggi:
•
è spesso necessario sviluppare complicati programmi lato server in grado di
interpretare e gestire opportunamente i dati inviati dall’utente (client);
•
ogni volta che l’utente invia la form dopo un cambiamento, i dati vengono
inviati al server web, ridiretti verso un’applicazione specifica tramite interfaccia
CGI ed elaborati; infine un’eventuale pagina HTML contente i risultati delle
elaborazione è restituita al client. Ciò aumenta il traffico sulla rete e carica la
CPU del server, rallentandola. Si pensi al caso in cui i dati immessi con una
form da client sono errati ed è necessario rispedire la form al client generando
traffico aggiuntivo e caricando il server con elaborazioni anche basilari per il
controllo della validità dei dati stessi.
Per concludere questa breve trattazione dello scripting su server (supportato
dalle web form nell’interfacciarsi con i client), verrà ora analizzato come l’HTML
gestisce e invia i dati di una form in relazione all’uso del metodo GET o POST
dell’HTTP nelle operazioni di spedizione. Quando una form viene inviata, il browser
ne determina tutti i controlli “successful”, ovvero quelli relativi a dati validi per essere
spediti e forma per ognuno di questi controlli una coppia nome/valore che lo
descrive. Le varie coppie nome/valore, nel caso in cui si usa il metodo di codifica
“application/x-www-urlencoded”, vengono unite a formare un’unica stinga così
strutturata: tutti i caratteri non alfanumerici vengono sostituiti dalla loro codifica ASCII
su due cifre esadecimali preceduta dal carattere “?”; gli spazi vengono sostituiti dal
carattere “+”; ogni nome è connesso al proprio valore per mezzo del carattere “=”; le
coppie nome/valore sono separate dal carattere “&”.
Se si usa il metodo GET per spedire la form tale stringa, che può essere lunga
al massimo 256 caratteri, viene concatenata al valore dell’URI nell’intestazione del
pacchetto HTTP, separata dall’URI stesso per mezzo del carattere “?”. Ad esempio si
può avere il seguente URI esteso comprendente i dati di una form con due campi di
input
per
l’immissione
di
nome
e
cognome:
“http://www.miodom.it/pagina.html?nome=chiara&cognome=rossi”.
Sul
server
la
stringa che segue il “?” all’interno dell’URI viene passata allo script per mezzo della
variabile d’ambiente QUERY_STRING dell’interfaccia CGI.
Nel caso in cui si sceglie il metodo POST la stringa contenente le coppie
nome/valore viene inserita nel corpo del messaggio HTTP, immediatamente dopo
l’header.
I linguaggi di scripting lato client e il loro impiego nella
gestione delle web form
Nel 1995 Netscape, organizzazione che rappresenta uno dei principali promoter
mondiali per la produzione e la diffusione di software open source, ha introdotto nel
proprio browser Netscape Navigator, arrivato allora alla versione 2.0, un nuovo
linguaggio di scripting che permetteva ai web designer di interagire con i vari
elementi di cui si componevano le pagine web: immagini, form, link, etc. Tale nuovo
linguaggio era però stato incluso in primo luogo per fornire possibilità di adoperare su
web le applet Java; queste sono dei programmi scritti utilizzando Java, i quali
possono essere inclusi nelle pagine HTML pressappoco con la stessa facilità con la
quale vengono incluse delle immagini e permettono di interagire con l’utente; ve ne
sono varie che implementano particolari effetti grafici. Nel ’95 infatti la Netscape
collaborava strettamente con la Sun Microsystem, l’ideatrice di Java, e da tale
rapporto di cooperazione derivò il tentativo di implementare nel browser Netscape il
supporto alle applet Java. Il 4 dicembre del ’95 Nescape e Sun annunciarono
l’introduzione di questo nuovo linguaggio di scripting lato client che in poco tempo
divenne largamente adoperato dagli sviluppatori web prevalentemente per
manipolare immagini e documenti web. Il nome inizialmente attribuito al linguaggio è
stato LiveScript ad indicare la vivacità, la natura dinamica che veniva aggiunta alle
pagine web che lo adoperavano. Il successo di LiveScript fu notevole, molto
probabilmente in relazione alla grande semplicità con la quale era possibile
aggiungere le nuove caratteristiche di dinamicità ai contenuti del web; il codice di
LiveScript, facile da elaborare, veniva inviato al client allegato alla pagina web alla
quale era connesso ed interpretato dal client stesso permettendo di gestire la
visualizzazione dei contenuti della pagina stessa. Dopo alcuni mesi dall’annuncio di
LiveScript, Netscape, in omaggio al linguaggio Java della Sun Microsystem, decise di
ribattezzare LiveScript col nome di JavaScript, che tuttora conserva.
La Microsoft rispose all’introduzione di JavaScript aggiungendo prima il
supporto per VBScript su Internet Explorer e immediatamente dopo, precisamente il
16 giugno del ’96, annunciando una prima versione di un proprio linguaggio di
scripting, chiamato JScript, simile per molti aspetti a JavaScript. L’introduzione da
parte della Microsoft e del linguaggio JScript e le conseguenti prevedibili
incompatibilità tra gli script JavaScript e quelli JScript, spinsero Netscape e Sun a
standardizzare il proprio linguaggio di scripting con il supporto della European
Computer Manufacturers Association (ECMA)[71], organizzazione dedicata alla
standardizzazione di sistemi di Information and Comunication Technology – ITC.
Tale lavoro di standardizzazione, iniziato nel novembre ’96, fu adottato dalla
ECMA nel giugno del ’97 (documento di specifiche ECMA_262) e nell’aprile dell’anno
successivo anche dalla ISO (International Standard Organization). Il linguaggio di
scripting così definito viene riconosciuto come ECMAScript[72] e raccoglie in sé
alcune delle funzionalità base definendo quindi un modello ad oggetti (object model)
per trattare i documenti HTML.
Nello stesso periodo sia la Microsoft che Netscape introdussero sul mercato le
versioni 4.0 dei propri browser, ognuna delle quali presentava un modello ad oggetti
proprietario per permettere agli script, rispettivamente JScript e JavaScript, di
agganciarsi e gestire i documenti HTML. Era nato ciò che da allora viene riferito
come “HTML dinamico”; esso consiste nella possibilità di adoperare congiuntamente
per gestire i contenuti web, l’HTML, JavaScript (o JScript) e i fogli di stile Cascading
Style Sheet (CSS[9])definiti dal World Wide Web Consortium per determinare con più
immediatezza le proprietà e lo stile delle varie parti di un documento HTML. Con
l’HTML dinamico si aveva la possibilità di elaborare pagine web molto più ricche di
grafica ed interattività, oltre che più flessibili nella gestione. Gli sviluppatori di
applicazioni web però si trovarono in evidente difficoltà nel produrre documenti HTML
che includessero script compatibili sia con Netscape Navigator che con Internet
Explorer e si adottarono diverse soluzioni, spesso provvisorie, per risolvere tale
problema di incompatibilità di fondo; ad esempio venivano fornite differenti versioni di
un documento HTML o di parti di questo a seconda del browser utilizzato dal client.
Anche per ciò che riguarda l’implementazione dei fogli di stile CSS, il comportamento
del browser web Netscape Comunicator differiva da quello di Internet Explorer e
nessuno dei due era aderente del tutto con le specifiche del World Wide Web
Consortium.
Proprio in questo periodo Netscape, Microsoft e molte altre parti interessate
lavorarono assieme al World Wide Web Consortium per definire e standardizzare
una versione di base comune e condivisa del Document Object Model (DOM),
ovvero di un’interfaccia indipendente dal particolare linguaggio e dalla specifica
piattaforma,
utilizzata
per
permettere
a
programmi
e
script
di
accedere
dinamicamente ed aggiornare il contenuto, la struttura e lo stile di documenti (ad
esempio pagine web HTML). Il DOM, il lavoro per la definizione del quale era iniziato
nell’ottobre del 1997, fu standardizzato dal World Wide Web Consortium nell’ottobre
del 1998. Per mezzo del DOM viene quindi definito un object model che, seguendo i
principi della programmazione orientata agli oggetti, permette di gestire i documenti
HTML (o, più in generale, XML) per mezzo di gerarchie di oggetti che ne
rappresentano le varie parti e ne determinano la struttura e le relazioni reciproche;
viene conseguentemente definita l’interfaccia da adoperare per accedere e
manipolare tali oggetti in maniera efficace.
Il DOM è stato sviluppato dal World Wide Web Consortium per passi successivi
detti livelli (level); ogni livello espande le funzionalità ed introduce nuove
caratteristiche rispetto a quello precedente. Il “level 0” sostanzialmente formalizza
quanto era già implementato sui browser Netscape e Explorer relativamente
all’interfaccia per mezzo della quale gli script accedevano ai documenti HTML, al
momento della formazione del gruppo di lavoro per la definizione del DOM. Nel “level
1” sono definite le funzionalità per la navigazione e la manipolazione dei documenti
HTML e, più in generale, XML; esso è stato standardizzato nell’ottobre 1998. Nel
“level 2” viene aggiunto al DOM il supporto di un object model per i fogli di stile,
fornendo quindi la possibilità di accedere e manipolare le informazioni riguardanti lo
stile di un documento. Viene oltretutto definito un modello di eventi (event model) per
mezzo del quale è possibile associare a differenti azioni o fasi elaborative di un
documento la generazione di particolari eventi che verranno opportunamente
propagati e notificati ai vari elementi che formano la struttura ad albero del
documento, ed eventualmente gestiti per mezzo dell’invocazione di script
appositamente definiti per tale fine, detti appunto event handler (gestori di eventi).
Attualmente è in fase di ultimazione l’elaborazione del DOM “level 3” che, per quanto
riguarda alcune sue parti, è già stato standardizzato. Esso aggiunge nuovi eventi e
permette il supporto di molte caratteristiche dell’XML quali ad esempio la validazione
di documenti in relazione ad una Document Type Definition (DTD[15]) o ad un
XMLSchema[16]; questi due termini si riferiscono a delle particolari modalità di
definizione della struttura e dell’organizzazione di un documento XML. In relazione
alle indicazioni incluse in questi documenti e a regole universalmente valide
riguardanti la struttura dei documenti XML, ogni singola istanza di documento può
essere validata in relazione sia al rispetto delle regole generali valide per ogni
documento XML, che di quelle specifiche per una classe di documenti XML, definite
per mezzo di una DTD o di uno Schema. Nel DOM “level 3” vengono oltretutto
definite nuove possibilità di formattazione dei documenti e determinate le modalità
per memorizzare e reperire dalla memoria le informazioni contenute in un
documento.
Tramite script è quindi possibile aggiungere dei semplici frammenti di codice
alle pagine HTML, interpretati lato client durante la visualizzazione della pagina
stessa, così da gestire delle elaborazioni dinamiche; gli script possono accedere e
modificare il contenuto di un documento HTML; di solito sono attivati al verificarsi di
particolari eventi.
L’uso degli script ha trovato subito applicazione, apportando notevoli vantaggi,
nella gestione delle web form. Includendo appositi script nelle pagine web contenenti
delle form è possibile effettuare una prima validazione lato client dei dati immessi
dall’utente prima che vengano inviati al server, evitando di svolgere tutte le
operazioni di verifica della correttezza dell’input dell’utente sul server; in tale maniera
viene alleggerito sia il carico elaborativo della CPU del server, sia il traffico circolante
in rete. Per mezzo di script si possono validare i dati immessi dall’utente e gestire la
visualizzazione di informazioni di errore in caso di insuccesso, fornendo dei
suggerimenti per la correzione. E’ anche possibile determinare la compilazione
dinamica delle form variando la struttura di alcuni controlli in relazione ai dati fino a
quel momento inseriti nel modulo elettronico. Possibili situazioni in cui si può
effettuare una validazione dei dati lato client per mezzo di script, prima di inviarli in
rete, sono i seguenti:
•
verificare che la password digitata da un utente abbia una lunghezza minima
definita (numero di caratteri);
•
verificare che un campo di input destinato a contenere un indirizzo e-mail
effettivamente contenga una stringa di caratteri del tipo [email protected], ove col
simbolo X si rappresenta una qualsiasi stringa (più in generale si può
verificare che dei dati immessi in input rispettino le regole di formattazione di
una qualsiasi espressione regolare);
•
controllare se almeno un’opzione di una lista è stata selezionata dall’utente;
•
controllare se sono uguali una password digitata in una casella di input e la
sua ridigitazione per conferma in una seconda casella di input;
•
verificare se l’utente ha compilato i campi della form obbligatori.
Tali script possono essere attivati da determinati eventi o in particolari condizioni;
ad esempio è possibile controllare il contenuto della form immediatamente prima
di spedirla e bloccare tutto in caso di insuccesso, oppure si possono controllare i
dati immessi man mano che l’utente compila i campi, permettendo un feedback
più immediato.
Per rendersi conto delle possibilità degli script Javascript si analizzino i seguenti
due semplici esempi:
1. Si vuole verificare se un campo di immissione di testo è stato riempito con la
digitazione di almeno un carattere; se ciò non accade si mostra un messaggio
all’utente su una finestra di poup.
Documento HTML:
…
<form name=”form1” action=”…” enctype=”…” method=”…”>
…
<input type=”text” name=”in1” onblur=”script1();”>
…
</form>
…
Script:
...
function script1(){
if (document.form1.in1.value.length == 0) {
alert("Immettere i dati nel campo di
testo!!!\n");
return false;
} return true; }
...
Per mezzo di questo script si accede all’elemento input di nome “in1” della
form e se ne verifica la lunghezza (numero di caratteri) per mezzo della
funzione “length()” che, se applicata su un oggetto stringa, ritorna il numero di
caratteri della stringa stessa; se è nulla ovvero l’utente non ha immesso alcun
dato nella casella di testo si visualizza un messaggio su una finestra di pop
up. Tale script viene eseguito conseguentemente all’evento “onblur”
(onblur=”script1();”) ovvero va in esecuzione tutte le volte che viene
deselezionata la casella di testo della form.
1. Si vuole disabilitare il checkbox “checkB” se l’utente deseleziona il checkbox
“checkA”
Documento HTML:
…
<form name=”form2” action=”…” enctype=”…” method=”…”>
…
<input type=”checkbox” name=”checkA” onclick=”script2();”>
<input type=”checkbox” name=”checkB”>
…
</form>
…
Script:
...
function script2(){
if (document.form2.checkA.checked == false)
document.form2.checkB.disabled = true;
if (document.form2.checkA.checked == true)
document.form2.checkB.disabled = false;
return; }
...
Ogni volta che si clicca col mouse sul checkbox “checkA”, ovvero viene
generato l’evento “onclick” dal controllo “checkA” della form, si verifica se tale
casella è selezionata; se non lo è si disabilita il checkbox “checkB” ponendo a
“true” la proprietà disabled, altrimenti lo si abilita ponendola a “false”.
Con l’introduzione di script lato client è quindi possibile risolvere, con elaborazioni
locali sul client, i problemi relativi alla validazione dei dati immessi ed al controllo
della compilazione di una form alleggerendo le elaborazioni del server ed il carico di
traffico della rete; oltretutto l’utente può avere un feedback immediato durante la
compilazione della form poiché i controlli sui dati immessi sono svolti localmente.
Ovviamente è possibile adoperare gli script, per ciò che riguarda la compilazione
delle form, solamente per quelle verifiche che non richiedono controlli che
coinvolgono dati che solo il server possiede (in tali situazioni si possono adoperare
script su server). In ogni caso le potenzialità degli script sono notevoli ed
ampiamente sfruttate per la gestione delle form. Di frequente accade però che per
gestire situazioni particolari gli script divengono difficili da elaborare e mantenere
funzionanti nel tempo, in relazione ad eventuali modifiche di cui sono oggetto le form
e le pagine web che le contengono. Spesso vi sono alcune frequenti verifiche basilari
sui controlli di una form (tipo di dato immesso, conformità con un’espressione
regolare da parte di una stringa, etc.) che, se effettuate tramite script, risultano
essere onerose e ripetitive per lo sviluppatore e appesantiscono le pagine web. Per
tali motivi attualmente si stanno sviluppando nuove modalità di gestione lato client
dei dati immessi tramite una form, adoperando, ad esempio, controlli sulla validità e
sulla struttura delle form definibili mediante sintassi dichiarativa; tali problematiche e
le soluzioni verso le quali il web si sta orientando saranno trattate nel seguito.
XForms e la standardizzazione e diffusione dell’XML
Con il passare del tempo e con la nascita e lo sviluppo di nuove tecnologie web le
form HTML, che hanno rappresentato durante gli anni novanta il motore dello
sviluppo del commercio elettronico e, più in generale, un mezzo per incrementare
notevolmente le potenzialità del web, hanno messo in evidenza vari aspetti che
potevano essere migliorati.
Nel 1998 è stato standardizzato dal W3C, dopo quasi due anni di attività di
formulazione, l’Extensible Markup Language (XML)[11], un potente linguaggio di
definizione della struttura logica di documenti elettronici detti documenti XML. Questi
ultimi sono caratterizzati dalla possibilità di separare e gestire indipendentemente la
struttura logica, il contenuto e le modalità di visualizzazione (la presentazione). Tali
documenti presentano un’elevata portabilità permettendo lo scambio e la
visualizzazione dei dati contenuti su piattaforme differenti dotate di appositi
programmi detti processori XML; essi si occupano dell’elaborazione dei documenti
XML stessi.
A partire da allora l’XML e numerose tecnologie correlate sono state messe a punto
definendo nuovi linguaggi di markup con differenti finalità. Esse si sono sempre più
diffuse in numerosi ambiti applicativi.
Nel 2000 è stato standardizzato anche l’Extensible Hypertext Markup Language,
XHTML 1.0[17], riformulazione del linguaggio HTML, giunto allora alla versione 4,
con una sintassi conforme alle specifiche XML 1.0. Nello stesso tempo, seguendo
alcuni accorgimenti, si conservò la possibilità di visualizzazione dei documenti su
user agent compatibili con HTML 4.
Col passare del tempo, a causa della crescente diffusione di servizi e applicazioni
web che richiedevano l’inserimento, da parte degli utenti del web stesso, di una
maggiore quantità di dati e con una struttura sempre più complessa, le form HTML,
come già accennato, hanno evidenziato alcuni limiti; tra questi vi sono un forte
legame tra contenuto e presentazione, la necessità di utilizzare spesso script anche
complessi per la loro gestione oltre che una scarsa integrazione con l’XML,
tecnologia chiave del World Wide Web Consortium (W3C), mezzo potente e
flessibile, attualmente affermatosi come la “lingua franca” del web.
Per far fronte a tali necessità, a partire da aprile 2000, il World Wide Web Consortium
ha iniziato a lavorare ad un progetto di definizione di quella che sarebbe stata la
nuova generazione di form sul web: XForms[10].
Attualmente il W3C ha messo a punto e standardizzato la tecnologia XForms
definendo nuove modalità di gestione dei moduli elettronici al fine di permettere una
maggiore interazione con gli utenti del web, più flessibilità e potenza nella gestione
dei dati immessi dagli utenti stessi, oltre che una forte integrazione con XML.
XForms è stato sviluppato definendo un apposito linguaggio di markup adatto ad
essere inserito all’interno di altri documenti XML che utilizzano un qualsiasi tipo di
markup (come ad esempio documenti HTML o SVG).
XForms è platform-indipendent e XML-based. Con XForms è possibile separare
l’organizzazione logica dei dati (cosa fa la form, che informazioni vuole ricavare e
come) dalla presentazione o modalità di visualizzazione. La stessa struttura logica
della form può essere infatti visualizzata opportunamente su differenti sistemi tramite
interfacce utente specifiche: browser tradizionale, PDA, mobile phone o browser
vocale.
Inoltre, utilizzando XForms, è possibile definire con l’aggiunta di markup (elementi ed
attributi) proprietà anche complesse che i dati inseriti dall’utente nella compilazione
del modulo elettronico devono verificare o particolari relazioni tra i valori dei campi di
una form. Si possono gestire anche un cospicuo numero di eventi ed elaborare form
complesse senza fare ricorso a script specifici e spesso molto articolati per ottenere
lo stesso risultato.
Lo scambio dei dati con l’utente avviene attraverso documenti XML la cui struttura è
definita appositamente dall’autore della form per contenere i dati stessi. La form può
essere precompilata con il contenuto di un documento XML esterno; a compilazione
terminata può essere inviata al server quale documento XML riempito con i dati
immessi dall’utente secondo regole di corrispondenza definite, con sintassi XForms,
dall’autore della form stessa.
Per supportare XForms sulla piattaforma dell’utente deve essere disponibile un
processore XForms, spesso aggiunto quale plug-in agli attuali browser, che si
occupa di interpretare la struttura delle form e visualizzare opportunamente i controlli
necessari per reperire i dati immessi dall’utente, validandoli ed inviandoli in risposta
al server tramite un documento XML appositamente strutturato per contenerli.
Tutti gli elementi del markup di XForms sono definiti in un namespace al seguente
URI:
http://www.w3.org/2002/xforms.
Viene ora analizzato in maggior dettaglio come è strutturato un documento XForms.
L’elemento base di un documento XForms è l’elemento <model> che rappresenta la
radice della definizione del modello XForms e tipicamente costituisce una zona del
documento XML contenente la form che non viene renderizzata.
All’interno dell’elemento <model> si trova l’elemento <instance> usato come
contenitore dell’instance data ovvero di un’istanza di documento XML che può, in
alternativa, essere individuata attraverso un riferimento a file esterno. Tale
documento XML rappresenta la struttura all’interno della quale inserire i dati immessi
dall’utente durante la compilazione della form affinché i dati stessi siano in seguito
spediti in formato XML. Spesso l’instance data viene anche utilizzata al momento
della visualizzazione iniziale della form per reperire i dati di default da mostrare
all’utente quali valori iniziali di determinati controlli.
All’interno dell’elemento <model> possono esservi uno o più elementi <bind> che
specificano dei vincoli sui dati dell’instance data. L’elemento <bind> può specificare
tramite i propri attributi sia il nodo/i nodi dell’instance data a cui fa riferimento
utilizzando delle espressioni XPath (attributo “nodeset”), che le proprietà che i dati
destinati ad essere immagazzinati in tale nodo/in tali nodi devono verificare. Ad
esempio l’attributo “type” determina, relativamente alle informazioni contenute nel
nodo in questione, un particolare tipo di dato tra quelli definiti nelle specifiche
XMLSchema; l’attributo “required” indica se è necessario per validare la form che il
nodo selezionato non sia lasciato vuoto; l’attributo “constraint” specifica un vincolo da
verificarsi relativamente ad uno a più nodi, definito utilizzando una espressione
XPath che ritorna un valore booleano; l’attributo “readonly” indica che il contenuto di
un nodo dell’instance data è di sola lettura ovvero che il controllo associato a quel
nodo non può essere usato per modificare i dati in esso contenuti; l’attributo
“calculate” permette di definire un’ espressione XPath per mezzo della quale
effettuare delle elaborazioni che possono coinvolgere altre parti dell’instance data ed
il cui risultato, interpretato come una stringa, determinerà il valore del nodo in
questione.
Infine, internamente all’elemento <model>, deve essere specificato tramite
l’elemento <submission> l’URL al quale il documento XML contenente i dati raccolti
tramite i controlli della form deve essere inviato.
E’ possibile oltretutto indicare per mezzo dell’attributo “schema” dell’elemento
<model> un riferimento ad una DTD o analogamente ad un XMLSchema dove viene
meglio definita la struttura dell’instance data.
Dopo aver determinato il modello XForms si possono inserire all’interno del
documento XML che includerà la form (editato utilizzando un particolare linguaggio di
markup come potrebbe essere l’HTML) i controlli XForms nella posizione desiderata;
questi rappresentano gli effettivi elementi di interazione con l’utente per la raccolta
dei dati.
I processori XForms, dopo aver analizzato ed interpretato opportunamente il modello
XForms, si occupano di esaminare gli elementi di marcatura utilizzati per definire e
posizionare i vari controlli visualizzandoli adeguatamente all’utente finale al fine di
permettergli di inserire le informazioni richieste.
I controlli che possono essere utilizzati all’interno di un documento XForms sono i
seguenti :
¾
<input>
definisce un generico ingresso;
¾
<secret>
definisce un ingresso criptato;
¾
<textarea>
definisce un area di testo;
¾
<output>
definisce una generica uscita;
¾
<upload>
definisce un file locale per fare l’upload;
¾
<range>
definisce un intervallo;
¾
<trigger>
definisce un pulsante;
¾
<submit>
definisce il pulsante per fare l’invio dei dati;
¾
<select>
definisce una scelta multipla;
¾
<select1>
definisce una scelta singola;
Per determinare le modalità per immettere i dati raccolti tramite i controlli della form
nel documento XML da inviare al server (il cui modello è definito mediante l’instance
data) è previsto l’attributo “ref”. Questo l’attributo può essere definito per tutti i
controlli e viene specificato, per mezzo di una espressione XPath, l’elemento o
l’attributo dell’instance data che conterrà i dati immessi dall’utente utilizzando il
controllo stesso. Lo stesso risultato può essere ottenuto indicando, quale valore
dell’attributo “bind” di un determinato controllo, l’ID di un elemento <bind> facente
parte del modello della form (quindi incluso all’interno dell’elemento <model>); i dati
reperiti tramite tale controllo saranno immessi nell’elemento dell’instance data a cui
fa riferimento l’elemento <bind> selezionato. In generale, tale operazione di
collegamento tra i dati reperiti attraverso i controlli e le locazioni all’interno
dell’instance data destinate a contenerli è detta binding.
La frequenza degli aggiornamenti dell’instance data durante la compilazione della
form è regolata dall’attributo “incremental”, aggiunto, se necessario, ai singoli
controlli; tale attributo può essere settato con i valori false (default) o true. Se risulta
essere false l’aggiornamento dell’instance data avviene ogni volta che un utente
deseleziona un controllo dopo averne modificato il contenuto; se invece “incremental”
è posto a true gli aggiornamenti dell’instance data avvengono con una frequenza
maggiore determinata dal particolare processore XForms in uso.
Ogni elemento del markup XForms che definisce un controllo può contenere ulteriori
elementi utili a specificare un’etichetta per il controllo (label), un messaggio di aiuto
per l’interazione dell’utente con lo specifico controllo (help), o anche un avviso da
mostrare nel caso in cui si verifichino situazioni di errore (alert).
E’ possibile, adoperando elementi <group>, raggruppare assieme dei controlli di una
form in maniera tale da poter gestire collettivamente le proprietà condivise da tutti i
controlli di un gruppo; in tale modo si ha anche la possibilità di raggruppare
visivamente i controlli che richiedono informazioni strettamente correlate così da
agevolare l’utente nella compilazione della form.
Tramite l’elemento <switch> si ha la possibilità di specificare differenti sezioni della
form delle quali solamente una per volta sarà mostrata per la compilazione all’utente
finale; tali sezioni sono incluse ciascuna in un elemento <case> figlio dell’elemento
<switch>. Tramite opportuni controlli l’utente potrà scegliere quale sezione
visualizzare.
Con XForms vi è la possibilità di gestire con relativa semplicità delle strutture di
controlli che si ripetono una o più volte (ad esempio, una lista di articoli da ordinare
con il relativo prezzo e l’indicazione della quantità); tale operazione è gestibile nelle
form HTML solo attraverso l’uso di complicati script lato client o per mezzo di una
eventuale ridefinizione della struttura della form sul server. Tramite l’elemento
<repeat> è possibile specificare sia i controlli che saranno ripetuti, che la parte
dell’instance data destinata a contenere le informazioni raccolte, la quale verrà
replicata tante volte quante sono le ripetizioni del gruppo di controlli utilizzate
dall’utente. E’ anche possibile indicare le modalità di visualizzazione delle strutture di
ripetizione (se visualizzare tutte le righe della struttura di ripetizione oppure utilizzare
una barra di scorrimento per selezionare la/le riga/righe da mostrare).
Per quanto concerne l’uso degli script nella definizione di una form, XForms, così
come è possibile notare analizzandone le caratteristiche finora descritte, tende ad
identificare le situazioni in cui lo scripting è comunemente adoperato ed introdurre
una sintassi dichiarativa che permetta di effettuare le stesse operazioni. Gli script,
infatti,
in alcune situazioni risultano difficili da realizzare e spesso complessi da
mantenere col passare del tempo e con le modifiche apportate alle pagine web che li
contengono. In XForms vengono definite con sintassi dichiarativa delle azioni
(Actions) che possono essere compiute, in relazione al verificarsi di particolari
condizioni; tra gli elementi utilizzati per determinare le azioni, a titolo esplicativo
vengono menzionati i seguenti:
¾ <message> : utilizzato per mostrare all’utente un messaggio (corrisponde
alla funzione “alert()” tipica degli script);
¾ <setvalue> : adoperato per immettere un determinato valore in una
locazione dell’instance data individuata da un’espressione XPath;
¾ <setfocus> : seleziona un determinato controllo della form;
¾ <reset> : resetta la form riportandola nel proprio stato iniziale;
¾ <toggle> , <index>, <delete> : adoperati per gestire l’aggiunta,
l’ordinamento e la cancellazione delle righe di una struttura di ripetizione di
controlli.
Di solito tali azioni vengono effettuate in relazione al verificarsi di particolari eventi
riguardanti la form e quindi sono utili ad implementare con sintassi dichiarativa degli
event handler (gestori di eventi). Difatti, in ogni elemento che definisce un’azione, per
mezzo dell’attributo “event”, viene indicato l’evento che attiva tale azione ed
eventualmente l’ID dell’elemento della form dal quale il particolare tipo di evento
deve essere generato. Numerosi sono gli eventi definiti nelle specifiche XForms e
quindi gestibili dai processori XForms; tali eventi sono relativi, ad esempio, alla
selezione e deselezione (focus) di un determinato controllo (DOMFocusIn e
DOMFocusOut), alla segnalazione che la form è stata correttamente caricata ed è
pronta ad essere compilata (xforms-ready), al cambiamento di valore di un controllo
della form (xforms-value-changed), alla validità o invalidità di un determinato
controllo (xforms-valid e xforms-invalid). E’ possibile raccogliere assieme, all’interno
dell’elemento <action>, un numero arbitrario di elementi che definiscono delle azioni
da effettuare in relazione al verificarsi di un particolare evento, indicato una sola volta
per mezzo dell’attributo “event” dell’elemento <action> stesso.
Per ciò che riguarda l’invio dei dati raccolti per mezzo delle form è possibile
specificare, tramite l’elemento <submission>, inserito direttamente all’interno del
modello della form, sia l’URI a cui inviare i dati (attributo “action”) che il metodo di
invio (attributo “method”); tra i metodi comunemente adoperati per ciò che riguarda il
protocollo HTTP[18] vi sono PUT, POST, GET e DELETE. Per quanto concerne i
possibili formati di serializzazione dei dati da inviare, oltre a quelli tradizionali definiti
nelle specifiche delle form HTML 4.01 (application/x-www-form-urlencoded e
multipart/form-data), c’è la possibilità di usare la codifica “application/xml”; per questo
formato è possibile specificare per mezzo di ulteriori attributi dell’elemento
<submission> il tipo di codifica dei caratteri del documento XML (attributo
“encoding”), la possibilità di inserire degli spazi bianchi nel documento XML per
migliorarne la leggibilità (attributo “indent”), l’omissione della dichiarazione del file
XML trattato (attributo “omit-xml-declaration”), la presenza o meno di sezioni esterne da
includere nel documento XML prodotto (attributo “standalone”) e le modalità di
trattare le sezioni di testo da non interpretare come contenuto XML del documento
(CDATA section).
Per definire lo stile delle form possono essere usati dei fogli di stile CSS.
Esempio di uso di XForms
Analizziamo ora come viene definito con sintassi XForms un semplice modulo
elettronico assieme ai controlli necessari per acquisire i dati.
Cominciamo col determinare il modello XForms supponendo di voler ottenere
da un utente le seguenti informazioni: nome e cognome, data di nascita ed area
geografica di residenza (Italia o estero).
E’ necessario definire la struttura dell’instance data (documento XML) destinata
a contenere i dati reperiti attraverso la form da inviare al server; oltre a ciò è
necessario anche specificare, utilizzando elementi <bind>, i vincoli per la validità dei
dati ottenuti per mezzo della form. In particolare devono essere necessariamente
compilati tutti i campi (required) ed il tipo di dato da immettere quale data di nascita
deve essere effettivamente una data (ottengo ciò ponendo il valore dell’attributo
“type” dell’elemento <bind> pari a xs:date che è uno dei tipi di dato definiti nelle
specifiche XMLSchema).
<!-- Modello XForms -->
<xfm:model id=”dati-utente”
xmlns:xfm=http://www.w3.org/2002/xforms”
xmlns:xs=”http://www.w3.org/2001/XMLSchema”>
<xfm:submission
id=”submit1” action=”URL_destinazione_dati_raccolti”/>
<xfm:instance id=”inst1” xmlns=””>
<utente>
<nome-cognome></nome-cognome>
<data-nascita></data-nascita>
<residenza></residenza>
</utente>
</xfm:instance>
<xfm:bind nodeset=”/utente/nome-cognome”
required=”true()”/>
<xfm:bind nodeset=”/utente/data-nascita”
required=”true()”/>
<xfm:bind nodeset=”/utente/residenza”
required=”true()” type=”xs:date”/>
</xfm:model>
E’ ora possibile specificare i controlli necessari per l’immissione dei dati
dell’utente (tali controlli possono essere inclusi nella posizione che si ritiene più
adatta all’interno di un documento editato adoperando un qualsiasi linguaggio di
markup; ad esempio HTML, XHTML, SVG, etc.):
o Nome e cognome (utilizzo un generico controllo ‘input’):
<xfm:input ref=”/utente/nome-cognome”>
<xfm:label>Inserisci il tuo nome ed il tuo
cognome</xfm:label>
</xfm:input>
o Data di nascita:
<xfm:input ref=”/utente/data-nascita”>
<xfm:label>Inserisci la tua data di nascita</xfm:label>
<xfm:hint>Inserire una data</xfm:hint>
</xfm:input>
L’elemento <hint> è di solito visualizzato al passare del mouse sul controllo.
Poiché il tipo di dato da immettere è una data, è probabile che sul browser
web tale controllo venga rappresentato mostrando una casella di scelta che
apre un calendario interattivo da cui poter selezionare una data.
o Stato di residenza (utilizzo il controllo ‘select1’ che permette di effettuare una
scelta di una tra più possibilità):
<xfm:select1 ref=”/utente/residenza”>
<xfm:label>Inserisci l’area geografica di
residenza</xfm:label>
<xfm:item>
<xfm:label>Italia</xfm:label>
<xfm:value> Italia </xfm:value>
</xfm:item>
<xfm:item>
<xfm:label>Estero</xfm:label>
<xfm:value>Estero</xfm:value>
</xfm:item>
</xfm:select1>
o Bottone di invio della form (fa riferimento per mezzo dell’attributo “submission”
all’ID dell’elemento <submission> del modello della form, il quale determina le
modalità di spedizione della form):
<xfm:submit name="submit1" submission="submit1">
<xfm:label>Submit</xfm:label>
</xfm:submit>
Si noti come le varie sezioni appena descritte che concorrono alla definizione
della form, specifichino solamente la struttura logica della form stessa; le modalità di
visualizzazione del modulo elettronico (posizionamento e stile dei controlli) sono
definite in relazione al documento XML nel quale viene inserita la form, al particolare
linguaggio di markup usato, ad eventuali fogli di stile CSS associati, oltre che dal
processore XForms presente sulla piattaforma dell’utente che si occupa di gestire la
compilazione
della
form
renderizzando
opportunamente
i
controlli
che
la
compongono. Risultano quindi evidenti le possibilità di definire separatamente,
adoperando XForms, l’organizzazione logica e le modalità di visualizzazione delle
form ottenendo conseguentemente una notevole indipendenza dalla piattaforma
utente.
La seguente immagine mostra come avviene la renderizzazione della semplice
form appena definita; le parti che di cui si compone la form sono state
opportunamente inserite all’interno di un documento HTML, in particolare i controlli
all’interno del body e il modello della form (elemento <model>) all’interno dell’head (è
stato adoperato per la renderizzazione il browser XSmiles[65] che supporta
nativamente la tecnologia XForms):
Il documento XML prodotto per raccogliere i dati della form ed inviato al server
web avrà la seguente struttura (nel caso in cui si specifica tramite l’attributo “enctype”
quale metodo di codifica dei dati della form “application/xml”):
<?xml version=”1.0”?>
<utente>
<nome-cognome>Giulio Rossi</nome-cognome>
<data-nascita>12-12-1999</data-nascita>
<residenza>Roma</residenza>
</utente>
In conclusione, è possibile affermare che con XForms il W3C ha definito una
nuova tecnologia web per gestire in maniera efficiente e ricca di potenzialità
elaborative e di interattività le form sul web, garantendo anche la possibilità di
determinare le caratteristiche di un modulo elettronico in maniera indipendente dalla
piattaforma utente. Resta però la necessità di adoperare un programma apposito
presente lato client, il cosiddetto processore XForms, per poter utilizzare le form; tale
aspetto risulta essere un freno per la diffusione di questa tecnologia. Attualmente le
form XForms non sono infatti supportate nativamente dai web browser più diffusi.
Nell’agosto del 2004 la fondazione Mozilla ha annunciato l’avvio di un nuovo progetto
di implementazione della tecnologia XForms - versione 1.0, nell’omonimo web
browser, in collaborazione con Novell e IBM; attualmente si è nel pieno di tale lavoro
di implementazione e alcune delle funzionalità di XForms sono già in fase di testing.
Tale progetto potrebbe rappresentare una spinta decisiva verso una maggiore
diffusione della tecnologia XForms.
Web Forms 2.0: la proposta di standard del Web
Application Technology Working Group.
Recentemente si è costituito un organismo non ufficiale, il Web Hypertext Application
Technology Working Group – WHATWG[19], frutto della collaborazione tra produttori di
web browser ed altre parti interessate, col fine di sviluppare nuove tecnologie direttamente
connesse ad applicazioni web, ovvero applicazioni remote cui si può accedere tramite il
World Wide Web utilizzando un browser. A partire dai primi mesi del 2004, il WHATWG si
è impegnato nell’elaborare un “working draft”, documento bozza di specifiche, relativo al
progetto Web Forms 2.0.
Con tale documento, rilasciato nella prima versione stabile il 26/06/2004, il
WHATWG si propone di raccogliere tutte le esigenze espresse dagli autori web,
relative ai problemi e alle difficoltà incontrate nell’uso delle form HTML; tali esigenze
sono state individuate utilizzando mailing list e discussioni aperte sul web riguardanti
l’argomento.
Obiettivo di tale gruppo di lavoro è estendere le form HTML, così come sono
definite nelle specifiche HTML 4.01 del World Wide Web Consortium, al fine di
includere nuove caratteristiche per far fronte alle nuove esigenze manifestate in tale
ambito, mantenendo una possibile compatibilità con i browser che supportano solo
l’HTML.
Come si evince dal working draft, le nuove form, oltre ad essere retrocompatibili
con le vecchie form HTML, presentano maggiori possibilità di validazione lato client
del loro contenuto per mezzo di sintassi dichiarativa (estendendo, ad esempio, con
nuovi attributi gli elementi coinvolti nella loro definizione), nuovi campi di input per i
quali è possibile definire rigidamente il tipo dei dati che devono essere immessi
dall’utente, un modello per includere strutture di ripetizione col fine di determinare,
dichiarativamente, la gestione di sezioni che si ripetono più volte. In aggiunta, anche
l’interfaccia DOM[14] (Document Object Module)2 viene opportunamente estesa per
supportare le nuove funzionalità introdotte, definendo nuovi eventi per la validazione
e l’interdipendenza del contenuto dei controlli.
E’
contemplata
anche
la
possibilità
di
inviare
i
dati
di
una
form
immagazzinandoli in un documento XML e di prepopolare i campi delle form con
contenuti di documenti esterni di vario tipo (ad esempio documenti XML),
agganciandoli e analizzandoli tramite script.
In Web Forms 2.0 non è previsto l’uso di tecnologie web recenti, quali
XPath[12], XMLSchema[16], poichè queste non sono ancora ampiamente supportate
dai browser.
Nel seguito vengono analizzate in maggior dettaglio le aggiunte e le modifiche
che, in relazione a quanto indicato nel testo del working draft Web Forms 2.0,
devono essere apportate alle web form definite nelle specifiche HTML 4.01, per
estenderne le potenzialità e renderne più completo ed efficiente l’impiego nell’ambito
dello sviluppo di applicazioni web di vario tipo.
In ogni form gli elementi fondamentali sono i controlli. Nel documento Web Forms 2.0
vengono definiti nuovi tipi di dato primitivi per determinare, più o meno rigidamente, le
informazioni che devono essere richieste all’utente per mezzo dei vari controlli. In particolare,
sono stati introdotti, per ciò che riguarda l’elemento < input>, utile a richiedere all’utente
l’immissione di informazioni di vario genere, dei nuovi valori per l’attributo type. E’
possibile, grazie a queste estensioni delle form HTML, definire campi di input destinati a
contenere i seguenti tipi di dato:
date-time
datetimelocal
2
data nel formato “anno, mese, giorno, ora, minuto, secondo,
frazione di secondo”, riferita al meridiano di Greenwich (il fuso
orario - timezone - è impostato ad UTC - Universal Time);
è uguale al tipo di dato date-time, ma senza alcuna indicazione
relativa al fuso orario;
Per una descrizione del Document Object Module (DOM) si veda il capitolo “I linguaggi di scripting
lato client e il loro impiego nella gestione delle web form”
date
month
week
time
number
range
email
URI
data nel formato “giorno, mese, anno”;
data nel formato “anno, mese”;
data nel formato “anno, numero di settimana”;
indicazione di un determinato istante di tempo in una giornata,
nel formato “ore, minuti, secondi, frazioni di secondo”;
valore numerico sia intero che decimale; è possibile usare
anche la notazione esponenziale;
un tipo di dato derivato da number per il quale viene specificato
l’intervallo di variabilità e il passo con cui il valore numerico
viene incrementato, per mezzo rispettivamente degli attributi
“min“, “max” e “step”;
Indirizzo e-mail (nel formato indicato nella sezione 3.4.1 della
RCF 2822 che specifica gli standard per lo scambio di
messaggi di posta elettronica fra calcolatori);
Uniform Resource Identifier (così come è definito nell’RFC
2396 che ne specifica la struttura).
Tali nuovi tipi di input possono essere settati inizialmente ad un valore di default
specificato per mezzo dell’attributo “value”. E’ demandata ad ogni particolare user
agent la scelta del miglior tipo di renderizzazione da adottare per permettere
all’utente di inserire, in maniera semplice e intuitiva, i dati specifici richiesti; ad
esempio, è possibile che, per agevolare l’immissione di date, lo user agent utilizzi,
invece della tradizionale casella di testo, un calendario interattivo.
Oltre all’introduzione dei tipi di dato appena descritti, in Web Forms 2.0 sono
state estese le caratteristiche di numerosi controlli già esistenti nelle form HTML, col
fine di tenere in considerazione le necessità di interfacciamento e manipolazione dei
controlli da parte dei linguaggi di scripting, relativamente alla gestione delle form
stesse.
Viene contemplata la possibiltà che l’elemento <form> venga incluso nell’head
per dichiarare la presenza di una determinata form in un documento HTML: in tal
caso l’elemento deve necessariamente essere vuoto; i vari controlli della form
possono essere sparsi ovunque all’interno del body ed ognuno deve riferire la form a
cui appartiene nel caso ci siano più form presenti in uno stesso documento HTML.
Oltre ad alcuni attributi delle form HTML che sono stati definiti in maniera più
dettagliata (“readonly”, “name”, “maxlength” e “disabled”), anche in relazione ai nuovi
tipi di elemento introdotti, sono stati definiti in Web Forms 2.0 nuovi attributi; tra
questi vi sono:
pattern
title
determina un’espressione regolare in base alla quale validare il
contenuto di un controllo; è applicabile ai controlli textarea ed
input di tipo text, password, e-mail e URI;
è possibile specificarlo assieme all’attributo “pattern”; fornisce
una breve descrizione della struttura della pattern da
visualizzare, eventualmente, per aiutare l’utente a immettere i
required
form
autocomplete
autofocus
inputmode
dati nel formato richiesto;.
indica che il controllo deve necessariamente essere riempito
con i dati dell’utente prima di inviare la form. E’ applicabile a
tutti i controlli escluso image, button, fieldset, select e output;
può essere anche adoperato con i controlli aventi l’attributo
“readonly” settato;
tale attributo specifica, relativamente ad un controllo, la form a
cui appartiene, indicando l’ID dell’elemento <form> a cui si
riferisce e sovrascrivendo ogni dipendenza di tale elemento da
altri elementi <form>; è quindi possibile posizionare i controlli
della form ovunque nel body di un documento HTML, dopo
aver dichiarato eventualmente, nell’head, la form stessa;.
è possibile specificare i valori on e off per tale attributo; se
attivato, lo user agent memorizzerà i dati inseriti nel controllo a
cui si riferisce l’attributo e, alla successiva richiesta della stessa
pagina, il controllo sarà già compilato con i dati inseriti in
precedenza. E’ importante tenere in considerazione la
sicurezza delle informazioni immesse dall’utente e la privacy
nell’utilizzare tale attributo. I controlli che supportano
l’autocomplete sono i tipi text, password, date number, email ed
URI dell’elemento input, gli elementi select e textarea;
indica il controllo della form che deve essere visualizzato per
primo quando viene caricata la pagina web contenente la form.
Se più controlli presentano tale attributo, viene selezionato
l’ultimo indicato nel documento HTML contenente la form. E’
possibile aggiungere tale attributo a tutti i controlli esclusi quelli
nascosti (hidden) e gli elementi output;
è un attributo che fornisce allo user agent informazioni, sotto
forma di una lista di nomi separati da spazi, riguardanti l’input
che deve essere reperito attraverso uno specifico controllo (set
di caratteri da utilizzare, uso della lettera iniziale maiuscola,
simboli che possono essere inclusi nell’input, etc.).
In aggiunta ai nuovi attributi appena descritti, le specifiche Web Forms 2.0
introducono anche nuovi elementi e quindi definiscono nuovi controlli. Tra questi vi
sono:
datalist
output
tale elemento serve per fornire una lista di valori che lo user
agent può mostrare all’utente quando viene immesso il contenuto
di un determinato controllo, permettendo di scegliere
rapidamente uno tra i valori predefiniti presenti nella lista stessa
oppure di continuare l’inserimento di un valore arbitrario. Questa
possibilità è valida per i controlli input di tipo text, e-mail, URI,
date e number. L’attributo list deve essere incluso in tali elementi
per associarvi una datalist e indica l’ID dell’elemento datalist
all’interno del quale sono specificate le varie possibilità di scelta
per mezzo di elementi option;
tale elemento permette di visualizzare dei campi di output
all’interno di una form. E possibile definire un valore di default e
specificare, per mezzo dell’attributo for, una lista di ID di altri
elementi/controlli della form i quali, con il loro valore, influenzano
il contenuto dell’elemento output stesso. Ciò può fornire allo user
agent indicazioni utili per una corretta gestione della form.
Tra gli elementi delle form HTML, ai quali sono state aggiunte nuove caratteristiche,
vi sono:
textarea
file upload
form
submit
button
è stato aggiunto l’attributo wrap col fine di specificare la
formattazione del testo inserito relativamente, ad esempio, ai
capolinea da considerare;
è stato aggiunto l’attibuto accept che permette di specificare una
lista di tipi di file da accettare e gli attributi min e max che
indicano il numero minimo e massimo di file di cui è possibile
effettuare l’upload.
l’attributo action che indica l’URI a cui inviare la form non è più
obbligatorio e, se non specificato, è utilizzato l’URI del
documento corrente per l’invio della form. Per mezzo
dell’attributo replace, è possibile anche effettuare degli updates
incrementali della form, ovvero è possibile far sì che, una volta
inviata una form parzialmente compilata, i dati spediti in risposta
dal server siano utilizzati dal browser per riempire particolari
campi della form stessa che sarà reindirizzata in maniera tale da
poterli aggiornare in relazione all’evoluzione della compilazione.
Per permettere di inviare una form a più processi, utilizzando
differenti metodi di codifica del contenuto o di effettuare, in base
ai dati inseriti, degli update della struttura e del contenuto dei
controlli della form visualizzata; è possibile specificare i seguenti
attributi (relativi alle modalità di spedizione dei dati collezionati)
all’interno dell’elemento <input type=”submit”>: action, method,
enctype, replace e target. Tali attributi, se presenti, sovrascrivono
i valori specificati dagli stessi attributi dell’elemento form,
definendo le modalità di codifica dei dati, il metodo di spedizione
degli stessi, l’indirizzo al quale devono essere spedite le
informazioni raccolte, etc.
In Web Forms 2.0 è prevista, oltre a quanto è stato descritto, anche la
possibilità di gestire con facilità, adoperando una sintassi dichiarativa senza fare più
ricorso a complicati script lato client, le strutture di ripetizione. Nelle form, infatti, ci si
trova spesso a dover gestire informazioni che si ripetono più volte per ciò che
concerne la loro struttura. Si pensi, ad esempio, ad una lista di articoli da ordinare
della quale non si sa a priori la lunghezza e per la quale ogni articolo presenta
l’indicazione di più campi informativi, come il nome, il costo unitario, la quantità, etc.
Tali situazioni in Web Forms 2.0 si possono gestire anche adoperando solo strutture
dichiarative, senza dover necessariamente fare ricorso allo scripting. Viene introdotto
il concetto di template, ovvero di modello da replicare più volte per gestire le
esigenze di ripetizione della stessa struttura di controlli all’interno di una form. Per
tale motivo viene di solito scelto un particolare elemento, tra i vari che fanno parte
della sintassi dell’HTML o dell’XHTML, contenente la struttura di controlli da ripetere.
Tale
elemento
viene
caratterizzato
per
mezzo
dell’aggiunta
dell’attributo
template=“repeat” e di un particolare ID (si potrebbe scegliere la riga di una tabella,
ad esempio, quale elemento da ripetere più volte). Ogni volta che si aumenta il
numero di ripetizioni, si inserisce nella form una struttura di controlli analoga a quella
precedente.
E’ prevista la possibilità di differenziare ogni ripetizione di un template all’interno
di una form per poterla riferire in seguito, grazie all’assegnazione di un ID univoco.
Ogni volta che la struttura di ripetizione dei controlli si espande, al nuovo gruppo di
controlli viene assegnato un identificatore univoco che è possibile includere nell’ID di
ogni singolo controllo del gruppo stesso. In tale maniera si riesce ad assegnare
comunque e indipendentemente dal numero di volte che viene ripetuta una certa
struttura di controllo, un ID unico ad ogni controllo, rispettando quindi il vincolo di
unicità degli ID all’interno di un documento HTML e permettendo di poter facilmente
riferire le varie parti della struttura di ripetizione. La gestione di tali strutture è trattata
completamente dal browser senza ricorsi a script lato client o pesanti spedizioni della
form stessa al server per far sì che la si estenda opportunamente.
Per rendere più agevole l’aggiunta, l’eliminazione o l’organizzazione delle varie
righe di una struttura di ripetizione, in Web Forms 2.0 sono stati previsti quattro nuovi
tipi di controllo; questi possono essere inseriti all’interno di una form per mezzo degli
elementi <button> o <input> dei quali viene specificato, usando l’attributo “type”, il
comportamento. L’attributo type può assumere quattro valori:
- add : aggiungere una riga alla struttura di ripetizione;
- remove : rimuovere una riga dalla struttura di ripetizione;
- move-up: spostare di una posizione più sù la riga selezionata;
- move-down: spostare di una posizione più giù la riga selezionata.
Tali controlli sono visualizzati come dei bottoni; tramite l’attributo “value” è possibile
specificare il testo da associre ad ogni bottone. Questi possono essere inclusi, solamente per
ciò che riguardi remove, move-up e move-down, nella struttura di controlli che si ripete,
ovvero nel template oppure è possibile che siano inseriti all’interno del body del documento
HTML nella posizione che si ritiene opportuna. E’ infine possibile gestire ripetizioni annidate
e specificare il minimo e il massimo numero di ripetizioni del template che possono essere
effettuate nella form (attributi “repeat-min” e “repeat-max” dell’elemento che definisce il
template).
Con Web-Forms 2.0 vengono anche estesi gli eventi che possono essere scatenati
durante l’elaborazione di una form. In particolare l’evento “change” viene attivato non appena
un controllo è deselezionato ed ha cambiato valore e, nel caso di controlli implementati per
mezzo di elementi grafici interattivi dal browser (menù di pop-up con calendario per scegliere
una data). Tale evento è scatenato ogni volta che viene modificato il contenuto di un controllo
anche se questo non perde il focus3.
Contrariamente all’evento “change”, generato dal cambiamento del valore di un
controllo e dalla sua deselezione, per trattare dei casi in cui vi è la necessità di un feed-back
più veloce, viene introdotto l’evento “input” scatenato ogni volta che viene modificato il
valore di un controllo anche se questo non è stato ancora deselezioanto. Tale evento è
catturato, come l’evento “change”, solo dal controllo che viene modificato.
Molto spesso accade che i controlli delle form sono interdipendenti e di conseguenza in
Web Forms 2.0 viene introdotta la possibilità di specificare tramite degli script, per ogni
singolo controllo, i valori e gli attributi che dipendono da valori e attributi di altri controlli,
invece di indicare per ogni controllo quali cambiamenti devono essere apportati sugli altri
quando il controllo stesso viene modificato, come avviene in HTML. Per fare in modo che le
modifiche subite da un controllo vengano notificate anche agli altri controlli di una form, il
cui valore dipende da quello del controllo che è stato modificato, parallelamente agli eventi
“input” e “change” vengono generati anche gli eventi “form input” e “from change”.
Al cambiamento del valore di un controllo, parallelamente all’attivazione degli eventi
“change” e “input”, gli eventi “form change” e “from input” vengono propagati a tutti gli altri
controlli della form e infine al controllo stesso che è stato modificato. Solo i controlli di tipo
output non scatenano tali eventi, i quali vengono inviati verso tutti i controlli anche al
caricamento iniziale di una form.
3
Equivale a dire che il controllo non viene deselezionato.
In tale maniera è possibile definire, per ogni controllo, degli event handler i quali
effettuano i cambiamenti opportuni al controllo stesso, in relazione alle modifiche subite da
altri controlli correlati e notificate dagli eventi “form change” e “form input”; tali gestori di
eventi modificano opportunamente le caratteristiche del controllo a cui sono connessi se
l’evento che intercettano è stato scatenato da un controllo ad esso correlato.
Al momento della verifica della validità dei dati di una form i vari controlli successful4
vengono analizzati; in caso di mancata validazione l’evento “invalid” viene generato e inviato
a tutti i controlli. Tale nuovo evento, gestito da un opportuno event handler (”oninvalid”)
relativamente ad ogni controllo, può modificare i valori di altri controlli facendoli divenire
validi o inavalidi. Dopo la generazione dell’evento “invalid” verrà verificata la validità solo
dei controlli non ancora validati mentre, se un controllo già validato viene fatto divenire non
più valido a causa delle azioni dell’event handler, i dati contenuti verranno spediti lo stesso,
anche se scorretti. E’ quindi necessario porre la dovuta cautela nel gestire tale tipo di
situazioni.
Le specifiche Web Forms 2.0 modificano leggermente le azioni da compiere
anche relativamente all’invio dei dati contenuti in una form. Al momento dell’invio
delle informazioni raccolte tramite una form la prima operazione eseguita è il
controllo di validità dei dati inseriti; se tale controllo, correlato alla gestione degli
eventi “invalid”, va a buon fine vengono identificati, con particolare attenzione alle
strutture di ripetizione, tutti i controlli, sia successful che non, facenti parte della form.
Viene dunque costruito un form data set comprendente tutti i dati dei controlli
successful. Il form data set è formato da gruppi consecutivi di tre dati per ogni
controllo: nome, indice e valore del controllo. Tutti i controlli, ad eccezione del select
e del file upload, presentano un solo valore; se due controlli hanno lo stesso nome
vengono contrassegnati con diversi numeri di indice. I controlli file upload e select
possono avere più di un valore o anche nessun valore; con valori multipli si ripetono
il nome e l’indice del controllo tante volte quanti sono i valori immessi assegnando
ogni volta uno dei valori.
A tal punto la form viene codificata secondo quanto indicato dall’attributo
“enctype” e dall’attributo “method”. I tipi di codifiche possibili, definiti dai valori di
“enctype”, sono analizzati nel seguito.
La codifica “application/x-www-form-urlencoded”, simile a quella definita nelle
specifiche HTML, interpreta la form secondo il charset specificato per mezzo
dell’attributo “accept-charset” dell’elemento <form>. Nel form data set viene inserito
forzatamente l’attributo di nome “charset”, contenente quale valore il set di caratteri
4
Un controllo è detto successful quando è in uno stato tale da poter produrre delle informazioni da inviare come
dati della form.
utilizzato per codificare la form. Viene quindi creata una lista di coppie nome/valore;
ogni nome è connesso al proprio valore dal carattere “=” e ogni coppia è separata
dalla successiva dal carattere “?”. I caratteri di spaziatura sono rimpiazzati dal
simbolo “+” e i caratteri non alfanumerici dal simbolo “%”, seguito dalla codifica
ASCII, su due cifre esadecimali, del byte che rappresenta tale carattere.
Come già accennato, nelle specifiche Web Forms è possibile inviare, utilizzando
la codifica “application/x-www-form-xml”, i dati raccolti tramite una form, per mezzo di
un documento HTML appositamente strutturato. Tale documento include tutti i dati
immessi nella form e ha, quale root element, l’elemeneto <submission>. Per ogni
struttura di ripetizione viene inserito un elemento <repeat> con l’attributo “template”
uguale all’ID del template e con l’attributo “index” ad indicare il numero di indice del
blocco di ripetizione. Per ogni controllo valido e successful viene inserito un elemento
<field>, figlio dell’elemento <submission>, con il nome del controllo quale valore
dell’attributo “name” e l’indice del controllo quale valore dell’attributo “index”; tale
elemento contiene il valore del controllo che riferisce. Per ciò che riguarda l’upload
dei file viene inserito un elemento <field> il quale presenta, oltre agli attributi “name”
e “index”, anche gli attributi “filename” (avente come valore il nome del file) e “type”
(avente come valore il tipo MIME del file). Il contenuto dell’elemento field è in tal caso
il file stesso in codifica base64, libero da caratteri di spaziatura. Degli spazi bianchi
possono essere aggiunti per rendere più leggibile il file XML inviato, ma verranno
ignorati tutti durante la ricezione del file stesso.
Un terzo metodo di codifica dei dati è il “text/plain” simile al metodo
“application/x-www-urlencoded” ad eccezione del fatto che le coppie nome/valore
non sono separate dal carattere “?”, ma dal carattere di nuova riga (newline).
Infine, un quarto ed ultimo metodo di codifica dei dati di una form è il
“multipart/form-data” che è adatto per inviare grandi quantità di caratteri non ASCII o
dati binari (form che includono uno o più file). Tale metodo di codifica è definito nelle
specifiche HTML 4.01 e non viene modificato nel Web Form 2.0 working draft. Nel
caso di uso del protocollo HTTP per inviare i dati reperiti tramite una form, i tipi di
metodi5 che sono consentiti sono: GET, PUT, POST e DELETE; di default è usato il
metodo GET. A seconda delle situazioni e quindi del tipo di protocollo per il
trasferimento di dati utilizzato (mailto, file, data, ftp, etc.) è conveniente utilizzare
l’uno o l’altro di tali metodi.
Un’altra caratteristica interessante che viene aggiunta nelle specifiche Web
Forms 2.0 alle form HTML, consiste nel poter caricare i dati con cui riempire i campi
5
Tali metodi vengono specificati tramite l’attributo “method” dell’elemento form o dell’elemento che
rappresenta il bottone per l’invio della form stessa.
di una form da una sorgente esterna. Ciò è utile sia per prepopolare i campi di una
form con valori di default prelevati da un file, che per definire, caricandole da una
sorgente esterna, le opzioni di menù di vario tipo (elementi <select> e <datalist>). E’
possibile quindi caricare in una selection list delle opzioni da un documento XML
esterno strutturato nella seguente maniera: il root element deve essere un elemento
<select> con una lista di opzioni specificate al suo interno. Tali opzioni vengono
aggiunte a quelle già esistenti nella selection list o le rimpiazzano, in relazione alla
presenza dell’attributo type=“incremental” nell’elemento <select> del file XML da cui
si vogliono caricare le opzioni. Quanto detto vale anche per l’elemento <datalist>.
Entrambi gli elementi <select> e <datalist> devono indicare per mezzo del valore
dell’attributo “data” l’URI del file XML da cui caricare le opzioni che devono essere
mostrate; a tale file deve essere associato il MIME type “application/xml” essendo un
documento XML a tutti gli effetti.
Vi è la possibilità di prepopolare i campi di una form con dati ricavati da un
documento XML esterno. Per fare ciò si deve indicare come valore dell’attributo
“data” dell’elemento form, l’URI di un documento XML opportunamente strutturato. Il
root element di tale documento deve essere un elemento <formdata>. Se esso non
presenta l’attributo type=“incremental” la form deve essre resettata al suo stato
iniziale prima di essere prepopolata con i dati ricavati dal file XML in questione. Quali
figli dell’elemento <formdata> vi sono gli elementi <repeat> strutturati per riempire,
con valori iniziali definiti, delle strutture di ripetizione, oppure gli elementi <field> che
permettono di inizializzare con opportuni valori i vari controlli della form originale,
identificati per mezzo del nome e dell’indice.
Per supportare, anche a livello di script, tali modifiche ed aggiunte, definite per
le form HTML nel working draft Web Forms 2.0, è necessario estendere
opportunamente l’interfaccia DOM. Ciò è ottenuto per mezzo di opportune aggiunte
di metodi e di nuovi campi definiti per gestire le form. Ad esempio, a tutti gli oggetti
che definiscono i controllli di una form, è stato aggiunto l’attributo “successful” che
indica se il controllo in questione può produrre informazioni da poter inviare come
dati delle form; solo i controllli successful infatti contribuiscono a determinare i dati
della form che verranno spediti. Ai vari oggetti è stato aggiunto anche l’attributo
“valid” ad indicare con un determinato valore numerico se il controllo è o non è valido
e, se non lo è, la causa della mancata validità.
Sono definiti nuovi metodi ed oggetti per interfacciarsi facilmente ed interagire
per mezzo di script con le strutture di ripetizione.
Per concludere tale carrellata delle principali caratteristiche di Web Forms 2.0,
resta da mettere in evidenza come il WHATWG abbia intenzione di impegnarsi a
definire anche un linguaggio avanzato per lo styling dei controlli delle form. In attesa
di sviluppare tale linguaggio per una gestione più agevole dello stile delle form Web
Forms 2.0, è possibile utilizzare le pseudoclassi6 definite appositamente per
determinare l’aspetto e l’organizzazione dei vari controlli delle form, nel working draft
del World Wide Web Consortium, Cscading Style Sheet 3 User Interface. I controlli
Web Forms 2.0 riferiti da ogni pseudoclasse sono indicati nel testo del working draft
Web Forms 2.0.
Il progetto “Web Forms 2.0” è sostenuto prevalentemente dai produttori dei
browser Mozilla e Opera.
Tale sforzo è animato dal tentativo di proporre un open standard per le form
web che:
1) sia compatibile col passato ed in particolare con le form HTML, tuttora
le più diffuse sul web ed implementate nei browser (al fine di poter sfruttare
l’esperienza degli autori web maturata in tale campo);
2) possa essere supportato dalla maggioranza dei browser senza
l’aggiunta di plug-in (come invece accade per lo standard XForms per il quale è
necessaria la presenza sulla piattaforma dell’utente del processore XForms) e
possa velocemente diffondersi come uno standard di fatto per le applicazioni
web;
3) includa e documenti, standardizzandoli, i molteplici metodi usati
attualmente dagli autori web per fronteggiare le problematiche relative
all’utilizzo efficace delle form HTML.
Facciamo a questo punto alcune considerazioni sugli obiettivi del progetto di
Web Forms in relazione ad XFroms.
Web Forms 2.0 viene definito come un progetto sostanzialmente indipendente
da XForms e mira ad essere largamente supportato dai browser maggiormente
utilizzati, al contrario di XForms stesso che è ritenuto attualmente ancora poco
implementato nel web. Sostanzialmente si può affermare che Web Forms 2.0 ha
tenuto conto di alcune critiche ricevute da XForms, tra cui il mancato supporto diretto
dei browser e il maggior grado di complessità delle XForms stesse rispetto alle
6
Una pseudoclasse riferisce un gruppo di elementi caratterizzati dalla condivisione di alcune caratteristiche,
determinandone in maniera unitaria le caratteristiche dello stile.
vecchie form HTML. Per tali motivi Web Forms 2.0 si è sviluppato tenendo in
maggiore considerazione una certa continuità con le form HTML; l’impegno del
WHATWG, quindi, è solo quello di sostenere adeguatamente il superamento delle
vecchie form.
Nelle specifiche Web Form 2.0 è definito anche un metodo per trasformare
sistemi server basati su XForms in server che inviano form HTML e Web Forms 2.0.
Viene utilizzato un particolare processore detto XForms processor che è in
esecuzione sul server e svolge la conversione da XForms a form HTML e Web
Forms le quali vengono poi spedite attraverso la rete al client.
Ovviamente, alcune caratteristiche distintive di XForms non sono più
implementate in Web Forms 2.0: tra queste spicca la separazione della struttura
logica della form dalla presentazione o interfaccia utente della stessa; si perde così
la forte indipendenza dalla piattaforma che caratterizza invece XForms.
Attualmente il gruppo di lavoro del WHATWG che si occupa del progetto Web
Forms 2.0 è impegnato nel perfezionare, rilasciando nuove release, il working draft al
fine di poter arrivare ad una versione stabile delle specifiche che possa essere
standardizzata; sono state elaborate anche alcune demo riguardanti l’uso delle
nuove form e delle loro principali caratteristiche, gestite tramite script Perl sul server;
tali esempi sono utili a dare un’idea chiara, seppur basilare, delle potenzialità di tale
progetto. E’, in conclusione, rilevante evidenziare come, con la definizione delle Web
Forms, il WHATWG si sia impegnato in un importante processo di adeguamento
delle form HTML alle nuove esigenze di interattività manifestate da utenti e
programmatori web, tenendo in considerazione la continuità col passato e le
problematiche relative alla compatibilità con le diffuse form HTML. Tale progetto è
aperto, pubblico e può risultare un mezzo importante per contrastare la diffusione
futura sul web di tecnologie di comunicazione proprietarie, verso le quali differenti
industrie informatiche, tra cui la Microsoft, stanno prevedendo di dirigere la propria
utenza.
Le web form: soluzioni proprietarie
Con la grande crescita degli interessi economici che gravitano intorno alla
definizione di una soluzione tanto potente quanto ampiamente diffusa di sistemi per
la collezione e l'elaborazione tramite web di dati, spesso strettamente connessi a
processi di business, molte aziende collocate nel settore informatico hanno proposto
soluzioni proprietarie. Nel seguito vengono brevemente illustrate le tre più importanti
proposte di software e metodologie per la gestione dei moduli elettronici sul web
sviluppate dalla Microsoft, dalla Adobe e dalla Macromedia.
Microsoft
Le pagine Web Form e la tecnologia ASP.NET
La Microsoft[36] permette di gestire le richieste di dati in input da parte degli
utenti remoti delle applicazioni web sviluppate appoggiandosi alla tecnologia
ASP.NET[44], per mezzo delle pagine Web Form. ASP.NET è il framework di
programmazione della Microsoft, eseguito su server web “Microsoft Server”,
utilizzato per creare e gestire in modo dinamico le pagine web, adoperando, per la
loro definizione, sintassi HTML mischiata a sintassi ASP; quest’ultima viene
utilizzata per poter determinare dinamicamente, tramite elaborazioni eseguite sul
server, parti della pagina web, al momento della richiesta da parte del client.
ASP.NET si basa sul framework .NET sviluppato sempre dalla Microsoft;
quest'ultimo consiste in un insieme di tecnologie tra di loro strettamente integrate per
permettere e supportare adeguatamente la realizzazione di servizi di connettività tra
persone, sistemi informativi e dispositivi. Il framework .NET[42] supporta vari
linguaggi di programmazione tra cui Microsoft Visual Basic, Visual C# e JScript
.NET; di conseguenza gli sviluppatori di applicazioni web ASP.NET possono
scegliere di utilizzare per le proprie applicazioni, uno qualsiasi tra i differenti
linguaggi di programmazione consentiti.
Per mezzo delle pagine Web Form è possibile definire quindi l'interfaccia utente
e le caratteristiche di interattività delle applicazioni web ASP.NET. Tali pagine web
permettono di effettuare lato server la gestione delle form HTML di solito utilizzate
per definire l'interfaccia con i client. Esse sono una combinazione di sintassi HTML e
controlli per le form messi a disposizione dal framework ASP.NET. ASP.NET infatti
definisce una serie di oggetti detti form controls che possono essere inseriti nelle
pagine ASP per mezzo di sintassi dichiarativa assieme ai tradizionali tag HTML;
ognuno di questi oggetti determina un particolare campo di immissione dati che sarà
presente all'interno della pagina web inviata al client. Al momento della richiesta da
parte di un utente di una pagina Web Form, sul server verrà processata la pagina
ASP e saranno istanziati gli opportuni oggetti necessari a gestire l'input richiesto
all'utente. Ognuno di questi oggetti (form controls) genererà automaticamente la
propria rappresentazione in HTML e di conseguenza al browser verrà inviato una
pagina web contenente solamente sintassi HTML. Per gestire la maggior parte delle
operazioni che l'utente può effettuare su una form vengono utilizzate delle
elaborazioni lato server e di conseguenza l'intera form viene spedita al server il
quale effettua le opportune modifiche e la invia nuovamente al client, magari per
permettere di ultimarne la compilazione. Tutti i form controls ASP sono associabili a
degli script che vengono eseguiti lato server e di conseguenza non inclusi tra i dati
inviati al client assieme alla form HTML; essi possono essere definiti utilizzando un
qualsiasi linguaggio di programmazione supportato dal framework .NET. Per i form
controls è possibile definire, analogamente alla gestione degli eventi delle form
HTML, dei gestori di eventi i quali non sono niente altro che script server, che si
occupano di trattare opportuni eventi lato server. Quindi nel caso in cui il client
effettua delle azioni sulla form che scatenano uno degli eventi gestiti lato server e
definiti dal progettista della pagina Web Form, l'intera form viene spedita al server il
quale esegue l' event handler opportuno e ritorna la form adeguatamente modificata
al client per proseguire nella compilazione. I form controls che possono essere
inclusi nelle pagine ASP sono molto più vari e ricchi di quelli che sono messi a
disposizione dalle form HTML e capaci di essere inclusi nelle pagine web destinate
all'utente finale in maniera compatibile con il browser web dell'utente stesso. Spesso
per gestire opportunamente la corrispondenza dei form controls con i controlli delle
form HTML vengono affiancati a questi ultimi anche degli script da eseguire lato
client.
Con tale metodologia di programmazione lo sviluppatore web ha la possibilità
di programmare la gestione della form e più in generale delle pagine web come se
tutte le operazioni si svolgessero localmente sul server; sarà poi il framework ASP
.NET a permettere di sfruttare le funzionalità implementate, da siti remoti
adoperando un web browser.
Info Path
Un' altra novità introdotta abbastanza recentemente dalla Microsoft per la
raccolta e la gestione di dati in rete tramite form, è l'applicazione Info Path[43]
(inclusa in Office 2003 Professional) che offre soluzioni orientate soprattutto a reti
interne all'azienda per agevolare, ad esempio, la gestione del personale, degli
inventari e di attività analoghe. Info Path è integrato nel pacchetto Office e offre la
possibilità di scambiare informazioni attraverso documenti XML e raccolte grazie a
moduli elettronici; la definizione delle form e la loro connessione ai documenti XML
strutturati per contenere i dati reperiti dall'utente risultano essere molto semplici e
guidati da interfacce utente WYSIWYG7. Info Path permette oltretutto l'impiego
deIl'XMLSchema per una gestione ottimale dei documenti XML stessi.
Con Info Path la Microsoft ha immesso sul mercato un valido tool per la
gestione di contenuti di varia tipologia, basata sullo standard XML, in previsione
anche della vastissima diffusione dell'uso di questo formato per la definizione di
documenti elettronici e del grosso giro di interessi economici correlato. E' importante
infine notare come, con l'introduzione di Info Path, la Microsoft ha sostanzialmente
ignorato lo standard XForms, sviluppato dal WorId Wide Web Consortium proprio
per la gestione delle form elettroniche, che permette l'immissione dei dati e la loro
memorizzazione in documenti XML appositamente organizzati.
Adobe
Adobe Form Designer 6.0
Form Designer[57] è un tool sviluppato dalla Adobe[56], azienda leader
mondiale nel campo della gestione e dello scambio dei documenti elettronici, con
l’intento di creare dei moduli elettronici per la raccolta di dati da utenti remoti in
maniera semplice e ricca di possibilità, così da accelerare e semplificare
l’acquisizione e la circolazione di informazioni in rete. Un'interfaccia molto completa
permette di sviluppare le form definendone il layout e le funzionalità in maniera
intuitiva ed immediata e di connettere con facilità le applicazioni web che sono
7
Sta per What You See Is What What You Get; in tale contesto indica la possibilità di definire dei moduli
elettronici intervenendo drettamente sulla renderizzazione del modulo stesso così come apparirà all’utente finale
e strutturandola opportunamente; viene dunque sfruttata la possibilità di vedere visualizzati istantaneamente i
risultati delle modifiche effettuate.
deputate a trattare i dati raccolti. E' implementato il supporto dell'XML per la gestione
e lo scambio dei documenti elettronici, ad esempio con programmi separati, che si
occupano di trattare opportunamente le informazioni raccolte. Form Designer
supporta JavaScript e permette di modellare dinamicamente il contenuto delle form.
Gli utenti ovviamente non hanno bisogno di possedere Form Designer per compilare
le form in rete; a seconda del tipo di utilizzo previsto da chi ha creato il modulo,
l'utente potrà compilarlo o unicamente con il proprio web browser o adoperando
Adobe Acrobat Reader, software scaricabile liberamente da Internet. I dati reperiti
tramite le form possono essere scambiati nel noto formato Portable Document
Format (.pdf).
Macromedia
Macromedia Flash MX: le Form
Flash MX[60] è un tool di Macromedia[59] per lo sviluppo di contenuti dinamici
e interattivi per applicazioni web, caratterizzati da effetti grafici di grande impatto ed
estremamente vari. I possibili impieghi di Flash MX sono molteplici: possono essere
create animazioni, grafica avanzata, elementi interattivi di differenti tipologie, etc. E’
possibile distribuire tali contenuti in rete per arricchire le interfacce utente delle
applicazioni web, visualizzandoli e gestendoli opportunamente lato client per mezzo
di Flash Player, il software di renderizzazione di file prodotti adoperando Flah MX,
distribuito gratuitamente su Internet, disponibile per le più diffuse piattaforme e
ampiamente diffuso.
I contenuti web realizzati con Flash MX possono essere inseriti facilmente
all’interno delle pagine HTML e visualizzati appoggiandosi al Flash Player che in tal
caso funge da plug-in del web browser adoperato. E’ ovviamente anche possibile
visualizzare i file Flash MX separatamente rispetto all’accesso ad altri documenti
elettronici, utilizzando unicamente il Player.
Flash MX include anche un proprio linguaggio di scripting, ActionScript, per vari
aspetti molto simile a JavaSscript, utilizzato per supportare lo sviluppo di contenuti
interattivi.
Adoperando Flash MX, si possono definire in maniera semplice e immediata
dei moduli elettronici utilizzabili all’interno delle applicazioni web per la raccolta di
informazioni dagli utenti. Le funzionalità delle form create adoperando Flash sono
simili a quelle delle form HTML, ma gli sviluppatori che utilizzano tale tool della
Macromedia possono sfruttare le notevoli potenzialità grafiche e di gestione del
layout disponibili, ben più ricche di quelle messe a disposizione dall’HTML.
I controlli che possono essere inseriti nelle form Flash sono i seguent: button,
radio button, file field, hidden field, text field, checkbox, menù/list, image field e jump
menù. E’ possibile posizionare i vari controlli all’interno della form in maniera molto
immediata grazie al supporto di un’interfaccia grafica WYSIWYG. Ad ogni controllo,
durante la creazione di una form, viene associato un nome. Per mezzo di un
ActionScript, la cui esecuzione viene di solito associata ad un determinato evento
quale la pressione di un bottone della form, vengono infine definite le modalità di
spedizione dei dati collezionati attraverso il modulo elettronico. In tale maniera viene
determinato l’URL a cui inviare le informazioni raccolte tramite i controlli della form e
il metodo del protocollo HTTP da adoperare (GET o POST). Le codifiche possibili
per i dati spediti sono quelle definite nelle specifiche delle form HTML. All’interno
dello script è inoltre possibile assegnare dei nomi particolari a ogni dato acquisito
tramite il modulo elettronico per poi determinare così le coppie nome/valore da
inviare in rete. La form così creata verrà renderizzata all’utente dell’applicazione web
che la include, per mezzo del Flash Player; quest’ultimo si occuperà dell’invio dei
dati acquisiti al server. Quindi la gestione del modulo elettronico, spedito all’utene
tramite un file Flash, e l’invio dei dati, vengono svolti interamente sul client
appoggiandosi al Flah Player. E’ importante, per concludere, notare che le form
Flash offrono anche varie possibilità di validazione dei dati immessi dall’utente.
Apache Cocoon e il framework Cocoon Forms
Cocoon Forms[25] è un framework per la gestione dell’acquisizione di dati da un
utente di un’applicazione web tramite form; è stato ideato per fornire agli sviluppatori
di applicazioni web che si appoggiano sulla servlet Cocoon[22] la possibilità di
definire e controllare le modalità con cui gli utenti inviano dati in input all’applicazione
stessa. Cocoon è un framework per il supporto dello sviluppo di applicazioni web
moderno e innovativo, poiché basato fortemente sulla gestione dei dati per mezzo di
documenti elettronici nel formato XML, riconosciuto come la “lingua franca” del web,
attualmente in rapida diffusione. Per comprendere appieno le potenzialità del
framework Cocoon Forms è necessario possedere una buona conoscenza delle
caratteristiche principali di Cocoon e delle modalità di controllo dell’evoluzione delle
operazioni effettuate da un’applicazione web per mezzo del meccanismo del control
flow[24].
Apache Cocoon
Cocoon è una servlet che implementa un complesso framework per supportare
la definizione di applicazioni web; è stato sviluppato nell’ambito della fondazione per
la produzione di software open-source Apache.
Il concetto che sta alla base del framework Cocoon è lo sviluppo di applicazioni
web basate sull’integrazione di singole componenti ognuna delle quali esegue un
compito specifico. In tale maniera risulta essere facile effettuare elaborazioni tanto
complesse quanto estremamente diversificate, gestendole modularmente attraverso
una serie di semplici operazioni.
Cocoon si basa fortemente sull’XML, quindi tutti i dati che processa e tutti i file
di definizione delle proprie funzionalità e delle azioni che deve compiere sono dei
documenti XML.
Cocoon è stato sviluppato attorno alla nozione di pipeline[23] (letteralmente
conduttura). Ogni applicazione web sviluppata utilizzando Cocoon è sostanzialmente
composta da un certo numero di pipelines ognuna delle quali è riferita ad un URL e
corrisponde ad un determinato pattern.
All’interno di ogni pipeline viene definita una catena di elaborazioni da effettuare
ogni volta che la pipeline stessa viene invocata (ad esempio da un client effettuando
una richiesta indirizzata al particolare URL corrispondente). All’interno di ogni
pipeline è indicata una sequenza di componenti che all’attivazione della pipeline
stessa eseguono elaborazioni particolari in successione. Vi sono tre grandi categorie
di componenti disponibili in Cocoon ovvero i generator, i transformer ed i serializer.
Ogni pipeline è di solito composta dalla sequenza di un generator, uno o più
transformer ed un serializer.
Il generator è il componente Cocoon che avvia le elaborazioni effettuate da una
pipeline; sostanzialmente esso si interfaccia con una determinata risorsa (che può
essere ad esempio un file XML, un database, un file di testo o anche un filesystem) e
produce un documento XML seguendo un vocabolario ben determinato, contenente i
dati reperiti accedendo alla risorsa stessa. Esistono differenti tipi di generator
specifici a seconda delle informazioni che si vogliono ottenere e della particolare
risorsa con la quale si deve interagire.
I dati reperiti attraverso il generator vengono passati in input al componente di
Cocoon che segue immediatamente nella pipeline e che nella maggior parte dei casi
è un transformer (anche se nulla vieta che sia un serializer; si ricordi che i dati
scambiati dai componenti di Cocoon non sono altro che documenti XML).
I transformer sostanzialmente effettuano delle particolari elaborazioni sul
documento XML che ricevono in input producendo come risultato in output un nuovo
documento XML. Tale documento XML a sua volta costituirà l’input del componente
Cocoon che segue immediatamente all’interno della pipeline.
Esistono molti tipi di transformer a seconda delle elaborazioni che si devono
effettuare. Tra questi sono largamente usati i transformer XSLT che riferiscono uno
stylesheet XSLT per mezzo del quale vengono specificate le regole per trasformare il
documento XML ricevuto in input. Vi sono anche dei transformer che si interfacciano
con un database per effettuare delle query specificate opportunamente nel
documento XML di input includendo i risultati nell’output, o ancora altri transformer
che includono nell’output parti di documenti XML esterni.
Infine la terza classe di componenti di Cocoon è composta dai serializer. Come
indica il nome stesso, questi serializzano, ovvero trasformano in un flusso di dati
binari o in una successione di caratteri, il contenuto del documento XML che
ricevono in input al fine di poterlo spedire in rete al client che ne aveva effettuato la
richiesta. In relazione alle modalità di serializzazione dell’output esistono molti tipi di
serializer tra cui vi sono l’XML, l’HTML ed il text serializer.
Sono dunque evidenti le potenzialità che offre Cocoon attraverso l’uso delle
pipeline, permettendo, grazie anche all’elevato numero di componenti (generator,
transformer e serializer) implementati, di comporre sequenze di elaborazioni per
compiere operazioni anche molto complesse. Ogni componente Cocoon è
implementato attraverso una o più classi Java. E’ possibile utilizzare uno tra i vari
componenti predefiniti o, in relazione a particolari esigenze, implementarne di propri.
All’interno di Cocoon sono presenti differenti file XML di configurazione del
framework e di definizione delle applicazioni web e della struttura di siti web
sviluppati basandosi su tale servlet.
Tra tali file ha una notevole importanza la sitemap (file di nome sitemap.xmap).
Attraverso una o più sitemap vengono definiti i seguenti aspetti (utilizzando sempre
una sintassi dichiarativa XML, semplice ed abbastanza intuitiva):
•
I componenti di Cocoon tra cui i generator, i transformer ed i serializer
specificando per ognuno vari parametri tra cui il nome che lo identifica e la
classe Java che lo implementa (oltre a quelli già elencati, Cocoon offre altri
componenti per effettuare operazioni di vario tipo e complessità)
•
Le pipeline implementate in Cocoon. Ognuna di queste corrisponde ad un
determinato pattern ed è messa in moto in risposta ad una richiesta
indirizzata ad un certo URI locale da parte del client; tale URI è detto
virtualURI poiché ad esso non corrisponde uno specifico file sul server da
inviare quale risposta al client. Il virtualURI è utilizzato invece per selezionare
una specifica pipeline che tramite una sequenza di operazioni definite dalla
catena di componenti di cui è composta, effettua le azioni richieste dal client
e produce una adeguata risposta per il client stesso.
Per chiarire meglio quanto detto fino ad ora si esamini il seguente spezzone di
documento XML tratto dalla sitemap di Cocoon:
<map:pipeline>
...
<map:match pattern=”elenco-libri”>
<map:generate type=”xml” src=”libri.xnl”/>
<map:transform type=”xslt” src=”ricava_elenco.xsl”/>
<map:serializa type=”xml”/>
</map:match>
...
</map:pipeline>
Supponiamo che un utente (client) tramite il proprio browser web si colleghi in
rete al server “mioserver” sul quale è in esecuzione Cocoon, che ascolta le richieste
dei client sulla porta numero 8888 (porta di default).
L’utente effettua una richiesta al seguente URL per ottenere l’elenco dei libri
disponibili dal sito web di una biblioteca:
http://www.mioserver.it:8888/elenco-libri
Tale richiesta è indirizzata a Cocoon il quale estrapola dall’URL la parte relativa
al percorso locale (“elenco-libri”) e controlla se vi è qualche pipeline che gestisce tale
virtualURI. Nella sitemap viene individuata tra le pipeline presenti (identificate e
delimitate dall’elemento <map:match>) quella corrispondente al virtualURI specificato
nella richiesta del client. Ogni pipeline è associata ad un virtualURI (o ad un cero
gruppo di URI virtuali) per mezzo di quanto specificato dal valore dell’attributo
“pattern” dell’elemento <map:match>.
In tal caso si avviano le elaborazioni della pipeline definita dall’elemento
<map:match pattern=”elenco-libri”>…..</map:match>. Un generator di tipo XML
legge il file XML individuato dal percorso espresso quale valore dell’attributo “src”
dell’elemento <map:generate>. Tale file XML viene passato in ingresso ad un
trasformer che lo elabora ed effettua una trasformazione XSLT secondo le regole
definite dal foglio di stile ricava_elenco.xsl (valore dell’attributo “src” dell’elemento
<map:transform>). Tramite questo foglio di stile vengono estratti dal documento XML
(libri.xml) ricevuto dal generator in input e contenente informazioni dettagliate circa
tutti i libri disponibili, solamente i titoli dei libri. Questo ultimo documento XML
prodotto dalle azioni del transformer XSLT verrà passato in input al serializer che
formatterà le informazioni secondo il formato HTML in maniera da poterle spedire in
risposta la client; sul client le informazioni stesse potranno essere agevolmente
visualizzate tramite un browser web.
Tale esempio, anche se molto elementare, è utile ad intuire le grandi
potenzialità offerte da Cocoon nel supportare lo sviluppo di applicazioni web. Si pensi
alla possibilità di formare un complesso set di di pipeline che si interfacciano con
svariate risorse persenti sul server e non solo su richiesta del client. Grazie alla
flessibilità ed alla forte strutturazione logica che caratterizzano i documenti XML che
contengono le informazioni, tali pipeline oltretutto potrebbero permettere di interagire
con differenti piattaforme e di utilizzare per l’output il formato più adatto per l’utente
finale.
Cocoon: il control flow
Le elaborazioni che caratterizzano la maggior parte delle applicazioni web sono
contraddistinte dal ripetersi di richieste da parte del client alle quali corrispondono
particolari azioni effettuate dal server e dati spediti in risposta. Molte volte durante le
interazioni tra client e server è necessario che il server mantenga e possa dunque
controllare lo stato di avanzamento globale dell’applicazione, determinando così le
successive pagine da visualizzare ed i loro contenuti.
Per poter trattare tali situazioni in maniera semplice, Cocoon implementa il
concetto di control flow. In Cocoon è possibile definire per mezzo di funzioni
Javascript dei flowscript[24], ovvero delle righe di codice Javascript, grazie alle quali
si può controllare l’evoluzione di una connessione del client col server. All’interno di
tale connessione sarà possibile, in tale maniera, la gestione di elaborazioni
complesse che interessano la visualizzazione di più pagine o dati tra loro correlati e il
cui avanzamento deve essere controllato in base alle informazioni particolari che
l’utente invia.
Ciò si ottiene definendo un virtualURI che identifica nella sitemap una pipeline
per mezzo della quale si invoca un flowscript (attraverso un virtualURI viene invocata
quindi una particolare funzione Javascript utile a gestire l’avanzamento delle
operazioni da effettuare nell’ambito della specifica connessione con il server).
Ogni volta che è necessario spedire una pagina o altri dati in risposta al client e
magari attendere l’arrivo di ulteriori informazioni inviate dal client stesso, l’esecuzione
del codice della funzione Javascript si blocca invocando una particolare funzione, al
punto raggiunto e lo stato di avanzamento delle elaborazioni dello script viene
salvato in un oggetto detto ‘continuazione’. Al momento opportuno, quando si è
nuovamente nelle condizioni di riprendere l’esecuzione delle azioni definite all’interno
dello script, magari poiché il client ha inviato i dati attesi, sarà possibile proseguire
nelle elaborazioni esattamente dal punto in cui erano state sospese recuperando dal
particolare oggetto-continuazione i valori di variabili locali, della pila e del contatore di
programma precedentemente memorizzati al momento della sospensione del
flowscript.
Ogni oggetto-continuazione che si usa in Cocoon è salvato all’interno di una
tabella hash globale ed identificato tramite un numero il quale viene di solito inviato
all’utente assieme ad altri dati alla sospensione del flowscript; nel momento in cui
l’utente risponde, all’interno dell’URL virtuale che indirizza viene incluso tale numero
identificatore dell’oggetto-continuazione che verrà così recuperato per poter
proseguire nelle elaborazioni del flowscript precedentemente interrotte.
Grazie a ciò è possibile definire in maniera relativamente semplice, utilizzando
procedimenti simili a quelli caratteristici della programmazione procedurale,
l’evolversi di complicate interazioni tra client e server appoggiandosi anche agli
oggetti definiti nel Flowscript Object Model (FOM)[24] appositamente pensati per un
loro utilizzo all’interno dei flowscript. Inoltre è possibile usare anche le numerose
tipologie di oggetti disponibili e reperibili nelle API di Cocoon.
Tra gli oggetti di sistema definiti nel FOM vi è l’oggetto ‘cocoon’ che rappresenta
la sitemap correntemente utilizzata e permette di accedere alle seguenti proprietà:
request, response, session, context, log e parameters, ognuna delle quali mette a
disposizione ulteriori proprietà e funzioni. Nel seguito vengono analizzati alcuni
esempi di funzioni di uso comune messe a disposizione dal FOM:
ƒ
cocoon.sendPageAndWait(“URI”)
viene spedita al client la pagina indicata attraverso l’URI parametro della funzione ed
il flowscript viene sospeso finchè non si ha una risposta dal client stesso;
ƒ
cocoon.sendPage(“URI”)
viene spedita al client la pagina indicata attraverso l’URI (argomento della
funzione) e le elaborazioni del flowsript proseguono senza attese;
ƒ
cocoon,redirectTo(“URI”)
viene inviata al client una redirezione all’URI specificato quale argomento;
ƒ
cocoon.session.setAttribute(
stringa_nome
,
oggetto_valore)
cocoon.session.getAttribute( stringa_nome)
cocoon.session.removeAttribute( stringa_nome)
tali funzioni servono rispettivamente a settare un attributo di sessione con un
determinato nome ed un particolare valore, a richiedere il valore di un attributo
di sessione identificato per mezzo del proprio nome e a rimuovere un
determinato attributo di sessione.
Questi esempi rappresentano solo, a titolo dimostrativo, alcune delle grandi
possibilità che si hanno di gestire complesse applicazioni web tramite il meccanismo
del control flow, utilizzando oggetti e funzioni del FOM all’interno dei flowscript.
Il concetto di flowscript è di fondamentale importanza nel framework Cocoon
Forms per gestire le web form utilizzando Cocoon.
Per comprendere meglio come viene invocato un flowscript in Cocoon si
consideri il seguente esempio. Come prima operazione è necessario definire e
memorizzare in un file il flowscript (funzione Javascript); si supponga di salvare il
codice seguente nel file ‘control_flow.js’:
function flow_script_fun(){
...
var a = cocoon.session.getAttribute(“nome_attr_1”);
var b = cocoon.session.getAttribute(“nome_attr_2”);
...
if(a = b)
cocoon.sendPageAndWait(“pageURI”);
...
return;
};
Ora è necessario dichiarare il file contenente il flowscript all’interno della
sitemap così che Cocoon possa leggerlo ed invocare la funzione definita al suo
interno; ciò si ottiene inserendo le seguenti righe nel file ‘sitemap.xmap’:
<map:flow language=”javascript”>
<map:script src=”control_flow.js”/>
</map:flow>
Infine si dovrà definire una pipeline che, in seguito ad uno specifico URL
selezionato dall’utente, attiverà il control flow richiamerà la funzione che definisce il
flowsript (flow_script_fun); per ottenere tale risultato bisogna modificare con la
seguente aggiunta il file ‘sitemap.xmap’:
<map:match pattern=”virtualURI_control_flow”>
<map:call function=” flow_script_fun”/>
</map:match>
In tale maniera, quando il client invierà una richiesta al seguente URL, verrà attivato
il flowscript:
http://www.mioserver.it:8888/virtualURI_control_flow
Il framework Cocoon Forms
Cocoon Forms è un framework per la gestione della raccolta dei dati dell’utente
di un’applicazione web tramite form; si basa, nell’interfacciarsi con i client, sull’uso di
form
HTML
ampiamente
supportate
da
tutti
i
browser
web,
eseguendo
prevalentemente su server le elaborazioni e le operazioni di validazione relative ai
dati ottenuti.
E’ possibile associare alle form documenti XML (operazione detta binding) sia al
fine di inizializzare le form con contenuti di default estratti dai documenti XML stessi,
che per memorizzare i dati ottenuti dall’utente utilizzandoli magari in successive
elaborazioni.
Numerose sono le possibilità offerte per definire controlli sulla validazione dei
dati con sintassi dichiarativa (ovvero tramite elementi di markup) anche se è
comunque permesso poter specificare degli script per trattare casi specifici e
complessi.
Oltre a ciò viene anche definito un cospicuo numero di eventi di cui poter
specificare le modalità di gestione.
Tale soluzione presenta dunque numerose potenzialità per la gestione delle
form su web; essa è però specifica per il server web Cocoon ed è strettamente
connessa ad altre tecnologie sviluppate nell’ambito del progetto Cocoon, tra cui il
flusso di controllo (control flow) per la gestione dell’avanzamento delle elaborazioni
per l’esecuzione di una applicazione web o anche le trasformazioni XSLT e le
sequenze di azioni definite in Cocoon per mezzo delle pipeline.
Cocoon Forms: definizione delle form
Per creare e definire parte degli aspetti relativi alla gestione di una form in
Cocoon Forms devono essere sostanzialmente editati due documenti XML:
•
il form model
•
il form template
Il form model è un file che descrive la struttura logica delle form e non contiene
alcuna
informazione
di
presentazione
(ovvero
riguardante
le
modalità
di
visualizzazione). Tale documento è detto anche form definition file poiché serve a
determinare
l’organizzazione
del
contenuto
informativo
della
form;
esso
sostanzialmente dichiara un certo numero di widget ovvero di oggetti che
conterranno ciascuno dei dati della form o definiranno delle particolari azioni sulla
form stessa; tali widget sostanzialmente corrispondono ognuno ad un determinato
controllo di quella che sarà la form così come verrà visualizzata all’utente. Per ogni
widget specificato nel form definition file è possibile indicare sia i criteri di validazione
che le modalità di gestione degli eventi che può attivare. Per ogni widget può essere
oltretutto definita anche una stringa per identificarne il contenuto (label), del testo di
aiuto per supportarne la compilazione visualizzato nel momento in cui sarà mostrato
all’utente il controllo della form associato a tale widget (help) ed un messaggio per
l’utente da visualizzare nel caso in cui non vada a buon fine la validazione dei dati
trattati dal widget stesso (failmessage).
Nel seguito vengono elencati i vari tipi di widget disponibili in Cocoon Forms
destinati ciascuno a contenere una particolare tipologia di dati da richiedere
all’utente:
Nome del widget
Field widget
Multivalue field widget
Boolean field widget
Repeater widget
Output widget
Submit widget
Action widget
Repeater action widget
Row action widget
Upload widget
Caratteristiche
Usato per l’immissione di testo o liste di selezione a
scelta singola
Gestisce le liste di selezione a scelta multipla
Gestisce un singolo valore booleano
Utile per definire strutture di ripetizione in cui
vengono ripetuti uno o più volte uno o più altri
widget
Simile al field widget ma non editabile (readonly)
Definisce particolari regole da verificare o azioni da
compiere in conseguenza dell’invio da parte
dell’utente dei dati della form
Serve a scatenare una specifica azione lato server
riguardante la form
Serve ad aggiungere o eliminare righe da un
repeater widget
Utilizzato all’interno di un repeater widget, serve per
effettuare
una
delle
seguenti
operazioni
relativamente alla riga del repeater a cui
appartiene: aggiunta della riga, eliminazione della
riga, spostamento in alto o in basso della riga.
Utile per inviare al server un determinato file per
mezzo della form
Il form template serve per definire le modalità di presentazione della form. Esso
consiste in un documento XML elaborato utilizzando un qualsiasi linguaggio di
markup (in particolare si consideri il caso dell’uso di HTML) all’interno del quale sono
inseriti elementi di marcatura specifici di Cocoon Forms utili ad includere la form. Tali
elementi definiscono i controlli che deve contenere la form associati ciascuno ad uno
specifico widget definito nel form definition file e le stringhe (label) che specificano le
modalità di inserimento dei dati per ogni controllo, anche queste ricavabili dal form
definition file. In tale maniera risulta possibile organizzare a piacimento la
disposizione dei controlli nella pagina web utilizzando i noti elementi di markup
HTML. In particolare la form viene inserita nel documento HTML (il form template file)
destinato a contenerla per mezzo dell’elemento <form-template>.
All’interno di tale elemento vengono posti nell’ordine e con la formattazione
desiderata due tipi di nuovi elementi:
ƒ
<widget>
identifica la posizione ove inserire il controllo della form associato ad un
determinato widget;
ƒ <widget-label>
permette di inserire la stringa di descrizione del contenuto che deve essere
immesso dall’utente in un determinato controllo associato ad un particolare
widget.
Tutti gli elementi del form definition file sono definiti in un namespace al
seguente URI:
http://apache.org/cocoon/forms/1.0#definition
Tutti gli elementi del form template file sono definiti in un namespace al
seguente URI:
http://apache.org/cocoon/forms/1.0#template
Cocoon Forms: binding di un documento XML
Si è detto che è possibile con Cocoon Forms prepopolare con valori di default
ricavati da un documento XML i vari campi di una form così come si possono salvare
i dati ottenuti dall’utente tramite la form in un documento XML. Per ottenere tutto ciò
è necessario definire, tramite un ulteriore documento XML, detto form binding file, le
regole di corrispondenza fra i widget che compongono la form definiti nel form
definition file e le varie parti del documento XML di destinazione, ciascuna destinata
a contenere i dati ricavati dall’utente tramite un determinato widget.
Tali regole di corrispondenza sono definite sostanzialmente associando ad ogni
widget, identificato tramite il proprio id, una espressione XPath che identifica un nodo
del documento XML di destinazione prescelto per salvare i dati reperiti tramite il
controllo
associato
al
widget
stesso
(<value
id=”id_del_widget”
path=”espressione_XPath”>).
Tutti gli elementi del form binding file sono definiti in un namespace al seguente
URI:
http://apache.org/cocoon/forms/1.0#binding
Cocoon Forms: flowscript e pipeline per la gestione delle form
Per utilizzare il framework Cocoon Forms è necessario controllare l’evoluzione
delle operazioni relative ad una form tramite un flowscript.
In particolare un flowscript per la gestione di una form deve includere le funzioni
definite nel file Javascript “Forms.js”, tramite le quali il flowscript può interagire con il
framework Cocoon Forms. Tale file è reperibile tra le risorse disponibili di default in
Cocoon.
Per comprendere come è strutturato un flowscript per la gestione delle form si
veda il seguente esempio:
/* carico la classe form per gestire le form in Cocoon */
cocoon.load("resource://org/apache/cocoon/forms/flow/javascrip
t/Form.js");
function show_form(){
var form = new Form(“URL_form_definition_file”);
var document = loadDocument(“URL_XML_file”);
form.createBinding(“URL_form_binding_file”);
form.load(document);
form.showForm(“URL_pipeline_form”);
form.save(document);
saveDocument(document,“URL_salvataggio_XML_file”);
cocoon.sendPage(“URL_pipeline_pagina_finale”);
return;
}
Come prima operazione all’interno del flowscript definito per mezzo della funzione
Javascript show_form() viene creato un nuovo Java Form Object riferito per mezzo della
variable di nome “form”, passando al costruttore quale parametro l’URL al quale reperire il
form definition file, ovvero il file XML che descrive la struttura della form dichiarando i
widget di cui si compone e le loro caratteristiche. Tale oggetto è detto form instance ed è
creato sulla base di quanto è specificato nel form definition file correlato.
Successivamente viene istanziata una nuova variabile di nome “document” alla
quale è assegnato il valore di ritorno della funzione ‘loadDocument(“URL_XML_file”)’.
Tale funzione ha quale unico parametro un URL che individua un documento XML il
quale viene letto e caricato all’interno di un oggetto Java che ne mappa il contenuto,
rappresentandolo attraverso il DOM-tree. Tale oggetto è infine restituito come valore
di ritorno assegnandolo alla variabile “document”.
In seguito si effettua il binding invocando sul Form Object (di nome “form”) il
metodo ‘createBinding(“URL_form_binding_file”)’. Quale argomento viene specificato
l’URL ove reperire il documento XML (form binding file) contenente le regole di
binding tra i widget della form ed un documento XML esterno (in tal caso quello
caricato precedentemente nella variabile “document”).
Viene poi prepopolata la form con i dati eventualmente presenti nel documento
XML caricato nella variabile di nome “document”, rispettando le regole di binding
(metodo ‘load(document)’ del Form Object di nome “form”).
Il metodo ‘showForm(“URL_pipeline_form”)’ del Form Object invoca la pipeline
di Cocoon che si occupa di inviare al client la form esprimendone la struttura in un
linguaggio comprensibile al client stesso (di solito tale linguaggio è l’HTML affiancato
dall’uso di alcuni script). Tale funzione continuerà ad inviare nuovamente la form al
client, notificando eventuali errori di compilazione, ogni volta che il client invia a
Cocoon i dati richiesti tramite la form, finchè gli stessi dati non superano i controlli di
validazione definiti, verificati tutti lato server.
Una volta che l’utente ha compilato correttamente la form il metodo
‘save(document)’ del Form Object salva i dati reperiti tramite la form nell’oggetto
“document” che mappa un documento XML appositamente strutturato per contenerli,
rispettando le regole di binding.
Viene quindi salvato invocando la funzione
‘saveDocument(document,“URL_salvataggio_XML_file”)’ l’oggetto “document” (primo
argomento) nel file XML individuato dall’URL specificato (secondo argomento).
Infine tramite la funzione ‘cocoon.sendPage(“URL_pipeline_pagina_finale”)’,
metodo dell’oggetto “cocoon” facente parte del Flowscript Object Model, è inviata
una pagina di notifica al client ad indicare che la compilazione della form è avvenuta
con successo, cosa possibile attivando una specifica pipeline che la genera; dopo di
ciò il flowsript termina.
Si veda in conclusione come è strutturata la pipeline di Cocoon utilizzata per
inviare al client la form; i controlli e la struttura della form devono essere definiti
usando un linguaggio di markup comprensibile al client stesso. In particolare Cocoon
prevede a tale scopo di definire i moduli elettronici adoperando le form HTML
ampiamente supportate dai browser web.
Ecco una pipeline che effettua la sequenza di operazioni necessarie ad inviare
la form al client:
<map:match pattern=”URL_pipeline_form”>
<map:generate src=”form_template.xml”/>
<map:transform type=”forms”/>
<map:transform type=”xslt” src=”forms-simplestyling.xsl”/>
<map:serialize type=”html”/>
</map:match>
Supponiamo che nel flowscript che gestisce la form sia stata appena eseguita la
seguente riga di codice: form.showForm(“URL_pipeline_form”);.
Attraverso la pipelie “URL_pipeline_form” viene effettuata la seguente sequenza
di operazioni:
a) Viene letto tramite il generator il form template file (form_template.xml);
b) Il form template file è dato in ingresso al formTemplateTransformer il quale,
attingendo informazioni dal form definition file, espande gli elementi
<ft:widget> ed <ft:widget-label> del template sostituendo ai primi informazioni
aggiuntive circa il controllo della form che rappresentano e ai secondi la
stringa che descrive il controllo reperibile sempre dal form definition file (label);
c) Tale documento XML viene poi passato ad un transformer XSLT che
rappresenta ogni widget, sulla base delle informazioni disponibili, secondo il
markup HTML ed inserisce vari script per controllare ed agevolare
l’immissione dei dati lato client (anche se i controlli di validazione della form e
la gestione degli eventi riguardanti la form stessa avvengono sempre lato
server);
d) Il serializer HTML in fine serializza tale documento HTML contenente la form
che sarà supportato e quindi rappresentabile su tutti i browser web.
La seguente immagine può essere utile a chiarire meglio la sequenza di
operazioni appena descritte.
Per concludere, dopo che la form è stata compilata dal client, i dati vengono
inviati al server che procederà con le operazioni di validazione; se la validazione va a
buon fine si riprende l’esecuzione del flowscript, interrotta per permetter all’utente di
compilare la form.
Esempio di uso di Cocoon Forms
Attraverso il seguente semplice esempio di un modulo elettronico gestito
adoperando Cocoon Forms è possibile chiarire meglio il funzionamento di tale
framework che permette una gestione delle web form in Cocoon caratterizzata da
buone potenzialità di interazione con gli utenti del web stesso, grazie anche alla
possibilità di richiedere loro l’invio di dati di varia tipologia.
Si analizzi una semplice web form che richiede all’utente di immettere il proprio
nome ed il proprio cognome salvandoli all’interno di un documento XML sul sever.
Il form definition file che definisce la tipologia di tutti i controlli che concorrono a
determinare la struttura della form, è il seguente:
<!-- file : definition.xml-->
<?xml version="1.0"?>
<fd:form
xmlns:fd="http://apache.org/cocoon/forms/1.0#definition">
<!—Elemento fd:widgets : contiene al suo interno tutti I
widget (controlli) che costituiscono la form con le
informazioni ad essi correlate -->
<fd:widgets>
<!-- field widget : nome e cognome -->
<fd:field id="nome" required="true">
<fd:label>NOME :</fd:label>
<fd:hint>Attenzione - nome(hint)!</fd:hint>
<fd:help>Attenzione - nome(help)!</fd:help>
<!—Definisco il tipo di dato che dovrà
contenere
tale widget -->
<fd:datatype base="string"/>
</fd:field>
<fd:field id="cognome" required="true">
<fd:label>COGNOME :</fd:label>
<fd:hint>Attenzione - cognome(hint)!</fd:hint>
<fd:help>Attenzione - cognome(help)!</fd:help>
<fd:datatype base="string"/>
</fd:field>
</fd:widgets>
</fd:form>
Il form template file è un file HTML all’interno del quale sono inclusi i vari
controlli della form; grazie al markup HTML vengono opportunamente posizionati
all’interno della pagina web i controlli stessi. Il form template file è il seguente:
<!-- file : template.xml-->
<html xmlns:ft="http://apache.org/cocoon/forms/1.0#template">
<head>
<title> Registrazione : nome e cognome salvati in un
documento
XML </title>
</head>
<body>
<p>Registrazione dell'utente - dati salvati in un
documento XML </p>
<!-- L'attributo action indica il nome della pipeine
da
invocare per spedire i dati della form.
In tale caso con tale nome e' passato
l'identificatore dell'oggetto continuazione al
fine
di riprendere la esecuzione del flowscript con
i
dati ottenuti dal riempimento della form motivo
per
il quale il flowscript era stato interrotto-->
<ft:form-template
action="#{$continuation/id}.continue" method="post">
<p>
<!-- nome -->
<ft:widget-label id="nome"/>
<ft:widget id="nome"/>
<p>
<!-- cognome -->
<ft:widget-label id="cognome"/>
<ft:widget id="cognome"/>
<input type="submit"/>
</ft:form-template>
</body>
</html>
Il form binding file determina come i dati acquisiti tramite i vari controlli della
form devono essere immagazzinati in un documento XML appositamente strutturato
per contenerli. La struttura di tale documento XML è la seguente:
<!-- file : datif.xml-->
<?xml version="1.0" encoding="UTF-8"?>
<utente>
<nome>Inserisci nome</nome>
<cognome>Inserisci cognome</cognome>
</utente>
Il form binding file ha la seguente organizzazione:
<!-- file : binding.xml-->
<?xml version="1.0"?>
<!-- File in cui definisco le regole di binding secondo
sintassi
CForms utilizzato nel flowscript nella funzione
createBinding(); -->
<fb:context
xmlns:fb="http://apache.org/cocoon/forms/1.0#binding"
path="/">
<fb:value id="nome" path="//nome"/>
<fb:value id="cognome" path="//cognome"/>
</fb:context>
Per gestire la compilazione della form è necessario il seguente flowscript
Cocoon che non è altro che un file javascript (tale flowscript utilizza il modello di
gestione della form descritto in precedenza) :
<!-- file : flowscript.js-->
/* carico la classe form per gestire le form in Cocoon */
cocoon.load("resource://org/apache/cocoon/forms/flow/javascrip
t/Form.js");
function regxml(){
/* Creo la variabile form sulla base di quanto
specificato
nel form model */
var form = new Form("definition.xml");
/* Salvo il documento XML di cui specifico l'uri come
parametro della funzione loadDocument in un oggetto
in maniera tale da poterne visitare il DOM tree*/
var doc = loadDocument("datif.xml");
/*Associo alla form un documento XML nel quale sono
definite
le regole di binding secondo la sintassi CForms
(nome documento bind.xml)*/
form.createBinding("Bbind.xml");
/* Carico il contenuto del documento nella form */
form.load(doc);
/* Funzione showForm : l'argomento e' la pipeline che si
occupa di caricare la form inviandola al client */
/* tale funzione continua a mostrare la form all'utente
finche' non e' valido tutto il suo contenuto */
form.showForm("registrazionexml");
/* Salvo il contenuto della form nell'oggetto doc */
form.save(doc);
/* Salvo il contenuto dell'oggetto doc nel documento XML
datif.xml La funzione makeTargetURI prende come
argomento
la stringa della path del documento XML con cui si e'
prepopolata la form e ritorna lo stesso nome di file
con
l'aggiunta della stringa "-result" per non
sovrascrivere
l'originale
esempio : name.xml ---> name-result.xml*/
saveDocument(doc,makeTargetURI("datif.xml"));
/* Invio una pagina al client invocando la pipeline
passata
come argomento alla funzione sendPage */
cocoon.sendPage("fineregxml”);
}
Infine per poter gestire correttamente tale form bisogna aggiungere alla sitemap
di Cocoon le seguenti sezioni:
•
Inclusione del flowscript (file “flowscript.js”):
<map:flow language="javascript">
<map:script src="flowscript.js"/>
</map:flow>
• Inclusione delle pipeline adatte a gestire opportunamente la form:
<!-- pipeline che invoca il flowscript flowscript.js -->
<map:match pattern="regxml">
<map:call function="regxml"/>
</map:match>
<!-- pipeline da invocare per richiedere una registrazione
(invocata nel flowscript flowscript.js) -->
<map:match pattern="registrazionexml">
<!-- genero il documento xml contenente il form template
-->
<map:generate src="template.xml"/>
<!-- uso il trasformatore seguente :
Template Trensformer : sostituisce nel temlpate ad
ogni
oggetto di tipo ft:widget o ft:widget-label la
corrispondente rappresentazione XML
-->
<map:transform type="forms"/>
<!-- invoco il trasformatore XSLT che permette di
effettuere
l'output dei controlli della form in HTML
(il foglio di stile che definisce tale
trasformazione è
riconfigurabile a piacere) -->
<map:transform src="forms-samples-styling.xsl"/>
<!—serializzo il contenuto come documento HTML per poi
inviarlo al client -->
<map:serialize type=”html”/>
</map:match>
<!-- pipeline da invocare se la registrazione e' andata a
buon
fine (invocata nel flowscript flowscript.js) -->
<map:match pattern="fineregxml">
<!-- Uso il generatore XML per leggere il documento
“notifica_avvenuta_registrazione” sul server ed
inviarlo
al client tramite il serializzatore -->
<map:generate type="xml"
src="notifica_avvenuta_registrazione.xml"/>
<map:serialize type=”html”/>
</map:match>
<!—Pipeline per la gestione degli oggetti continuazione -->
<map:match pattern="*.continue">
<map:call continuation="{1}"/>
</map:match>
Supponiamo che tale modulo elettronico sia presente sul server web di nome
“www.nomeserver.it” sul quale è in esecuzione la servlet Cocoon che ascolta le
richieste dei client sulla porta numero 8888 (di default).
Se un utente remoto effettua per mezzo del proprio browser web una richiesta
all’URI virtuale “http://www.nomeserver.it:8888/regxml”, Cocoon invoca la pipeline
che gestisce tale virtual-URI, individuata dal particolare elemento <match> della
sitemap, avente l’attributo “pattern” uguale a “regxml”. Tale pipeline a sua volta avvia
l’esecuzione della funzione “regxml()” (flowscript Cocoon)
definita nel file
“flowscript.js”. Tale flowscript gestisce l’inizializzazione della form prepopolandone i
controlli con i dati prelevati dal documento XML “datif.xml”, connesso alla struttura
della form per mezzo delle regole di binding determinate dal form binding file
“binding.xml”. La form viene quindi inviata all’utente in seguito all’invocazione della
funzione “form.showForm("registrazionexml")”, facente parte del flowscript, di cui
viene sospesa l’esecuzione. Tale funzione adopera la pipeline “registrazionexml” per
leggere il template (form template file) “template.xml” e modificare opportunamente i
controlli della form interni al template stesso per mezzo di un’opportuna
trasformazione XSLT definita dal foglio di stile “forms-samples-styling.xsl”; grazie a
tale trasformazione i controlli della form vengono espressi con sintassi dichiarativa
HTML affiancata da alcuni script javascript ed in seguito il documento HTML viene
serializzato ed inviato al client che ne aveva fatto richiesta. Dopo che l’utente ha
terminato di compilare la form per mezzo del proprio browser web i dati immessi
vengono ricevuti sul server, validati e, in caso di successo della validazione,
memorizzati nel file “datif-result.xml”; tale procedimento è gestito per mezzo delle
funzioni form.save(doc) e saveDocument(doc,makeTargetURI("datif.xml")), invocate
all’interno del flowscript di cui viene ripresa l’esecuzione, precedentemente sospesa
pochè la form era stata inviata all’utente per la compilazione. Il flowscript termina
invocando la pipeline “fineregxml” tramite la quale viene inviato all’utente il
documento
HTML
“notifica_avvenuta_registrazione.xml”
quale
conferma
del
successo della registrazione dei dati inviati tramite il modulo elettronico.
In conclusione, è importante notare come il framework Cocoon Forms
rappresenti uno strumento di gestione delle form per applicazioni web sviluppate
appoggiandosi alla servlet Cocoon, molto potente e versatile; esso infatti permette di
definire, per mezzo del form definition file, la struttura e l’organizzazione di un
modulo elettronico, in maniera indipendente dal particolare linguaggio di markup
XML usato per specificare al client le caratteristiche della form stessa (il più delle
volte l’HTML). Grazie ad un foglio di stile che determina una particolare
trasformazione XSLT è infatti possibile, immediatamente prima dell’invio della form al
client, modificare il markup connesso alla form in maniera tale da renderlo
comprensibile al client stesso. Definendo differenti fogli di stile si possono inviare i
dati riguardanti la visualizzazione della form adoperando diversi linguaggi di markup
XML, a seconda delle caratteristiche della piattaforma del client dal quale proviene la
richiesta. Si ha quindi, gestendo il dialogo con i client per mezzo delle form HTML, il
vantaggio della compatibilità con la quasi totalità dei browser. Vi è anche la
possibilità sia di caricare che di memorizzare i dati della form in un documento XML
per mezzo di regole di connessione dei controlli della form con i vari elementi del
documento XML, definite nel form binding file. Adoperare Cocoon Forms per gestire
un modulo elettronico risulta però essere anche abbastanza laborioso e complesso;
difatti per ogni form devono essere editati per lo meno quattro file: il form definition
file, il form template file, il form binding file ed il file javascript contenente il flowscript
che gestisce le fasi di compilazione della form. Inoltre è necessario aggiungere alla
sitemap le pipeline da impiegare nelle varie elaborazioni che interessano la form
stessa. I controlli sui dati immessi dall’utente e l’aggiornamento dinamico del valore
dei controlli in base alla compilazione di determinati campi della form avvengono tutti
lato server quindi per portare a completamento la compilazione di un modulo
elettronico si ha la necessità di inviarlo più volte al server il quale ne controlla la
validità e, in caso di errori, lo spedisce nuovamente al client richiedendone,
eventualmente, per mezzo di messaggi appositi, la correzione. Tali operazioni
appesantiscono il carico di elaborazioni del server ed il traffico circolante sulla rete.
Linguaggi XML per la definizione dell’interfaccia utente
delle applicazioni
Ogni volta che si sviluppa un’applicazione, sia essa desktop o destinata al web,
che esplica parte delle proprie funzionalità interagendo con un utente umano, una
delle principali problematiche con cui ci si deve confrontare è la realizzazione di
un’ottimale interazione con l’utilizzatore per permettergli di sfruttare a pieno ed in
maniera il più possibile semplice ed intuitiva le caratteristiche e le potenzialità
dell’applicazione stessa. L’interfaccia di una siffatta applicazione per computer è
quella componente chiave che si occupa di gestire l’interazione utente-elaboratore
sfruttando, in ultima analisi, le caratteristiche dei dispositivi di input ed output
dell’elaboratore stesso (in particolare monitor, mouse e tastiera, ma sempre più
spesso anche di altoparlanti, joystick, etc.).
Da varie decine di anni, parallelamente allo studio dell’interazione uomocomputer, sono stati sviluppati e si sono diffusi numerosi linguaggi di definizione
delle interfacce utente sia in ambiente accademico che commerciale: tali linguaggi
vengono comunemente denominati User Interface Definition Language - UIDL.
Negli ultimi anni in particolare si è avuta una forte proliferazione di proposte e
progetti di nuovi UIDL. Tale problematica è divenuta sempre più rilevante anche e
soprattutto in relazione alla presenza di numerose piattaforme sulle quali poter
eseguire una determinata applicazione ed alla correlata necessità di permettere una
elevata portabilità del software sfruttando la possibilità di definire l’interfaccia utente
in maniera generale e valida in ogni ambiente di esecuzione. In aggiunta a tale
esigenza, un’interfaccia utente deve poter gestire in maniera ottimale l’interazione
con l’utente fornendo i mezzi per agevolare il più possibile l’uso delle funzioni
dell’applicazione connessa con modalità semplici ed intuitive. Infine il programmatore
deve avere la possibilità di riuscire a definire in modo chiaro e coinciso le
caratteristiche dell’interfaccia stessa: modalità di connessione con l’applicazione,
layout, design, etc.
A partire dalla fine degli anni ’90, con la standardizzazione dell’Extensible
Markup Language (XML) da parte del World Wide Web Consortium, si è sviluppata
una nuova famiglia di UIDL XML-based. Forti dell’astrazione agevolata dall’uso di
documenti XML per determinare le caratteristiche dell’interfaccia, tali linguaggi
mirano ad essere platform-indipendent, appoggiandosi il più delle volte a dei supporti
software (plug-in o ambienti di esecuzione più complessi) per la renderizzazione
finale su un particolare sistema.
In gran parte degli UIDL XML-based oltretutto viene applicato, agevolato proprio
dall’uso dell’XML, il principio di separazione delle modalità di visualizzazione dalla
struttura logica delle varie parti che compongono l’interfaccia, permettendo così di
poter controllare meglio e modificare con facilità le modalità di visualizzazione
stesse, personalizzabili magari dall’utente finale in relazione al proprio sistema di
elaborazione. Tale metodologia inoltre rende possibile ai programmatori, in fase di
sviluppo, di concentrarsi sulle funzionalità dell’applicazione e sulla logica
dell’interfaccia, delegando opportunamente la gestione della grafica e del layout agli
esperti di design.
La possibilità di usare linguaggi XML-based al posto di linguaggi procedurali per
definire l’interfaccia utente di una applicazione, semplifica molto i compiti degli
sviluppatori; infatti la sintassi dichiarativa si presta bene a tale scopo per la maggiore
sinteticità rispetto a quella procedurale, per la migliore manutenibilità e chiarezza e
per l’organizzazione gerarchica dei documenti XML facilmente correlabile alle
gerarchie degli elementi e dei controlli che compongono l’interfaccia utente.
Tali UIDL sono spesso integrati in piattaforme più elaborate per lo sviluppo di
applicazioni le quali quindi si appoggiano ad una sintassi procedurale per definire le
funzionalità, la logica dell’applicazione stessa e ad una sintassi dichiarativa per
sviluppare l’interfaccia utente. Questo sembra essere il nuovo paradigma di
programmazione
del
futuro
che
condensa
in
sé
le
caratteristiche
della
programmazione desktop e web. Infatti gran parte dei linguaggi di programmazione
di applicazioni desktop attualmente utilizzano esclusivamente il codice procedurale
(funzioni, oggetti, classi, librerie), mentre, nell’ambito della programmazione web, è
adoperata molto diffusamente la sintassi dichiarativa (HTML, XML ed altri linguaggi
XML-based) affiancata spesso da linguaggi di scripting poco potenti, limitati nelle
possibilità. Il modello di sviluppo di software verso cui ci si dirige prende il meglio da
entrambi i paradigmi di programmazione sfruttando la potenza del codice
procedurale nel descrivere la logica dei programmi e la versatilità della sintassi
dichiarativa nel definire la user interface.
Da quanto affermato è possibile notare come tale nuova metodologia di
programmazione riduca molto le distanze tra le applicazioni desktop e quelle web,
dando la possibilità di definire applicazioni di rete che interagiscono con l’utente
utilizzando interfacce create per mezzo dei nuovi UIDL XML-based, adeguatamente
supportati da appositi ambienti di esecuzione presenti sulla piattaforma dell’utente
stesso (lato client).
Attualmente la maggior parte delle applicazioni web, per gestire l’interazione
client-server, si basa su linguaggi dichiarativi quali HTML, XHTML ed altri per lo più
standardizzati dal W3C con la finalità di permettere lo scambio di dati con l’utente
attraverso la rete e supportati più o meno largamente dai browser. Tali linguaggi
determinano le modalità di visualizzazione e raccolta delle informazioni immesse
dall’utente di un’applicazione web, con poche possibilità di elaborazioni lato client
(limitate a quelle che sono le potenzialità di Javascript).
D’altro canto oggi ci si sta sempre più orientando verso i nuovi linguaggi di
programmazione descritti in precedenza per la definizione di applicazioni di rete.
Ognuna di queste applicazioni web è caratterizzata da un pacchetto autoinstallante,
scaricabile in rete, magari da un server e comprendente i vari file di definizione
dell’interfaccia utente (UIDL) affiancati da codice di tipo procedurale che si occupa di
gestire le elaborazioni per quanto possibile lato client e di condurre e comunicare la
comunicazione in rete col server.
In tale maniera gli scambi di informazioni in rete tra client e server sono
differenti rispetto ale tradizionali applicazioni web HTML-based e spesso molto più
snelli. Oltretutto grazie all’uso di un apposito UIDL per la definizione dell’interfaccia
utente, l’interazione con l’utente stesso risulta essere molto più ricca di potenzialità,
flessibile ed adattabile alle differenti esigenze che possono manifestarsi se
paragonato alle possibilità offerte dalle form tradizionali usate sul web. Infatti in tale
maniera le applicazioni web sono dotate di una vera e propria interfaccia grafica fino
ad ora destinata prevalentemente ad applicazioni desktop.
Oltretutto questo tipo di applicazioni permettono di effettuare buona parte delle
elaborazioni lato client, alleggerendo il carico del server; difatti potendo gestire
l’interfaccia grafica sul client è possibile utilizzare del codice scritto adoperando un
vero e proprio linguaggio di programmazione procedurale ovviamente molto più
potente e performante degli script Javascript, che attualmente spesso vengono
affiancati alle pagine HTML.
E’ però necessaria sulla piattaforma del client la presenza di un opportuno
ambiente che supporti l’esecuzione di tali pacchetti-applicazioni di rete, fornendo
librerie e funzionalità comuni a tutte quelle di una determinata tipologia. Poter
installare l’ambiente di esecuzione di queste applicazioni in maniera compatibile con
differenti piattaforme ne aumenta la portabilità.
In tale contesto diviene di fondamentale importanza il problema della gestione
della sicurezza e quindi di un accesso controllato alle risorse del sistema di
elaborazione del client da parte di queste applicazioni di rete. Trattandosi infatti di
veri e propri programmi eseguiti lato client che vengono scaricati dalla rete e che
spesso comunicano in rete, è fondamentale garantire la protezione del sistema ad
esempio da eventuali accessi indesiderati al file system o ad altre risorse private.
In conseguenza di quanto detto, è possibile prevedere in futuro una progressiva
migrazione del web dall’uso degli attuali browser, che sono strumenti tuttora basilari
per lo scambio di dati sul web stesso e per l’interazione con gli utenti e la raccolta dei
dati da questi inviati tramite le form, all’impiego di nuove metodologie di
programmazione di rete molto più evolute e complesse. In tale maniera per reperire
le informazioni di input dell’utente non si utilizzano più le funzionalità delle form
tradizionali, ma sofisticate e potenti interfacce grafiche supportate da ambienti di
esecuzione appositi e librerie di classi presenti sul lato client. Quindi in futuro
l’interazione utente-PC, relativamente alle applicazioni web e non solo, sarà definita
tramite il vocabolario XML dell’UIDL prescelto. E’ possibile quindi che le tradizionali
web form fino ad ora descritte e, più in generale, i linguaggi dichiarativi attualmente
impiegati per lo scambio di dati strutturati sul web, tra i quali il più diffuso è
sicuramente l’HTML, vengano affiancati se non progressivamente soppiantati da
interfacce grafiche per applicazioni di rete ben più complesse definite per mezzo dei
nuovi UIDL e gestite tramite codice procedurale in linguaggi di programmazione
specifici.
Attualmente sono varie e diversificate le proposte di nuovi UIDL e di ambienti
per lo sviluppo di software applicativo che supportano tali linguaggi; tale campo è in
continua evoluzione e suscita forte interesse sia dal punto di vista dello sviluppo di
nuove tecnologie, che in relazione alla centralità assunta dal web nella gestione di
processi commerciali e più in generale economici spesso anche di grande
importanza.
Tra i molti UIDL attualmente in via di sviluppo e di perfezionamento due
proposte significative sono le seguenti:
•
L’EXtensible
sviluppato
User-interface
nell’ambito
della
Language
(XUL[28],
produzione
di
si
pronuncia
software
open
“zul”),
source
dell’organizzazione Mozilla[26];
•
L’EXtensible Application Markup Language (XAML[39], si pronuncia
“zammel”), sviluppato dalla Microsoft per gestire le interfacce grafiche con
sintassi dichiarativa nell’ambito della programmazione di applicazioni per il
nuovo sistema operativo Windows Longhorn, di cui è prevista l’introduzione
sul mercato tra il 2006 ed il 2007.
Nel seguito vengono analizzati tali UIDL con i necessari riferimenti alle
caratteristiche degli ambienti di sviluppo software che li supportano.
Mozilla: EXtensible User-interface Language
L’EXtensible User-interface Language è un linguaggio dichiarativo XML-based,
basato su standard pubblici (open standard), utilizzato per la definizione
dell’interfaccia
utente
delle
applicazioni
sia
web
che
desktop,
sviluppate
agganciandosi al framework Mozilla XPToolkit[30]. Tale framework consiste in una
collezione di pacchetti i quali, grazie all’integrazione delle funzionalità offerte,
formano una Application Programmer Interface indipendente dalla piattaforma di
esecuzione; utilizzando tale API, è possibile supportare lo sviluppo di applicazioni
complesse sfruttando un ambiente che fornisce la possibilità di una facile
implementazione dell’interfaccia utente dell’applicazione stessa o delle funzionalità di
comunicazione di rete (nel caso in cui tale applicazione è distribuita su più computer
connessi in rete che interagiscono tra di loro tramite opportuni scambi di pacchetti
dati). Nei casi più complessi tali applicazioni si basano su programmi scritti
adoperando linguaggi di programmazione, come ad esempio il C/C++, i quali
sfruttano la possibilità di essere agganciati e supportati dall’XPToolkit di Mozilla ad
esempio per ciò che riguarda l’interazione con l’utente tramite un’interfaccia definita
utilizzando XUL o l’uso delle molteplici funzioni di utilità messe a disposizione dalle
librerie XPCOM[31] (Cross Platform Component Object Model); tali funzioni sono
basilari nello sviluppo di software che si appoggia a tale piattaforma ed espandibili
dal programmatore.
I componenti fondamentali dell’XPToolkit sono i seguenti:
ƒ
XUL, linguaggio XML-based di definizione dell’interfaccia utente;
ƒ
Gecko[32], motore per il renderig e l’editing di contenuti web. Supporta la
gestione di interfacce utente definite utilizzando XUL, ma è anche compatibile
con i più recenti e diffusi standard di Internet quali HTML, CSS, DOM, etc. E’
open source e facilmente integrabile su vari piattaforme, in molteplici ambienti
di sviluppo. Si occupa della renderizzazione dei contenuti delle applicazioni
per mostrarli all’utente fornendo un ambiente per l’esecuzione degli script
Javascript associati all’interfaccia utente;
ƒ
Necko[33], libreria che fornisce funzionalità di alto livello per il supporto della
comunicazione di rete, estensibile e comprendente il supporto ai protocolli di
comunicazione più diffusi.
Ogni applicazione web sviluppata utilizzando XUL e l’XPToolkit, si compone
fondamentalmente di tre parti:
1. file XUL che definiscono la struttura dell’interfaccia utente nelle varie sezioni
della applicazione;
2. file Javascript che determinano il comportamento e le funzionalità dei controlli
che compongono l’interfaccia, con la possibilità di agganciare programmi scritti
appositamente dallo sviluppatore (C/C++) o le librerie di utilità XPCOM
dell’XPToolkit;
3. file CSS (Cascading Styile Sheet), adoperati per definire le modalità di
visualizzazione dell’interfaccia utente tramite fogli di stile.
L’unione di queste componenti costituisce un pacchetto, un’applicazione che si
appoggia all’XPToolkit di Mozilla. I file di ogni pacchetto sono raccolti assieme in un
unico archivio (.jar) seguendo una opportuna organizzazione di directory interna.
E’ possibile quindi scaricare un pacchetto dal web, magari connettendosi ad un
server, ed eseguirlo sul proprio sistema avendo già scaricato l’XPToolkit. Lo stesso
browser Mozilla è infatti un pacchetto sviluppato appoggiandosi alla piattaforma
Mozilla composto da file XUL, CSS e Javascript. Oltretutto l’XPToolkit è il risultato di
un progetto di produzione di software open source e standard based, disponibile per
le più diffuse piattaforme assicurando così un’elevata portabilità delle applicazioni
sviluppate.
La separazione della struttura logica dell’interfaccia utente definita utilizzando
XUL, dalle modalità di visualizzazione specificate per mezzo dei fogli di stile (CSS),
permette di sviluppare separatamente tali due aspetti di un’applicazione, oltre che di
modificare e personalizzare semplicemente l’aspetto dell’interfaccia stessa.
E’ anche possibile ridefinire con facilità, in relazione ad esempio a particolari
condizioni, alcune caratteristiche dell’applicazione come ad esempio i testi
visualizzati in relazione alla lingua.
Per ciò che riguarda le applicazioni web i pacchetti possono essere scaricati in
rete ed eseguiti localmente con privilegi definiti dall’utente a seconda dei casi
relativamente all’accesso e all’uso delle risorse locali (accesso al file system,
modifica di file, etc.).
Rispetto alle tradizionali applicazioni web definite utilizzando l’HTML e le
tecnologie ad esso connesse, appoggiandosi all’XPToolkit si ottiene quindi una
notevole crescita delle potenzialità dell’interfaccia utente che viene definita tramite
XUL e la possibilità di accedere nelle elaborazioni lato client a risorse locali quali
librerie condivise, file system, etc.
Vengono ora analizzate più in dettaglio le caratteristiche di XUL. Il vocabolario
XML di tale linguaggio è organizzato appositamente per permettere una semplice
quanto potente definizione delle interfacce utente delle applicazioni che sono state
sviluppate utilizzando la piattaforma Mozilla. L’elemento <window> è la radice di un
file XUL e comprende in sé tutti gli altri elementi dell’interfaccia. Come nelle
tradizionali form web è possibile inserire a proprio piacimento bottoni, campi di input,
etichette, liste a scelta multipla e singola, immagini; tutti questi sono controllli di base
per interagire con l’utente. In aggiunta è previsto l’uso di barre (progress meter) che
mostrano il progresso di particolari applicazioni e di indicatori di scorrimento
(scrollbar). E’ possibile creare facilmente dei menù anche annidati o ancora, menù a
comparsa visualizzabili ciccando col mouse su particolari zone dell’interfaccia. E’
contemplata la possibilità di creare anche delle barre di comandi (toolbar) che
implementano funzionalità comuni a tutte le pagine che compngono l’interfaccia nel
suo complesso. E’ oltretutto prevista, nel caso in cui i controlli sono numerosi
relativamente a quanto può essere mostrato in una pagina dell’interfaccia, la
possibilità di visualizzarli a gruppi su differenti livelli di sovrapposizione, scegliendo
tramite opportuni comandi di volta in volta quali mostrare in primo piano (tabbox).
Si può determinare il layout delle pagine raggruppando i controlli (Box Model) e
definendo una serie di box per ciascuno dei quali è possibile specificare la
disposizione e le dimensioni degli elementi contenuti. Si possono quindi organizzare
interfacce che si adattano alla dimensione dell’area dello schermo disponibile per la
visualizzazione, arrangiando al meglio la renderizzazione dei vari controlli.
E’ possibile definire delle strutture tabulari per avere potenzialità ancora
maggiori nella disposizione degli elementi di una pagina.
Si possono adoperare, nello strutturare le interfacce, delle finestre in cui
mostrare il contenuto HTML di una pagina web, reperito magari attraverso la rete
(iframe).
E’ prevista anche la possibilità di leggere sorgenti di dati esterne e mapparle su
opportuni grafi ad albero (tree) per accedere gerarchicamente a tali informazioni
visualizzandole aggiornate all’interno dell’interfaccia utente.
Si possono scorrere agevolmente strutture di ripetizione di controlli, ad esempio,
quando lo stesso schema si ripete più volte, contenendo ogni volta dati differenti, ed
è contemplata l’opportunità di salvare lo stato dell’interfaccia così come settato
dall’utente per ripristinarlo al successivo avvio dell’applicazione.
Oltre alle caratteristiche appena descritte, proprie della struttura dell’interfaccia
utente, e’ possibile associare ai vari elementi dell’interfaccia stessa degli script per la
gestione degli eventi da essi generati; gli eventi gestibili sono quelli che si ritrovano
anche nelle specifiche delle form HTML oltre ad alcuni aggiuntivi.
E’ possibile abilitare o disabilitare in relazione a delle condizioni uno o più
controlli.
Tramite gli script Javascript si può accedere direttamente agli oggetti della
Cross Platform Component Object Model (XPCOM), ovvero al set di oggetti messo a
disposizione delle applicazioni sviluppate utilizzando l’XPToolkit di Mozilla e dei
metodi e delle proprietà ad essi correlati: le modalità di integrazione degli oggetti
XPCOM negli script Javascript sono riferite con la sigla XPConnect.
Ad ogni file XUL è possibile associare uno o più fogli di stile (CSS) in maniera
simile alle pagine HTML.
A XUL si affianca un ulteriore linguaggio XML detto EXtensible Binding
Language (XBL[34]) usato per modificare il comportamento degli elementi da inserire
in una generica interfaccia o definirne di nuovi, estendendo così a piacere ed in
relazione alle esigenza della particolare applicazione le potenzialità di XUL.
Infine XUL presenta l’utile meccanismo degli overlay che consiste nella
definizione di file tramite i quali è possibile definire nuove caratteristiche per le
interfacce o modificare e riutilizzare quelle già presenti senza agire direttamente sulla
loro definizione originale, ma indicando i cambiamenti da fare in un file esterno; ciò
permette di apportare modifiche e personalizzazioni in maniera non definitiva e di
ripristinare facilmente e velocemente la situazione originaria delle interfacce.
Con XUL e l’XPToolkit di Mozilla cambia la tradizionale organizzazione delle
applicazioni web ed alle comuni pagine HTML contenenti eventualmente la web form
per reperire l’input dell’utente, si sostituisce una più completa e performante
interfaccia grafica, ricca di numerose nuove possibilità per una maggiore interattività,
gestita prevalentemente lato client tramite script ed appoggiandosi a librerie presenti
localmente.
Per chiarire meglio quanto descritto si faccia riferimento al seguente esempio di
definizione della struttura di un’interfaccia grafica tramite un file XUL.
Esempio di organizzazione di un file XUL
Analizziamo il seguente esempio, opportunamente commentato, di un file XUL.
<?xml version="1.0"?>
<!-- Eventuale riferimento ad uno o piu' stylesheet utilizzati per definire le modalita' di
visualizzazione dell' interfaccia
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?> -->
<!-- Elemento window: root di ogni file XUL -->
<window
id="esempio-xul"
title="Esempio di strutura dell'interfaccia utente XUL"
orient="horizontal"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<script>
<!—- Definisco alcune funzioni Javascript utilizzate nell’interfaccia
- resetta():mostra una finestra di pop up con la scritta : "Bottone conferma
premuto!!!";
- option():notifica con un messaggio in una finestra di pop up quali opzioni
dei pannelli A e B sono state selezionate
- direzione():notifica con un messaggio in una finestra di pop up il
pulsante di direzione premuto sulla barra di comando (Avanti/Indietro) -->
function resetta(){
alert("Bottone conferma premuto!!!");
}
function option(){
var a=document.getElementById("pa");
var b=document.getElementById("pb");
if(a.checked){
if(b.checked)
alert("Le opzioni del pannello A e del pannello B sono state
selezionate!!!");
else
alert("L'opzione del pannello A e' stata selezionata!!!");
}
else {
if(b.checked) {alert("L'opzione del pannello B e' stata
selezionata!!!");}
else {alert("Nessuna opzione e' stata selezionata!!!");}
}}
function direzione(a){
alert("La direzione scelta e' " + a);}
</script>
<!-- Vbox: raggruppo i controlli da visualizzare verticalmente uno di seguito all'altro -->
<vbox>
<toolbox>
<!-- Menubar: aggiunta di un menù a tendina -->
<menubar id="barra-menu-a-tendina">
<menu id="A-menu" label="Menu 1">
<menupopup id="popup-1">
<menuitem label="Scelta 1"/>
<menuitem label="Scelta
<menuseparator/>
<menuitem label="Scelta
<menuitem label="Scelta
</menupopup>
</menu>
<menu id="B-menu" label="Menu 2">
<menupopup id="popup-1">
<menuitem label="Azione
<menuitem label="Azione
</menupopup>
</menu>
</menubar>
2"/>
3"/>
W"/>
a"/>
b"/>
<!-- Toolbar: aggiunta di una barra di comandi -->
<toolbar id="barra-statica">
<toolbarbutton id="avanti" label="Avanti"
onclick="direzione('avanti');"/>
<toolbarbutton id="indietro" label="Indietro"
onclick="direzione('indietro');"/>
</toolbar>
</toolbox>
<hbox>
<!-- Groupbox: raggruppo in un riquadro gli elementi della interfaccia
contenuti -->
<groupbox>
<caption>
<description>dati persopnali</description>
</caption>
<vbox>
<!-- Description: elemento per aggiungere del testo -->
<description>
Inserire i propri dati personali
</description>
<!-- Spacer: elemento di spaziatura -->
<spacer flex="2"/>
<!-- Hbox: raggruppo i controlli da visualizzare orizzontalmente uno di
seguito all'altro -->
<hbox>
<!-- Textbox: immissione di testo -->
<label value="Nome e cognome:" control="nome"/>
<textbox id="nome" flex="1"/>
</hbox>
<spacer flex="1"/>
<!-- Listbox: lista a scelta multipla con opzioni tutte visibili -->
<label value="Stato di residenza:" control="stato"/>
<listbox id="stato">
<listitem label="Italia"/>
<listitem label="Francia"/>
<listitem label="Spagna"/>
<listitem label="Germania"/>
</listbox>
<spacer flex="1"/>
<hbox>
<!-- Menulist: menu' a tendina -->
<label value="Sesso:" control="sesso"/>
<menulist id="sesso" flex="1">
<menupopup>
<menuitem label="Maschio"/>
<menuitem label="Femmina"/>
</menupopup>
</menulist>
</hbox>
<groupbox>
<!-- Radio: bottone scelta singola -->
<radiogroup>
<caption>
<description>Impiego</description>
</caption>
<hbox>
<radio id="stuente" value="stu" label="Studente"/>
<radio id="dipendente" value="dip" label="Dipendente"/>
</hbox>
</radiogroup>
</groupbox>
<spacer flex="1"/>
<!-- Button: bottone con immagine e testo associati -->
<button label="Conferma" image="happy.png" flex="1"
onclick="resetta();"/>
</vbox>
</groupbox>
<groupbox>
<caption>
<description>Opzioni</description>
</caption>
<!-- Tabbox: pannelli multipli sovrapposti dell'interfaccia utente -->
<tabbox>
<tabs>
<tab label="Pannello A"/>
<tab label="Pannello B"/>
</tabs>
<tabpanels>
<tabpanel id="pannello-a">
<checkbox id="pa" label="Attiva l'opzione A"/>
</tabpanel>
<tabpanel id="pannello-b">
<checkbox id="pb" label="Attiva l'opzione B"/>
</tabpanel>
</tabpanels>
</tabbox>
<spacer flex="1"/>
<button id="pc" label="Verifica opzioni selezionate"
onclick="option();"/>
</groupbox>
</hbox>
</vbox>
</window>
Ecco come tale file XUL (.xul) viene renderizzato dal Mozilla XPToolkit.
Analizzando la sintassi dichiarativa del file XUL è possibile individuare
facilmente i vari controlli che compongono l’interfaccia. Sono sfruttate, in tale
esempio, alcune basilari possibilità di strutturare l’interfaccia utente, offerte da XUL
come l’inserimento di menù a tendina, barre di controllo pannelli sovrapponibili ed il
raggruppamento di vari controlli per una definizione più agevole del layout tramite i
box (elementi <hbox> e <vbox> del Box Model ed elemento <groupbox>). Sono
anche presenti dei semplici script inclusi direttamente all’interno del file XUL
(elemento <script>).
Tale file potrà essere aperto attraverso il browser Mozzilla o come applicazione
stand-alone invocando, dalla linea di comando della shell del sistema operativo ove è
installato il Mozilla XPToolkit, il file eseguibile “mozilla” e passando come argomento
il nome del file XUL stesso.
Microsoft: EXtensible Application Markup Language
L’EXtensible Application Markup Language[39] è un linguaggio XML-based per
la definizione di interfacce utente avanzate tramite sintassi dichiarativa, sviluppato
dalla Microsoft per fornire ai programmatori Windows la possibilità di gestire
l’interazione delle applicazioni con l’utente per mezzo di interfacce potenti e definibili
in maniera semplice e relativamente sintetica.
XAML sarà utilizzato per lo sviluppo di applicazioni sia web che desktop a
partire
dalla
futura
versione
del
sistema
operativo
Windows,
denominata
Longhorn[37] che lo supporterà pienamente.
E’ possibile prevedere una forte diffusione dell’uso di XAML essendo questo lo
strumento principale per la definizione dell’interazione tramite interfaccia grafica tra
PC ed utente nella prossima generazione di applicazioni Windows; tale sistema
operativo è infatti attualmente largamente impiegato.
Le nuove applicazioni Windows si baseranno su di un nuovo paradigma di
programmazione che mira a rendere lo sviluppo delle applicazioni stesse più
semplice. Infatti verranno utilizzati linguaggi procedurali (C#, Visual Basic, etc.) per
definire le funzionalità effettive delle applicazioni ed una sintassi dichiarativa per
organizzare la user interface.
In tale maniera sarà possibile strutturare delle interfacce complesse e complete,
simili a quelle utilizzate nelle applicazioni desktop, anche per il software destinato al
web. Ovviamente tali programmi non saranno portabili poiché eseguibili solo sotto
Windows; difatti si prevede che tale nuovo paradigma di programmazione venga
progressivamente inserito nella piattaforma .NET per lo sviluppo di software per
Windows.
Le applicazioni web sviluppate con tale nuova metodologia di programmazione,
utilizzando XAML, potrebbero sostituire o comunque porsi come alternativa alle
applicazioni
web
basate
sull’HTML
ed
altre tecnologie
web
pubbliche
e
standardizzate; in tale situazione l’interazione con l’utente verrebbe affidata ai
controlli XAML e non più alle tradizionali web form ed il carico elaborativo sarebbe
spostato in maniera consistente sul lato client, riducendo e strutturando in maniera
differente gli scambi di dati via rete tra client e server (tale comunicazione
probabilmente consisterà nello scambio di pacchetti appositamente organizzati in
relazione alle funzioni della specifica applicazione). Questa tendenza è confermata
anche dallo scarso impegno della Microsoft nell’implementare e sviluppare nuove
versioni del proprio browser Internet Explorer (IE) compatibili con i più recenti
standard di Internet definiti dal World Wide Web Consortium. Al contrario l’azienda
americana ha previsto di eliminare del tutto dalla versione 7 di IE il supporto alla
visualizzazione di contenuti web che non siano le parti utente delle applicazioni di
rete sviluppate sotto Windows, le quali utilizzano interfacce utente XAML. L’impatto
di una simile scelta potrebbe segnare fortemente il futuro del web se si pensa che
attualmente IE è il browser utilizzato da più del 90% degli utenti del web stesso.
Oltretutto IE sarà direttamente integrato nel sistema operativo a partire dalla nuova
versione di Windows e non sarà più disponibile quale pacchetto software aggiuntivo.
Le applicazioni prodotte utilizzando XAML sono formate da un insieme di pagine
(definite ciascuna, per ciò che riguarda le funzionalità, da un file XAML), tra le quali è
possibile navigare sul modello del web ma con possibilità di azioni molto differenti,
durante l’avanzamento delle elaborazioni; queste pagine sono gestite da codice
procedurale che permette di modificare i controlli utilizzandoli dinamicamente
nell’interazione con l’utente e di agganciare le funzionalità vere e proprie della parte
elaborativa dei programmi. Al giorno d’oggi i linguaggi di programmazione compatibili
.NET utilizzabili per lo sviluppo di applicazioni della tipologia descritta sono C#,
Visual Basic .NET e JScript .NET. Attualmente sono già disponibili dei tool per lo
sviluppo delle interfacce grafiche di queste applicazioni adoperando XAML.
In questo contesto diviene fondamentale, per una corretta gestione del software
web, scaricato magari dalla rete ed eseguito localmente, porre molta attenzione al
problema della sicurezza. Attualmente infatti gran parte dei computer sono sempre
connessi in rete, ad Internet il più delle volte, e tale connessione rappresenta sempre
più spesso una fonte insicura di dati ed applicazioni di rete che contengono bug o
effettuano operazioni illecite. Per evitare ciò, a partire dalla nuova versione di
Windows, sarà introdotto il paradigma del “managed code”, ovvero il software verrà
eseguito all’interno di un container (di un processo applicativo) che ne controllerà, tra
le altre cose, le richieste di memoria ed i criteri di accesso alle risorse. Ciò
permetterà di fornire un certo livello di sicurezza nell’esecuzione delle applicazioni,
alleggerendo il programmatore dall’implementazione di tali funzionalità quali parte
integrante della specifica applicazione. Oltre a ciò, un ulteriore miglioramento del
sistema in termini di sicurezza sarà ottenuto grazie all’introduzione in Longhorn di un
nuovo File System detto WinFS che dovrebbe fornire maggiori garanzie nel verificare
gli accessi ai dati, oltre che maggiore affidabilità e velocità di ricerca delle
informazioni.
Viene descritto nel seguito, più in dettaglio, come viene realizzata l’interfaccia
utente delle applicazioni adoperando XAML.
Il linguaggio XAML è strettamente correlato ad Avalon, il sistema di
presentazione di Longhorn il quale, grazie ad un’elaborata collezione di librerie e
gerarchie di classi, permette di supportare interfacce capaci di gestire documenti di
vario tipo e contenuti multimediali e caratterizzate da notevoli possibilità di
elaborazioni grafiche.
Ogni parte di un’interfaccia, infatti, è di solito gestita per mezzo di una
componente di Avalon e, tramite sintassi XAML, sostanzialmente, le varie
componenti, che formano nel loro insieme la user interface, vengono istanziate,
organizzate e inizializzate con opportuni valori. Ogni elemento del vocabolario XAML
corrisponde ad una classe Avalon dalla quale deriva il proprio nome; per mezzo delle
proprietà degli elementi di solito vengono definiti i parametri relativi all’istanziazione
dei vari oggetti (componenti Avalon).
La struttura gerarchica dei documenti XML e quindi anche dei file XAML, ben si
presta a descrivere le gerarchie di classi che devono essere istanziate per definire
un’interfaccia utente; questa possibilità riduce il lavoro dei programmatori se
paragonata alla determinazione di tali caratteristiche dell’interfaccia delle applicazioni
per mezzo di sintassi procedurale, molto più complessa ed oltretutto spesso mista a
parti relative alla definizione delle elaborazioni da effettuare e non della user
interface. XAML si presenta come uno strumento per definire interfacce utente
adoperando una sintassi molto più coincisa, strutturata e facilmente interpretabile
rispetto al codice procedurale; è però importante notare che tutto ciò che può essere
determinato per mezzo di XAML, è possibile anche specificarlo adoperando un
linguaggio di programmazione, istanziando e settando opportunamente i vari oggetti
che compongono un’interfaccia. Oltretutto alcune delle possibilità di definizione delle
user interface che mette a disposizione Avalon non possono essere strutturate
adoperando XAML, ma solamente usando la sintassi procedurale. Ciò pero non
sminuisce le notevoli potenzialità di XAML.
Grazie a XAML e all’ introduzione della sintassi dichiarativa XML, diviene
possibile definire dei fogli di stile XSLT (EXtensible Stylesheet Language Transform)
per trasformare, rispettando regole di trasformazione generali, un documento XML
organizzato secondo la struttura (elementi ed attributi) di un determinato vocabolario
in un documento XAML che sfrutta le potenzialità delle classi Avalon.
Al momento della renderizzazione, un file XAML può essere già stato compilato
passando attraverso la conversione automatica del proprio contenuto da sintassi
dichiarativa a sintassi procedurale, producendo così un file sorgente intermedio
comprendente sia il codice eventualmente inserito nel file XAML per la gestione
dell’interfaccia, che il codice ulteriore necessario a definire l’interfaccia stessa,
ricavato traducendo gli elementi XAML. In alternativa un file XAML può essere letto e
convertito a run-time in una serie di oggetti opportunamente istanziati di cui si
compone la user interface.
Le applicazioni web che fanno uso di XAML di solito sono costituite da una o più
pagine XAML e del codice per la gestione delle elaborazioni e delle proprietà
dell’interfaccia utente. La parte client di tali applicazioni Windows può essere
scaricata da server, eseguita su sistemi Windows compatibili con XAML, essendo
ospitata (hosted) e controllata nell’esecuzione tramite un browser apposito. Molto
probabilmente tale ruolo di hosting delle applicazioni web e supporto alla
renderizzazione dell’interfaccia sarà implementato nella futura versione 7 di Internet
Explorer in Windows Longhorn. Queste applicazioni web di solito vengono scaricate
in rete in versione già compilata o parzialmente compialta per l’esecuzione su
piattaforme Windows; esse rappresentano una possibile evoluzione del modello
attuale di programmazione e gestione delle applicazioni web lato client (HTML +
Javascript).
Nel seguito verranno analizzate le principali caratteristiche dei documenti
XAML.
Tale linguaggio di definizione dell’interfaccia utente è formato da una serie di
elementi che uniti concorrono a definire una struttura gerarchica di oggetti e vengono
suddivisi, in base alle loro caratteristiche, in quattro grandi famiglie:
1. PANELS: elementi che fungono sostanzialmente da contenitori di altri
elementi e hanno la funzione di organizzare adeguatamente il layout;
2. CONTROLS: elementi utilizzati per realizzare le caratteristiche base
dell’interazione con l’utente; ve ne sono numerose tipologie per permettere di
implementare con flessibilità ed efficacia le caratteristiche di interattività
dell’applicazione (button, input field, checkbox, combobox, menù submenàù,
scrollbar, drop-down list, spider, hyperlink, etc.);
3. TEXT FORMATTING ELEMENTS: elementi utili a formattare il testo e trattare
i documenti e la loro visualizzazione ottimale all’interno dell’interfaccia utente;
4. SHAPES: elementi adoperati per inserire della grafica vettoriale nelle
interfacce.
I Panels, componenti fondamentali di XAML, come affermato, offrono
l’opportunità di posizionare e renderizzare adeguatamente gli elementi che
contengono. E’ inoltre possibile annidare a piacimento i Panels così da avere
maggiori possibilità di definizione del layout delle pagine. Esistono sei differenti tipi di
Panels:
NOME
CARATTERISTICHE
Canvas
Posiziona gli elementi contenuti secondo coordinate relative all’area a
disposizione per la renderizzazione e permettendone la sovrapposizione.
Dock
Panel
Posiziona gli elementi contenuti con riferimenti relativi tra gli elementi
stessi (a destra/sinistra/in alto/in basso rispetto all’elemento
precedentemente dichiarato).
Flow
Panel
Visualizza e posizione gli elementi contenuti secondo l’ordine con cui sono
stati definiti arrangiandoli ed organizzandoli in maniera automatica al fine
di utilizzare al meglio l’area a disposizione. E’ adatto a gestire complesse
renderizzazioni di testo e grafica.
Text
Panel
E’ utilizzato per ottenere una gestione ottimale di complessi layout di
contenuti testuali e supporta molti formati di file di testo
Grid
Panel
Serve per organizzare gli elementi contenuti in griglie, a formare righe e
colonne di controlli dell’interfaccia utente. E’ usato per creare semplici
tabelle di layout.
Fixed
Panel
E’ usato per posizionare gli elementi di una pagina definendo un layout
fisso, che rispetta la stessa organizzazione e posizionamento delle parti
dell’interfaccia, indipendentemente dalle dimensioni della finestra o dalla
risoluzione del device.
Tramite i panels è quindi possibile strutturare facilmente interfacce grafiche che
si adattano automaticamente alle dimensioni dell’area dello schermo disponibile; tale
problema in alternativa può essere risolto con una cospicua e ben più complessa
quantità di codice procedurale dedicato.
Nel definire le caratteristiche grafiche dell’interfaccia, XAML permette di
adoperare la grafica vettoriale per mezzo degli elementi SHAPES, offrendo la
possibilità di includere le forme geometriche delle seguenti tipologie: Ellipse, Line,
Rectangle, Path, Polygon e Polyline.
Di ognuno dei precedenti elementi è possibile definire numerose proprietà tra
cui le dimensioni, i bordi, i colori, etc. Oltretutto i vari elementi che compongono
l’interfaccia utente possono essere modificati mediante trasformazioni di vario tipo
come rotazioni ad esempio sull’asse, traslazioni, rappresentazioni in scala, etc. E’
possibile anche animare con facilità le varie caratteristiche e proprietà dei controlli
dell’interfaccia, ottenendo tramite semplici procedimenti, effetti grafici molto
interessanti.
Con XAML vi è la possibilità di definire tramite l’elemento <style> degli stili,
ovvero delle proprietà comuni ad un certo gruppo di elementi che riferiscono tutti il
medesimo stile (questa caratteristica è assimilabile ad alcune delle possibilità offerte
dai Cascading Stylesheet CSS).
Ogni componente dell’interfaccia utente è rappresentata da un elemento
apposito del markup XAML e riferisce un oggetto XAML che verrà istanziato a tempo
di esecuzione; le proprietà degli oggetti possono essere specificate per mezzo delle
proprietà degli elementi XAML o nei casi più complessi per mezzo di gerarchie di
elementi discendenti da quello da determinare.
L’interfaccia viene gestita per mezzo di codice procedurale associato al fine di
trattare opportunamente gli eventi; tale parte procedurale del file XAML, che è
possibile includere anche in un file esterno, rende necessaria la compilazione
dell’applicazione prima dell’esecuzione e può essere sviluppata in linguaggi come
C#, Visual Basic .NET o JScript .NET; all’interno di tale codice è possibile riferire le
varie parti della gerarchia di oggetti dell’interfaccia e modificarle con grande
immediatezza. Ad esempio: bottone1.Width = new Length(90); setto la proprietà
Width (larghezza) del bottone riferito dalla variabile di nome bottone1 a 90 pixel.
Attraverso il seguente esempio, opportunamente commentato, viene mostrato
come è strutturata una semplice interfaccia utente utilizzando XAML. Tale esempio è
una dimostrazione basilare delle possibilità di XAML; le interfacce realizzate
adoperando tale linguaggio e quindi appoggiandosi alla collezione di classi grafiche
Avalon presentano una complessità ed una ricchezza di componenti molto maggiore.
Esempio di organizzazione di un file XAML.
<Window
xmlns=http://schemas.microsoft.com/2003/xaml
xmlns:def="Definition" def:Class="CounterSample.Counter"
<!-- La proprieta' def:CodeBehind indica il nome del file nel quale e'
presente il codice procedurale per la gestione della interfaccia
utente -->
<!-- def:CodeBehind="Counter.xaml.cs" -->
Text="Esempio XAML"
Visible="True"
Width="268"
Height="150"
Loaded="OnLoaded">
<!-- All'interno dell'elemento Window.Resources si specificano le proprieta'
comuni di alcune classi di elementi; in tal caso tutti i bottoni inseriti
nell'interfaccia utente saranno caratterizzati dal margine e dalla
dimensione dei caratteri di seguito specificati (elemento style) -->
<Window.Resources>
<Style>
<Button Margin="5" FontSize="14" />
</Style>
</Window.Resources>
<!-- L'elemento FlowPanel definisce automaticamente il layout degli elementi
dell'interfaccia che contiene sfruttando al meglio l'area disponibile -->
<FlowPanel>
<-- Tramite l'elemento FlowPanel.Background definisco le modalita'
relativamente alla sfumatura dei colori di sfondo del FlowPanel (sto
modificando una proprieta' del FlowPanel) -->
<FlowPanel.Background>
<LinearGradientBrush StartPoint="0.5,0" EndPoint="0.5,1">
<LinearGradientBrush.GradientStops>
<GradientStop Color="#E7E7E7" Offset="0" />
<GradientStop Color="#FFFFFF" Offset="0.02" />
<GradientStop Color="#FFF287" Offset="0.2" />
<GradientStop Color="#F9E11A" Offset="0.98" />
<GradientStop Color="#000000" Offset="1" />
</LinearGradientBrush.GradientStops>
</LinearGradientBrush>
</FlowPanel.Background>
<!-- L'elemento SimpleText inserisce del testo definendone alcune proprieta'
di formattazione -->
<SimpleText Margin="5" FontSize="14">Esempio XAML</SimpleText>
<!-- L'elemento TextBox determina una casella di testo specificandone le
dimensioni, l'allineamento, il margine e la modalita' di sola lettura
del contenuto -->
<TextBox ID="ValueTextBox" FontSize="14" Width="250" Height="30"
HorizontalAlignment="Center" IsReadOnly="True" Margin="5"></TextBox>
<!-- L'elemeto FlowPanel annidato all'interno di un altro elemento FlowPanel
serve per definire il layout dei tre bottoni -->
<FlowPanel HorizontalAlignment="Center" Width="100%">
<!-- I tre elementi Button definiscono tre bottoni all'interno del
FlowPanel col testo visualizzato su ognuno ed associando, per mezzo
della proprieta' Click all'evento "click del mouse sul bottone"
l'esecuzione della funzione di nome rispettivamente Funz_a, Funz_B e
Funz_C; il codice associato a tali funzioni sara' contenuto nel file
di codice specificato quale valore dell'attributo def:CodeBehind del
root element Window -->
<Button Click="Funz_A">A</Button>
<Button Click="Funz_B">B</Button>
<Button Click="Funz_C">C</Button>
</FlowPanel>
</FlowPanel>
</Window>
Di seguito è mostrato come viene visualizzato il file XAML appena descritto:
XUL versus XAML: l’evoluzione delle interfacce utente
delle applicazioni web
XUL e XAML sono due delle principali proposte, attualmente in fase di sviluppo
e di perfezionamento, riguardanti nuovi linguaggi XML-based per la definizione di
elaborate interfacce utente per applicazioni di varia tipologia. Se per quanto riguarda
lo sviluppo di software per desktop già ora sono disponibili elaborate interfacce
grafiche da poter adoperare, riferendosi alle applicazioni web, l’interazione con
l’utente, al giorno d’oggi, il più delle volte, è ottenuta per mezzo del tradizionale
scambio di documenti HTML contenenti eventuali form supportati magari da script,
secondo un modello di gestione delle operazioni inevitabilmente condizionato dalla
natura page-based delle applicazioni di rete tuttora diffuse (si visitano, interagendo,
una serie di pagine).
Al contrario le applicazioni web sviluppate appoggiandosi a tali linguaggi per
gestire l’interazione con l’utente (lato client), permettono una definizione della
porzione front-end molto più ricca e strutturata. Sia XUL che XAML sono entrambi
inseriti in uno specifico ambiente di sviluppo di applicazioni. In particolare XAML sarà
pienamente supportato per ciò che riguarda la produzione del software nella
prossima versione di Microsoft Windows denominata Longhorn e sarà integrato nel
framework Microsoft .NET, mentre XUL è supportato dalla piattaforma Mozilla e,
assieme ad altre componenti del Mozilla XPToolkit, permette prevalentemente lo
sviluppo di applicazioni di rete.
Nonostante siano numerose le affinità tra tali due linguaggi di definizione
dell’interfaccia utente, le finalità che stanno alla loro base sono ben differenti:
ƒ
XUL si propone di rendere possibile la creazione di elaborate interfacce
utente, presentandosi come uno standard aperto, supportato dalla piattaforma
Mozilla (XPToolkit) la quale permette la renderizzazione e la gestione di molti
altri standard del web (HTML, DOM, CSS, supporto a Javascript, etc.). I
browser Mozilla e Netscape nelle versioni attuali sono implementati sfruttando
tale piattaforma. Strettamente connesse a XUL sono oltretutto tecnologie
molto diffuse e da tempo standardizzate quali CSS e Javascript.
ƒ
XAML è un linguaggio sviluppato interamente dalla Microsoft che per molti
aspetti ricalca le caratteristiche di XUL, già diffuso al momento della creazione
di XAML. Per mezzo di XAML è possibile definire complesse user interface
per applicazioni Windows appoggiandosi per la loro gestione al codice
procedurale adoperabile all’interno del framework .NET. XAML è fortemente
correlato alla gerarchia di classi Avalon sviluppate dalla Microsoft che si
occupano di gestire l’interfaccia utente; con XAML sostanzialmente si
definisce con sintassi XML l’organizzazione gerarchica degli oggetti Avalon
che compongono l’interfaccia.
Le applicazioni web in futuro potrebbero appoggiarsi, per ciò che concerne la
user interface, a tali nuovi UIDL piuttosto che agli standard web tuttora diffusi per
l’implementazione dell’interfaccia del client e, più in generale della comunicazione
client-server. In questa maniera si passerebbe da una struttura basata sulla
visitazione successiva di pagine (page-based), che attualmente è la più adoperata,
ad una gestione più elaborata lato client delle azioni dell’utente, non più una
sequenza di pagine da visitare ma un vero e proprio programma in esecuzione
localmente. In questo modo si permette all’applicazione di accedere alle risorse
locali e di comunicare all’occorrenza con il server. In tale contesto diviene di
fondamentale importanza una corretta gestione della sicurezza, della portabilità,
della facilità d’uso e dell’accessibilità delle applicazioni.
Se XUL è un UIDL open standard e basato su un progetto open source di
piattaforma per lo sviluppo di applicazioni, XAML è stato ideato dalla Microsoft sia
per semplificare la programmazione delle user interface del software prodotto, ma
soprattutto per disporre di un linguaggio XML-based proprietario per la definizione
della porzione front-end delle applicazioni web, con possibilità grafiche paragonabili a
quelle delle applicazioni desktop. Se si pensa alla grande diffusione del sistema
operativo Windows nelle sue varie versioni e del browser Microsoft Internet Explorer
è evidente come la Microsoft abbia la forza per spingere l’utenza del web all’uso di
questa sua nuova tecnologia nelle applicazioni di rete. Ciò, come già sottolineato, è
confermato dalla intenzione
della Microsoft di non supportare più dalla futura
versione 7 di Internet Explorer, la visualizzazione di contenuti web che non siano le
parti client di applicazioni Windows sviluppate adoperando XAML.
I competitor di Microsoft affermano, confermando tale tendenza, che se nel giro
di alcuni anni non emergerà uno standard aperto e retrocompatibile con HTML e col
DOM in maniera tale da poter essere anche adoperato con le vecchie versioni dei
vari browser tra cui Internet Explorer 6 (che probabilmente sarà l’ultima versione di IE
che supporta le tecnologie open standard diffuse sul web attualmente), accadrà che
nel giro di una decina di anni con molta probabilità lo standard per le applicazioni
web sarà Microsoft Avalon ed il framework .NET.
Al giorno d’oggi il futuro del web, delle applicazioni di rete e della gestione
dell’interazione con l’utente è molto incerto; le proposte sono molteplici se si
considera il giro di interessi, anche economici che circonda tali problematiche.
In questo panorama frammentato si delineerà probabilmente o il raggiungimento
della standardizzazione delle nuove tecnologie adoperate sul web o la coesistenza di
soluzioni proprietarie concorrenti; in tale processo di definizione del futuro del web la
forza delle aziende e delle organizzazioni coinvolte sicuramente costituirà un fattore
determinante.
Conclusioni
L’analisi sviluppata nei capitoli di questo studio consente di dedurre che
attualmente c’è un forte fermento: in rapporto al trattamento dei dati circolanti su web
tramite form sono in atto numerosi tentativi di individuare una soluzione che sia
efficace e flessibile oltre che ampiamente supportata. Tutto ciò è di grande attualità
anche perché oggi il web è divenuto veicolo per lo scambio di informazioni relative
anche a processi di business intorno ai quali gravitano forti interessi economici.
Ciò che risulta evidente è che le esigenze di interattività delle applicazioni web,
fortemente connesse alla possibilità di poter trattare facilmente e in maniera
immediata l’input degli utenti per permettere loro di sfruttare appieno le possibilità
della comunicazione in rete, sono cresciute e, il più delle volte, l’HTML assieme alle
form con esso definite, non sono più sufficienti a soddisfarle. Vi è la necessità di
avere a disposizione mezzi più potenti che permettano di strutturare l’interazione con
l’utente la quale caratterizza le applicazioni web, in maniera più flessibile, immediata
e ricca: si faccia riferimento, ad esempio, ai metodi con i quali è possibile reperire
dati dall’utente e comunicarli attraverso la rete ad un eventuale server.
Le risposte a tali esigenze sono molteplici e sono state discusse nelle
precedenti sezioni di questo elaborato. Dalla ricerca svolta risulta che esse sono
sostanzialmente divisibili in due grandi categorie, ovvero in soluzioni che mirano a
definire degli standard pubblici e delle piattaforme di sviluppo web open source e in
proposte di nuove tecnologie proprietarie, sostenute da aziende leader nel settore
informatico.
Il World Wide Web Consortium ha proposto e standardizzato la tecnologia
XForms per fornire una nuova soluzione per la gestione dell’input degli utenti, in
merito alle applicazioni e ai servizi web, che tenga conto sia delle maggiori esigenze
di interattività manifestate in tale ambito che della progressiva affermazione dell’XML
come mezzo principe per veicolare le informazioni in rete; tale tecnologia però è
legata alla presenza di un’applicazione lato client che si occupa di gestire i moduli
elettronici.
Il Web Hypertext Application Technology Working Group, organizzazione
impegnata nello sviluppo di nuove tecnologie direttamente connesse ad applicazioni
web, ha proposto le specifiche
Web Forms 2.0, ovvero delle estensioni alle form HTML che, pur mantenendo la
retrocompatibiltà col passato, hanno l’obiettivo di estenderne le caratteristiche
tenendo, ove possibile, conto delle nuove esigenze manifestatesi sul web.
Sia Mozilla, fondazione per la produzione di software open source, che la
Microsoft stanno addirittura sviluppando nuove piattaforme per lo sviluppo di
applicazioni web che permettono di gestire l’interazione con l’utente attraverso delle
interfacce elaborate che si appoggiano a librerie grafiche avanzate, la cui definizione
è resa possibile per mezzo di appositi User Interface Definition Languages, ovvero di
linguaggi appositamente strutturati, i quali adoperano una sintassi dichiarativa XMLbased. Tra gli UIDL attorno ai quali oggi vi è maggiore attenzione da parte degli
sviluppatori web vi sono l’EXtensble Application Markup Language della Microsoft e
l’Extensible Usre-interface Language implementato da Mozilla. Tale tipologia di
applicazioni web, nelle quali è possibile decentrare parte delle elaborazioni lato
client, potrebbe sostituirsi col tempo all’attuale modello di sviluppo di applicazioni
web, in cui gran parte delle elaborazioni avviene lato server e il server stesso
comunica con i client sostanzialmente per mezzo dell’HTML, affiancato da eventuali
tecnologie complementari che ne estendono le potenzialità.
In questo scenario è rilevante considerare anche le più importanti tecnologie
proprietarie per la gestione dell’input degli utenti delle applicazioni web che sono:
Microsoft Web Forms ed ASP.NET, Microsoft Info Path, Adobe Form Designer,
Macromedia Flash MX.
Oltre a quelle appena menzionate, molte sono le soluzioni meno note, poiché
più specifiche e legate a particolari piattaforme, adottate per la raccolta di
informazioni e l’interazione con l’utente su web; tra queste vi è il framework Cocoon
Forms per la gestione dei moduli elettronici delle applicazioni web che si appoggiano
alla servlet Cocoon.
In conclusione è possibile affermare che oggi vi sono varie proposte di nuove
tecnologie relative alla gestione delle form nel web e più in generale dell’interfaccia
delle applicazioni di rete con gli utenti web e che esse sono più o meno diffuse e
spesso in continua evoluzione e in perfezionamento. Sembra probabile che col
tempo si superi tale varietà di proposte e si arrivi ad una soluzione stabile e
largamente supportata.
Bibliografia
1. Micah Dubinko - XForms Essentials - O’Reilly Editions, 1st Edition
August,2003
2. Elliotte Rusty, W. Scott Means - XML in a Nutshell - Editions, 2nd edition
June,2002
3. Doug Tidwell - XSLT - O’Reilly Editions, 1st Edition August,2001
4. David Flanagan - JavaScript: The Definitive Guide - O’Reilly Editions, 4th
Edition November,2001
5. [www.w3.org] World Wide Web Consortium Web Site
6. [www.w3.org/TR/Markup/] HTML Home Page
7. [www.w3.org/MarkUp/html-spec/html-spec_toc.html] HTML 2.0
8. [www.w3.org/TR/html401/] HTML 4.01
9. [www.w3.org/Style/CSS/] CSS - Cascading Style Sheet 2.1
10. [www.w3.org/TR/2003/REC-xforms-20031014/] XForms 1.0
11. [www.w3.org/XML/] XML - Extensible Markup Language 1.0
12. [www.w3.org/TR/xpath] XPath - XML Path language 1.0
13. [www.w3.org/Style/XSL/] XSLT - Extensible Stylesheet Language
Transformation 1.0
14. [www.w3.org/DOM/] DOM
15. [www.w3.org/TR/REC-xml/#dt-doctype] DTD
16. [www.w3.org/XML/Schema] XML Schema
17. [www.w3.org/TR/xhtml2/] XHTML
18. [www.w3.org/Protocols/rfc2616/rfc2616.html] HTTP protocol
19. [www.whatwg.org] Web Hypertext Application Technology Working Group
Web Site
20. [www.whatwg.org/specs/web-forms/2004-06-27-call-for-comments/] Working
draft: Web Forms 2.0 - Call for Comment (27/6/2004)
21. [www.apache.org/] Apache
22. [cocoon.apache.org] Apache Cocoon Web Site
23. [cocoon.apache.org/2.1/userdocs/concepts/#Pipeline+Processing] Cocoon
and pipeline processing
24. [cocoon.apache.org/2.1/userdocs/flow/api.html] Flowscript Cocoon
25. [cocoon.apache.org/2.1/userdocs/forms/] Cocoon Forms
26. [www.mozilla.org/] Mozilla
27. [www.mozilla.org/why/framework-details.html] The Mozilla Application
Framework in Detail
28. [www.mozilla.org/projects/xul/xul.html] XML User Interface Language (XUL)
29. [www.mozilla.org/projects/xul/joy-of-xul.html] Peter Bojanic - The Joy of XUL 2/12/2003
30. [www.mozilla.org/xpfe/xptoolkit/] Mozilla XPToolkit
31. [www.mozilla.org/projects/xpcom/] XPCOM
32. [http://wiki.mozilla.org/Gecko:Home_Page] Gecko
33. [www.mozilla.org/projects/netlib/] Necko
34. [www.mozilla.org/projects/xbl/xbl.html] XBL
35. [wp.netscape.com/eng/mozilla/3.0/handbook/javascript] Sito JavaScript
36. [www.microsoft.com] Microsoft
37. [msdn.microsoft.com/Longhorn/] Longhorn
38. [www.ondotnet.com/pub/a/dotnet/2004/01/19/longhorn.html] Ian Griffiths Inside XAML - 19/1/2004
39. [msdn.microsoft.com/msdnmag/issues/04/01/DevelopingAppsforLonghorn/def
ault.aspx] Dino Esposito - CODE NAME LONGHORN: A First Look at Writing
and Deploying Apps in the Next Generation of Windows - 27/8/2004
40. [http://msdn.microsoft.com/longhorn/understanding/pillars/avalon/default.aspx
?pull=/msdnmag/issues/04/01/Avalon/default.aspx] CODE NAME AVALON:
Create Real Apps Using New Code and Markup Model - Charles Petzold gennaio,2004
41. [msdn.microsoft.com/library/en-us/script56/html/js56jsoriJScript.asp] Sito
JScript
42. [www.microsoft.com/net/] .NET
43. [www.microsoft.com/office/infopath/prodinfo/default.mspx] InfoPath
44. [www.asp.net/] Sito ASP
45. [www.visual-basic.it/uploads/articoli/tecnici/fbFramework.htm] Fabrizio
Baldazzi - Il Framework .NET: questo sconosciuto - 2002
46. [xml.coverpages.org/userInterfaceXML.html] XML Markup Languages for User
Interface Definition
47. [xul.sourceforge.net/counter.html] Raccolta di esempi di UIDL: XUL Grand
Coding Challenge 2004 - Counter Sample Showcase
48. [www.aspnetpro.com/opinion/2004/03/asp200403jg_o/asp200403jg_o.asp]
Jonathan Goodyear - What will happen when Windows and the Web collide? aprile,2004
49. [webnews.html.it/focus/395.htm] Cesare Lamanna - Il futuro dei browser 3/6/2004
50. [www.sax.net/live/?date=10/31/2003] Mike Sax - Is XAML the future of the
web? - 31/10/2003
51. [www.devx.com/DevX/Article/17899/0] Nigel McFarlane - Longhorn and
Mozilla: Birds of a Feather - 25/11/2003
52. [www.davidtemkin.com/mtarchive/000004.html] David Temkin - W3C
standards and Web applications - 19/6/2004
53. [wesnerm.blogs.com/net_undocumented/2003/10/xaml_and_standa.html] Joe
Beda - XAML and Standards - 30/10/2003
54. [www.asp.net/] Microsoft ASP.NET
55. [msdn.microsoft.com/library/default.asp?url=/library/enus/dndotnet/html/introwebforms.asp] Paul D. Sheriff - Introduction to ASP.NET
and Web Forms - novembre 2001
56. [www.adobe.com/] Adobe System Web Site
57. [www.adobe.de/products/server/formdesigner/main.html] Adobe Form
Designer
58. [www.oreillynet.com/pub/a/javascript/2003/05/20/colinmoock.html] Colin
Moock - A Study in Flash Form Submission - 20/5/2003
59. [www.macromedia.com/] Macromedia
60. [www.macromedia.com/software/flash/] Macromedia Flash MX
61. [www.macromedia.com/support/flash/ts/documents/f4_form.htm] How to
create and submit a form in Flash 4
62. [www.internetnews.com/dev-news/print.php/3361141] Sean Michael Kerner Mozilla, Opera Join Forces For New W3C Proposal - 31/5/2004
63. [www.w3schools.com/xforms/xforms_intro.asp] Sito di e-learning: Introduction
to XForms
64. [www.xml.com/pub/a/2001/09/05/xforms.html] Micah Dubinko - What Are
XForms? - agosto 2003
65. [www.xsmiles.org/] Sito del web browser X-Smiles
66. [http://www.eweek.com/article2/0,3959,985910,00.asp] Timothy Dyck XForms: Next Destination for Web Forms - 31/3/2003
67. [freephp.html.it/] Sito italiano di guide e tutorial di sul PHP
68. [www.javascript.it/] Sito italiano di risorse di sul linguaggio JavaScript
69. [www.php.net] Sito PHP
70. [hoohoo.ncsa.uiuc.edu/cgi/] Sito CGI
71. [www.ecma.international.org] ECMA
72. [www.ecma-international.org/publications/standards/Ecma-262-htm]
ECMAScript