giugno 2006 Se per gli utenti finali tutti questi siti costituiscono l’effetto tangibile e il principale motivo d’interesse della tecnologia Ajax, per gli sviluppatori applicativi conta soprattutto chiedersi come fare per realizzare applicazioni in que …
giugno 2006 Se per gli utenti finali tutti questi siti costituiscono
l’effetto tangibile e il principale motivo d’interesse della tecnologia Ajax,
per gli sviluppatori applicativi conta soprattutto chiedersi
come fare per realizzare applicazioni in questo nuovo paradigma web-oriented.
Sostituire una programmazione client-based tradizionale con un modello client-server
basato su tecnologie come Javascript, XML, CSS, XSLT, DOM e HTTP rappresenta
un cambiamento quasi epocale per chi è abituato a programmare e commercializzare
software con l’approccio classico.
Lo sviluppo di applicazioni Ajax, in particolare, pone delle sfide impegnative
perfino per chi già conosce tutte le tecnologie elementari in gioco che
sono state appena citate:
- I Web browser hanno delle leggere differenze, nel supporto JavaScript,
nel modello DOM, nel DHTML e in altri aspetti minori, che li rendono non perfettamente
compatibili, seppure equipotenti. Così, pur essendo possibile realizzare
applicazioni che girano in modo uguale su qualunque client recente, per farlo
occorrono una approfondita conoscenza di queste sfumature e un costo implementativo
per assorbirle e neutralizzarle col proprio codice. - Nel modello Ajax, la quota di codice destinata a girare lato client va
scritta in JavaScript (o più precisamente nel dialetto JavaScript supportato
dal browser). Non tutti i programmatori applicativi classici, abituati a lavorare
in linguaggi come C++ o Java, conoscono JavaScript in modo approfondito. - Nel JavaScript oggi supportato direttamente dai browser mancano tutte quelle
librerie “ricche”, object-oriented, che gli sviluppatori sono abituati
a trovare in ambito .NET o Java. Per costruirsi un ambiente equivalente in
cui lavorare, sarebbero costretti a ricostruirselo! - Lo sviluppo per Ajax, soprattutto per quanto riguarda il lato client, non
è normalmente supportato dagli ambienti integrati di programmazione
(Integrated Development Environment, IDE). L’ambiente “base” offerto
dai browser è scomodo e rudimentale e in queste condizioni anche il
debugging non risulta facile.
In questo contesto stanno cominciando ad apparire librerie, soluzioni e framework
per la programmazione Ajax. L’area più interessata dalle soluzioni è
proprio il lato client, quello in cui dominano JavaScript e i suoi “dialetti”
legati al browser usato: lo scopo è in genere duplice: da un lato tentare
di neutralizzare e nascondere queste differenze, dall’altro risparmiare al programmatore
applicativo il bisogno di diventare un guru di JavaScript per scrivere software
Ajax.
Da un lato vi sono librerie specializzate nel supporto alla programmazione
event-driven asincrona basata su XMLHttpRequest: per esempio, CGI::Ajax per
il Perl, Myghty per Python, o SAjax per vari linguaggi lato server (inclusi
PHP e Python).
Esistono poi dei framework che abbracciano il problema in modo più
ampio, fornendo un supporto più o meno completo a tutti gli aspetti del
flusso di controllo. Per il Perl, ad esempio, è degno di nota l’open
source Catalyst.
Molto completa appare già oggi la soluzione di Microsoft, Atlas, che
garantisce anche di ottenere una GUI ricca di widget potenti e con un look assai
vicino a quello tradizionale. Atlas appare orientato preferibilmente (ma non
esclusivamente) all’interazione con un back-end di tipo ASP.NET.
Per chi necessita di una libreria client-side (Open Source e gratuita per
qualunque uso, grazie alla licenza BSD) che copra il particolare aspetto dei
GUI widgets, merita una menzione la libreria Yahoo! User Interface.
