La Filosofia di AJAX

Autore: Carlo Bongiovanni
Pubblicato il 3 agosto 2007

Post Correlati

• Nessun post correlato

Jesse James Garret dell’Adaptive Path ha coniato la definizione originale di AJAX.
Secondo questa definizione, AJAX incorpora queste caratteristiche:

• presentazione basata su standard usando l’Extensible HyperText Markup Language (XHTML) e fogli di stile a cascata (CSS).

• display dinamico dei dati ed interazione con essi utilizzando il Document Object Model (DOM)

• interscambio e manipolazione dei dati utilizzando l’Extensible Markup language (XML) e l’Extensible Stylesheet Language Transformations (XSLT)

• recupero dei dati in via asincrona utilizzando l’XMLHttpRequest

• Javascript come legame tra tutte le tecnologie appena elencate.

AJAX è uno stile di sviluppo che richiede un browser. L’interfaccia utente è modificata dinamicamente usando un linguaggio di programmazione che restituisce dati solo quando necessario, piuttosto che seguire l’approccio tradizionale che esegue un refresh dell’intera pagina quando la richiesta viene eseguita.

A livello di programmazione, AJAX e Javascript sono esempi di duck-typing e latent programming, e queste due tecniche li rendono capaci di eseguire codice in maniera dinamica e solo quando necessario.

Duck typed programming riguarda lo scrivere codice quando la definizione delle classi non è conosciuta prima del tempo, ma si sa che l’oggetto ha uno specifico comportamento.
I linguaggi classici di programmazione ad oggetti definiscono il comportamento dei tipi prima dell’esecuzione. Possiamo ad esempio guardare il codice che segue, che illustra l’essenza del duck typed programming.

[html]

[/html]

Quando il browser web esegue il codice, questo sarà parsato dall’alto verso il basso, seguendo questo schema:

1. definizione delle funzioni azione1, azione2 e RunAzione

2. instanziazione della variabile obj

3. definizione dei due pulsanti azione1 e azione2 che eseguono del codice javascript quando si clicca su di essi

4. definizione dell’elemento html div che identifica l’output..

Chiamare la funzione RunAzione genera un’eccezione, in quanto obj è un semplice oggetto per il quale non è stata definita nessuna implementazione del metodo runIt.

Un classico linguaggio di programmazione come C++, C#, o Java non riuscirebbe a compilare il codice qui sopra, poichè la funzione RunAzione esegue un metodo per un tipo al quale non è stato implementato quel metodo.

Quando il metodo di un oggetto è chiamato, stiamo usando la tecnica del latent typing (lett: “tipizzazione latente”).
Latent typing indica che l’associazione di un tipo ad una variabile avviene durante il run-time dell’applicazione; ciò vuol dire che non si conosce l’esatto comportamento di obj fino a quando l’applicazione non viene eseguita.

Un classico argomento usato per contrastare duck typing e latent programming, è che non si sa mai l’esatto comportamento del codice fino a quando non lo si esegue. Al contrario Java, C++ e .NET portano alla generazione di codice stabile e robusto. O perlomeno, questa è la teoria che porta avanti chi supporta lo static typing. Il problema però resta: con lo static typing si avrà del codice che compila senza problemi, ma il fatto che compili non garantisce la correttezza del codice stesso.

Un’altro argomento del supposto vantaggio nell’uso dello static typing, è dato da IntelliSense.
IntelliSense è una funzione che, digitato il nome di una variabile, ed eseguita una combinazione di tasti, riporta tutti i metodi, proprietà e strutture dati associate all’oggetto. Con IntelliSense puoi scrivere codice più velocemente, dato che non devi stare a pensare quanti parametri possiede un metodo, e così via.
Un problema da non ignorare su IntelliSense, è che spinge i programmatori a creare programmi con tecniche bottom-up. Tali tecniche sono richieste perchè IntelliSense non può funzionare se non sono stati definiti i tipi. Quindi, i programmi top-down sono diventati rari, dato che i programmatori sono costretti ad usare la tecnica opposta per sfruttare IntelliSense.

A questo punto, molti di voi si staranno chiedendo: perchè mai continuo a scrivere codice utilizzando linguaggi che mi portano a seguire delle convenzioni e mi impediscono di essere “libero”? La risposta è che tali linguaggi, con le loro IDE, creano un ambiente caldo e accogliente che mi porta a rilassarmi nell’idea che sto scrivendo codice che funziona.

La realtà è che ci sono casi in cui va bene procedere in questa direzione, e casi in cui bisogna essere più flessibili, a seconda dell’applicazione che si sta realizzando.

E’ importante realizzare che con AJAX hai la possibilità di creare contenuti e codice dinamico in maniera molto semplice e veloce, cosa che non puoi fare quando utilizzi altri linguaggi.

Fonti:
AJAX and REST Recipes
Adaptive Path