Archivio tag: ajax

Dion Almaer (ajaxian.com)- Hot to take your app offline

Pubblicato il da
Risposta

Dion parla di Google Gears, la tecnologia che permette di portare offline dati e applicazioni web.

Parte dalla considerazione che in Palo alto si perde la connettività molto spesso. Portare l’applicazione offline può eliminare delle barriere, ma non solo. Portare le elaborazioni offline permette anche di aumentare la performance per l’online.

A Google si sono chiesti come portare le applicazioni offline senza risovere semplicemente i problemi di Google stessa; per questo Google Gears è stato rilasciato come open source (new bsd).

La filosofia su cui si basa può essere così sintetizzata:

  • usare lo stesso URL per applicazione online e offline
  • la transizione la versione online e offline dell’applicazione deve essere trasparente
  • dev’essere possibile usare dati locali anche se si è online
  • dev’essere disponibile a tutti su tutte le piattaforme

Google Gears è qualcosa di più rispetto a Ajax, ma i concessi sono tra loro simili: si tratta di fare per le applicazioni offline quello che XMLHttpRequest fa le per applicazioni web (per questo è simile, come concezione, a Ajax).

I componenti:

  1. LocalServer: che gira nel browser
  2. Database: un database relazionale “fully-searchable”, non file di testo
  3. WorkerPool: possibilità di gestire thread indipendenti dal browser

Database

Il database è creato usando SQLite. Su questa base sono stati aggiunti dei livelli di astrazione successivi.

GearsORM: gestire relazione tra oggetti del database come fosse Hibernate.

GearShift: gestire la migrazione di tanti database negli utenti quando si fanno cambiamenti: db migration come il rails.

Local Server

E’ semplicemente un mini server web che ascolta sulla porta 200 e 304.

Worker Pool

Risponde alla necessità di avere diversi thread di processo separati dal browser, e sicuri. In questo modo il Javascript gira in background, non nel contesto del browser.

Altro

E’ stata scritta un’estensione per criptare i dati salvati nel client. E’ stato aggiunta la ricerca full-text.

Questo intervento è stato scritto in live blogging dalla conferenza Future of Web Apps di Londra, il 3 e 4 Ottobre 2007. Leggi tutti gli interventi di Fucinaweb dal FOWA

Ancora su Ajax e usabilità

Pubblicato il da
1

Anche le prime ore di vita di Google Calendar non sono state esaltanti. Ho perduto modifiche che ero convinto di aver salvato e soprattutto ero spaesato perché spesso non capivo se a una mia azione seguiva un riscontro del software.

L’ho già detto, e mi ripeto ancora una volta. La creazione di applicazioni basate su Ajax offre sicuramente delle nuove possibilità, ma pone anche delle nuove problematiche relative all’usabilità dei prodotti.

L’altro giorno nell’usare Google Calendar mi capitava di voler creare un nuovo evento, completarlo con alcuni dati, e solo dopo una trentina di secondi (quando oramai stavo facendo dell’altro) l’interfaccia mi informava che l’operazione non era andata a buon fine.

Mi chiedo poi se non stiamo utilizzando un po’ troppo pesantemente questo tipo di interfacce. Ci sono elementi in Google Calendar che effettivamente beneficiano di un’implementazione “ricca” (cioè usando Ajax), come ad esempio l’inserimento di un nuovo evento. Ma già quando si tratta di modificarlo successivamente, il fatto che il campo diventi editabile quando ci si muove sopra con il mouse è forse superfluo, oltre a trarre in inganno (ho passato 10 secondi a cercare un esplicito pulsante “edit”).

Speriamo sia solo l’esuberanza dei primi mesi, e che questo tipo di soluzioni maturi tanto da permettere di usarle solo dove hanno realmente senso.

Ajax in action

Pubblicato il da
Risposta

Il termine Ajax è stato coniato da un anno e non si sono fatti attendere i pesanti manuali che spiegano tutto, ma proprio tutto, su questa architettura.

Di Ajax in Action, pubblicato da Manning, ho fondamentalmente apprezzato il modo con cui sono affrontati, fin dalle prime pagine, gli argomenti.

Invece che cominciare a scrivere qualche banale Hello Word con Javascript gli autori hanno infatti preferito chiarire subito che sviluppare applicazioni Ajax è un compito che richiede competenze specifiche.

Per questo motivo si parla prima di tutto di refactoring, di come utilizzare il più possibile Javascript come linguaggio orientato agli oggetti, e di come utilizzare i pattern di sviluppo in soluzioni Ajax. Crane e soci insegnano cioè come partire con il piede giusto.

Imparare da subito questi concetti ripaga subito dopo, perché gli esempi presentati, anche se semplici, non sono mai banali, e consentono anzi di riflettere un bel po’ su come sviluppare nel modo corretto.

L’unico appunto che mi sento di fare (una nota più che un appunto), è che va bene capire come funziona l’architettura Ajax. Ma forse più che voler approfondire più di tanto quanto presentato nel testo, l’importante è capire che Ajax sarà presto integrato – come ho già detto – all’interno dei diversi framework di sviluppo.

