Perchè questo articolo
"XForms" is W3C's name for a specification of Web forms that can be used with a wide variety of platforms including desktop computers, hand helds, information appliances, and even paper. XForms started life as a subgroup of the HTML Working Group, but has now been spun off as an independent Activity. [1]
Questa definizione sicuramente non spicca per la capacità di scaldare gli animi nei confronti di una tecnologia poco nominata, poco diffusa e nei confronti della quale è, finora, risultato limitato l'interesse della comunità degli sviluppatori (indipendentemente dalla piattaforma).
XForms in realtà nasconde (probabilmente anche a causa di un battesimo poco felice) un approccio fondamentalmente nuovo all'architettura delle applicazioni web. L'intenzione di questo articolo è quindi quello di proporre un riassunto delle potenzialità che mi sono risultate evidenti finora. La decisione di intraprendere la stesura di questo articolo è dovuta anche alla constatazione che le risorse web dedicate all'argomento sono poche e quasi esclusivamente provenienti dai componenti dei team responsabili della redazione delle specifiche stesse (la panoramica si ovviamente ancora più ristretta per quanto riguarda la lingua italiana). Questo non è un tutorial e non vuole esserlo: sono soltanto pensieri personali scaturiti da letture e prove sul campo. Ogni commento ed osservazione sarà ben accetto.
Perchè XForms?
XForms nasce con lo scopo di superare le limitazioni che le specifiche HTML originali hanno evidenziano con il trascorrere degli anni, ma soprattutto di fornire uno strumento di sviluppo più adeguato alle necessità attuali e future. Occorre infatti ricordare che la parte delle specifiche HTML concernenti l'interazione con l'utente è rimasta praticamente invariata [2] (tag FORM, INPUT, TEXTAREA, SELECT...)
Sono state individuate alcune aree di intervento, tra le quali:
- I dati raccolti (ed inviati via GET o POST) dalle web form attuali sono sostanzialmente una serie di coppie chiave/valore di tipo stringa: è desiderabile disporre di un meccanismo maggiormente strutturabile e tipizzato;
- I valori inseriti dall'utente non hanno una modalità nativa di essere validati se non tramite elaborazioni client a mezzo script (JavaScript) o elaborazioni server (nel qual caso in realtà si può a tutti gli effetti considerare la pagina restituita una nuova form);
- Impostare relazioni di dipendenza tra i controlli (valori funzione di valori di altri controlli, o valori calcolati) è possibile unicamente tramite elaborazioni client a mezzo script da codificare caso per caso senza l'ausilio di strumenti precostituiti, oppure ancora tramite elaborazione server (caso per il quale si ripetono le stesse considerazioni esposte al punto precedente);
- La fase di invio dati (SUBMIT) delle web form attuali implica sostituire completamente la pagina contenente la form compilata dall'utente con una nuova pagina restituita dall'elaborazione server: per scenari nei quali è importante lo stato della pagina al momento dell'invio, è necessario dotarsi di un qualche meccanismo di gestione della sessione corrente in modo da ripristinarla;
- Dal punto di vista dello sviluppatore, risulta difficile riutilizzare una form in un diverso contesto (es.: apparati vocali, wap), o addirittura semplicemente in una pagina diversa, benchè le regole di validazione non cambino, dato lo stretto legame tra i dati da raccogliere e la loro rappresentazione;
- Consentire all'utente di lavorare in modalità (parzialmente-) disconnessa richiede lo sviluppo di framework aggiuntivi (esterni alle specifiche) di notevole complessità, tali da consigliare di adottare una struttura tecnologica completamente differente (Rich Internet Application);
Come si può facilmente osservare, queste limitazioni sono di carattere talmente generale che praticamente qualunque strumento di sviluppo ha dovuto affrontare e risolvere alla propria maniera (ASP.NET e Java su tutti, ma anche Flash e simili) contribuendo alla nascita di una moltitudine di strumenti a supporto, ovviamente incompatibili tra loro.
Cos'è XForms?
Descriviamo brevemente i tratti fondamentali dell'architettura su cui si basa XForms, cominciando proprio dall'Abstract delle specifiche XForms 1.0 [3], dato che non credo sia possibile esprimersi in maniera più chiara e coincisa:
XForms is an XML application that represents the next generation of forms for the Web. By splitting traditional XHTML forms into three parts—XForms model, instance data, and user interface—it separates presentation from content, allows reuse, gives strong typing—reducing the number of round-trips to the server, as well as offering device independence and a reduced need for scripting. XForms is not a free-standing document type, but is intended to be integrated into other markup languages, such as XHTML or SVG.
XForms è un'applicazione xml, quindi è costituita da un vocabolario, ma soprattutto propone un modello concettuale rigoroso della pagina web come elemento di interazione utente-applicazione. Occorre chiarire che l'ambito applicativo obiettivo di XForms è la "raccolta dati" in senso più generale: ovviamente sotto questa definizione estremamente generica può ricadere praticamente qualunque risorsa web il cui scopo non sia unicamente l'atavico contenitore di link ad altri documenti. Le innovazioni più felici sono state, probabilmente, due: il data bind dei controlli, e la capacità di invio e ricezione di documenti xml indipendentemente dal corpo della form stessa (per intenderci, senza il post back della pagina).
I pilastri su cui si basa XForms sono tre (più due): XForms Model, XForms Instance e XForms UI Controls (e come "collante" binding e submission). Un "modello" XForms descrive la struttura dati della form stessa: ogni modello contiene almeno uno "istanza" (ovvero un frammento xml da utilizzarsi come contenitore per i dati che si intende raccogliere), il destinatario delle informazioni raccolte (elemento xml "submission"), ed eventualmente elementi di tipo "bind" con la duplice funzione di shortcut per i collegamenti con i controlli utente e indicazioni di validità aggiuntive non esprimibili tramite XMLSchema.
I controlli definiti da XForms hanno la caratteristica di voler evidenziare il fine che si prefiggono piuttosto che l'aspetto che assumeranno quando verranno presentati all'utente: esemplare è il caso del controllo "select" che ha come propria variante "select1" che hanno in comune lo scopo di selezionare da una lista di scelte, ma il secondo con la limitazione ad una soltanto. Ovviamente, dipendentemente dalle capacità del device sul quale verranno interpretate le XForms, diverso sarà l'aspetto: potrebbe essere una form simile a quelle che vediamo tutti i giorni nel caso sia ospitata dentro un browser, ma altrettanto potrebbe essere un menù vocale via telefono, puttosto che una formattazione più "povera" come WML o come cita l'abstract stesso, in SVG per interfacce completamente grafiche. A questo punto probabilmente è utile osservare il codice di un esempio per fissare le idee [4].
Interessante notare che la pagina stessa diventi l'entità preposta alla conservazione dello stato dell'applicazione, poichè contenendo uno o più modelli cui sono "bindati" i valori mostrati dai controlli visibili all'utente (direttamente o tramite espressioni XPath), è sufficiente avere a disposizione questa serie più o meno numerosa di documenti xml per descriverlo esaustivamente. Il modello strutturale proposto richiama immediatamente alla mente MVC: esiste un modello, una vista (costituita dall'insieme di controlli utente) ma manca il controller, ovvero il responsabile per le azioni intraprese dall'applicazione in reazione agli eventi scatenati dall'utente. In realtà questo è presente, ma più difficile da scovare, poichè...non è scopo delle specifiche XForms definerla. Sarà l'applicazione di cui è parte la form stessa a realizzare questa parte nella modalità più opportuna: nei casi più semplici il ciclo di vita della form stessa potrebbe esaurire completamente la logica applicativa per mezzo della gestione eventi XForms (semplice form per l'invio di una mail con la validazione degli indirizzi), mentre in quelli più complessi potrebbe essere desiderabile una coordinazione di molteplici servizi web per il compimento dell'elaborazione (workflow).
Il supporto attuale e futuro per XForms
Attualmente XForms non gode di un supporto nè esteso tantomeno solido: Internet Explorer non lo supporterà nativamente nemmeno nella prossima versione 7, Microsoft Visual Studio di conseguenza non ne spingerà l'introduzione presso il grande pubblico. L'unica alternativa sono i plugin di terze parti tra i quali formsPlayer, oppure il meno invadente (anche se in beta e privo di molte funzionalità) Novell XForms Explorer (anche sotto forma di applicazione Java Web Start). Mozilla ha un ramo di sviluppo che intende supportare XForms. Su Opera e Safari non sono riuscito a trovare informazioni ufficiali, ma solo chiacchiere (Questo articolo di Micah Dubinko, offre una panoramica più ampia). Esistono implementazioni lato server che prevedono la traduzione opportuna prima dell'invio al client, ovviamente perdendo tutte le peculiarità relative alla dinamicità di XForms.
Allo stato di fatto nessuno pare scommettere su questa tecnologia. Perchè allora interessarsene? Provo a dare una risposta a questa domanda.
Il campo di azione di XForms
Recentemente si è assistito alla diffusione di un'approccio a molte delle necessità evidenziate con il paradigma di sviluppo denominato AJAX: benchè da più parti si sia sottolineato che forse non è un approccio vincente e tantomeno innovativo, in pochi mesi AJAX ha ottenuto un interesse considerevole. E' sufficiente invece fare una ricerca su Google per capire quanto XForms sia sconosciuto, nonostante sia una specifica disponibile da almeno 2 anni. Vediamo di capire se e quanto queste sigle abbiano in comune oltre alla "X" che contengono.
AJAX (Asyncronous XML And Javascript) realizza un sottoinsieme delle capacità native di XForms: invio di richieste e ricezioni di risposte dal server in modalità "asincrona" rispetto alla pagina nel suo complesso tramite l'oggetto XMLHttpRequest ed utilizzo dei dati tramite JavaScript per aggiornare l'interfaccia utente. La gestione della richiesta, l'invio e la gestione della risposta sono completamente a carico del programmatore (a meno di utilizzo di librerie esterne [5]che sostanzialmente simulano l'esistenza di oggetti JavaScript (proxy) dotati della stessa interfaccia degli oggetti remoti). Tutto questo in XForms è automatico.
E questo è solo l'inizio.
Avere a disposizione la capacità di effettuare il binding di controlli a porzioni di frammenti xml tramite XPath consente di disinteressanrsi della fase di aggiornamento dei valori dei controlli (tipicamente Javascript): il ricalcolo dell'espressione di bind lo fa per noi. Supponiamo di fare il solito (ormai) clone di Google Suggest. Gestire il caching dei suggerimenti in base alla chiave di ricerca, con aggiunta e ricerca, tutto realizzato in JavaScript (array) non è un gioco da 5 minuti. Lo è invece in XForms con il quale il tutto si riduce ad arricchire uno stesso frammento xml con i risultati della ricerca (XForms "insert" in fase di gestione della risposta del servizio), mentre la generazione della lista dei suggerimenti è automatica dato che conterrà una espressione XPath [del tipo "/googleresponse/result[@key=/googlerequest/value]" (assumendo siano presenti due istanze una il cui elemento radice è googlerequest e l'altra googleresponse).
Oltre alla semplicità e alla chiarezza con la quale è possibile esprimere l'intenzione del codice che si stà scrivendo (programmazione dichiarativa), è evidente che avere a disposizione nel ciclo di elaborazione flussi di documenti xml consente di utilizzare modalità standard di analisi, arricchimento, filtraggio e quant'altro, avvicinando il modello dell'applicazione web a qualcosa che assomiglia più ad una pipeline nella quale ciascun modulo è responsabile della elaborazione della propria parte [6].
Cosa manca all'appello
AJAX ha avuto come elemento trainante la diffusione di qualche tool (principalmente l'eccellente [5] per il .NET framework) che ne agevola la sperimentazione e , una volta verificata la corrispondenza alle proprie aspettative (o affascinati dalla semplicità con la quale si possono ottenere risultati di rilievo con poca fatica...), l'adozione definitiva.
Ovviamente tale successo è dovuto anche alla semplice integrazione nel modello di sviluppo canonico (trasparenza per l'utilizzatore) e alla constatazione che il processo di sviluppo stesso non viene stravolto dall'adozione di una nuova tecnologia.
All'opposto XForms sembra andare più nella direzione di un approccio SOA allo sviluppo: intendo dire che anzichè sviluppare appositamente dei layer di accesso al cuore dell'applicazione per esporne e comandarne le funzionalità nel contesto di colloquio continuo e diretto tra UI e applicazione stessa, XForms pare propendere per l'utilizzo di servizi indipendenti dal contesto, alla stregua dei web services (non necessariamente basati su SOAP), in modo particolare per lo scambio di documenti. Se ne deduce che le stesse accortezze dovrebbero essere adottate al fine di non rompere il legame (contratto) stretto con il client al momento della definizione del formato dati atteso.
Per questa (ed una infinita serie di altre, ancora da approfondire) ragioni, l'integrazione a basso impatto è (forse) possibile, ma non auspicabile a causa del rischio di non avvalersi delle potenzialità dell'approccio nella sua completezza. Uno studio sui casi d'uso e la generazione di template di progetti e linee guida consentirebbe, a mio avviso, di liberare la forza di XForms per una nuova generazione di applicazioni per le quali non sia più così vuoto il termine Smart Client.
Conclusioni
XForms ha tutte le carte in regola per prendere il proprio posto tra le tecnologie di sviluppo future: ha dalla sua molte armi, ma ha contro la difficoltà di trovare supporto tra i big del settore. In particolare Microsoft (in quanto leader del mercato - di ogni mercato - ha grandi responsabilità e autorevolezza) non pare (ancora?) interessarsi all'argomento, probabilmente poichè "superfluo" nell'ottica nella prossima versione del "mondo interfaccia-utente" in fase di sviluppo: Avalon (Windows Presentation Foundation) ed il linguaggio di programmazione XAML in collaborazione con il modello di deploy "Express", consentirà di "sfumare" la linea di demarcazione tra applicazioni web (povere nelle funzionalità e poco reattive) con le applicazioni stand-alone, al prezzo di vincolarsi in maniera definitiva al mondo Windows. Che la strada intrapresa sia simile pare evidente (XAML ed XForms hanno in comune qualcosa in più di essere basati su xml), la scelta di "svincolarsi" dalle restrizioni delle specifiche pubbliche ed aperte pure. Una scelta appunto. E' pure vero che XForms nel grande disegno di Microsoft rappresenterebbe una piccola porzione di tutte le funzionalità che offrirà Avalon, ma forse sarebbe una breccia importante: XForms+SVG+X3D+SMIL offrirebbero, se armonicamente sviluppati, un arsenale di tecnologie coerenti, indipendenti l'una dall'altra oltre che multipiattaforma. Che sia qui l'inghippo? Probabilmente non solo questo (ammesso che sia): coordinare lo sviluppo di tecnologie per condurle da uno stato embrionale ad uno sufficientemente maturo, sarebbe stato troppo dispendioso in termini di tempo, con il rischio di non arrivare in mai...
1) W3C XForms homepage: vi si possono trovare le specifiche 1.0 e la 1.1 (ancora in fase di definizione ma che aggiungono sostanzialmente il supporto a SOAP come modalita di invio dei dati, un definizione di "contesto" degli eventi scatenati, nuovi tipi XMLSchema...);
2) HTML 4.01 Specification: Chapter 17. Forms - User-input Forms: Text Fields, Buttons, Menus, and more;
3) XForms 1.0 Recommendation - Abstract;
4) XForms 1.0 Recommendation - G Complete XForms Examples oppure per esempi funzionanti per Novell XForms Explorer - Samples o ancora per formsPlayer - Samples;
5) Michael Schwarz - Ajax.NET - A free library for the Microsoft .NET Framework;
6) Apache Coccon: un framework basato sul concetto di pipeline di componenti;
7) Model-driven XML forms generation Part 1, Part 2: una coppia di articoli da IBM che illustra un tool per Eclipse per la generazione automatica di form.