Si spera che in questo modo da produttività nell’utilizzare questo tipo di soluzioni sia destinata ad aumentare sensibilmente.

Ajax in Action – di Dave Crane, Eric Pascarello, Darren James, pubblicato da Manning, 640 pagine

Ha senso imparare Ajax?

Pubblicato il da
3

Che in futuro la percentuale di applicazioni web di tipo Ajax (e Ria in generale) aumenti sempre più è un dato di fatto. Ma non è ancora chiaro chi, all’interno del team di sviluppo di un progetto web, debba imparare a masticare questa nuova architettura. Tutti? Solo chi si preoccupa della programmazione? Chi sviluppa i template? Il designer?

Chi progetta l’interfaccia

Uso qui impropriamente il termine “progettare l’interfaccia” intendendo in realtà molte specifiche professionalità, illustrate sapientemente da Jesse James Garrett nel diagramma “The Elements of User Experience“.

Chi rientra in questa categoria farebbe bene a capire come per l’utente cambia il modo di usare un sito che utilizzi Ajax. Perché le possibilità aumentano e l’interattività si avvicina a quella di un normale programma per computer. Per capire cosa intendo potete dare un’occhiata a quanto messo a disposizione da Yahoo!. Ma tutto questo pone anche dei problemi per quanto riguarda l’accessibilità e l’usabilità di Ajax.

Chi declina il template

La cosa più importante che deve fare chi si occupa del lavoro sporco, ovvero di convertire i template in codice Html e fogli di stile, è fare in modo che questi aderiscano il più possibile agli standard web. Non solo sulla carta, ma per davvero, come dico da due anni e passa.

Il fatto che Ajax impieghi massicciamente Javascript, realizzato solitamente da chi si occupa di produrre l’Html della pagina, potrebbe trarre in inganno. Si tratta infatti di un uso avanzato di Javascript, da lasciare a chi lavora lato server.

Chi scrive il codice lato server

Ecco, direte, quali sono i veri utilizzatori di Ajax, le persone che si infangano le mani tra codice Javascript e programmazione lato server…o no?

Certo, per capire come funziona Ajax suggerisco di creare da zero un piccolo esempio, ma è imprensabile sviluppare applicazioni complesse in questo modo.

Molto meglio votarsi a un framework che sollevi da questa responsabilità. Ma se possibile non un framework lato client, come ad esempio Prototype.

In futuro (neanche tanto lontano, basti pensare a quello che sta facendo, tra gli altri, Microsoft con Atlas), il supporto per Ajax sarà integrato direttamente all’interno dei framework di sviluppo lato server, tanto da renderne “invisibile” il funzionamento.

Attenzione però, perché trasparente fa rima con pericoloso. Dovrete prestare comunque attenzione a quello che fate; non dimenticatevi che siete sempre alle prese con un browser e – la maggior parte delle volte – con il protocollo Http.

Graceful Degradation o Progressive Enancement? Graded Browser Support

Pubblicato il da
Risposta

Nel sito di Yahoo! rivolto agli sviluppatori è possibile trovare un illuminante articolo, quasi un manifesto, che mi ha permesso di capire qual è la strategia di Yahoo! per quanto riguarda il supporto ai diversi tipi di browser, elemento importante specie in un periodo in cui un sito non sembra degno del nome se non include qualche effetto Ajax.

Yahoo! preferisce quello che definisce progressive enancement rispetto al graceful degradation. Con graceful degradation, secondo Yahoo!, si intende il processo di creazione della pagina che favorisce la presentazione al contenuto. In questo scenario si sviluppa il sito per i browser di ultima generazione, controllando che comunque i browser più obsoleti siano in qualche modo in grado di visualizzare la pagina. Progessive enancement è invece una metodologia che dà priorità al contenuto, così che come prima cosa si realizza il sito in modo che il contenuto sia accessibile alle diverse combinazioni di browser, per poi includere alcune funzionalità per i browser di ultima generazione.

Per fare questo Yahoo! suddivide i browser in 3 categorie (o “gradi” da qui graded browser support): nella prima include browser che sono in grado di interpretare solo Html (circa il 3% dei visitatori); nel verificare le pagine vengono presi in considerazione errori prodotti con questi browser. Nella seconda categoria troviamo invece i browser moderni, con pieno supporto agli standard (circa il 96% dei visitatori); anche in questo caso eventuali errori vengono subito verificati e corretti. Di un’ultima categoria fanno invece parte i browser “rari” o che manifestano problemi nel supporto agli standard; eventuali errori in questo caso non sono presi in considerazione. Qui troviamo anche i browser appena usciti sulla piazza, fermo restando che prima o poi finiranno con tutta probabilità nella lista dei browser moderni.

Indipendemente dal fatto che siate d’accordo o meno con le teorie di Yahoo! (io ancora un’idea precisa non ce l’ho), tornerà sicuramente comodo dare un’occhiata alle categorie di browser. Se siete sensibili al problema sono senza dubbio da visitare anche i link presenti in fondo all’articolo

.