Ajax in action

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?

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.

I migliori (o quasi) plugin per WordPress

Questo sito impiega WordPress, cioè un sistema di publishing per weblog, come piattaforma di gestione dei contenuti.

Worpress è sempre più usato non solo come software per pubblicare i propri weblog, ma anche per gestire veri e propri siti che non necessitano della complessità (o completezza) di un CMS.

E’ però inevitabile che, come per tutti i siti, anche in Fucinaweb le richieste di funzionalità aumentino. Grazie alla vastissima disponibilità di plugin, trovare qualche estensione di interesse non è troppo difficile.

Ecco allora una breve lista di plugin che ho scoperto in questi mesi e trovo particolarmente utili, oltre a utilizzarli spesso in questo sito. Non sono l’unico ad aver avuto questa idea, anzi, lo spunto per provare nuovi plugin è arrivata leggendo l’intervento Must-have WordPress plugins di Joe ‘Zonker’ Brockmeier.

  • Worpress Database Backup e Wp-cron – L’accoppiata vincente. Il primo vi permette di creare dei backup del database di WordPress direttamente dall’interfaccia di amministrazione. Il secondo rende l’operazione periodica, così potete salvare, o farvi mandare per posta ogni giorno, una copia di backup dei vostri dati (non è necessario un crontab installato sul server). Insostituibili
  • Category visibility – Un utile plugin se volete associare degli interventi a delle categorie, ma non volete che la categoria compaia nell’elenco proposto da WordPress nella spalla del vostro sito. Attenzione però all’impiego, a volte è meglio utilizzare opportuni tag (vedi prossimo plugin)
  • Jerome’s keywords – Volete far comparire in qualche punto del vostro intervento un elengo di tag in stile “web 2.0”? Questo plugin fa per voi. Attivatelo e nella schermata di inserimento degli interventi comparirà una nuova casella di testo, Keywords, che separete con delle virgole. A questo punto potete intervenire nei template e decidere di far comparire questo elenco come tag in fondo al post (potete guardare questo stesso articolo in Fucinaweb per capire cosa intendo) o anche nei meta tag nel codice sorgente della pagina. Infine, ma molto importante, verranno inseriti nel feed Rss del vostro sito degli opportuni tag per l’inclusione e categorizzazione in Technorati
  • Google Analytics – Se non volete inserire a mano il javascript di collegamento a Google Analytics, questo plugin fa per voi. Ma non è tutto. In un precedente intervento ho spiegato come Google Analytics possa essere utilizzato anche per tracciare i collegamenti verso siti esterni al nostro. Attivate il plugin e avrete anche questa comodità. Esiste in realtà un altro ottimo plugin che fa le stesse cose, anzi, sulla carta ben di più. Si tratta di WordPress Reports, un plugin che oltre a integrarsi con Google Analytics lo fa anche con Feedburner. Molto bella anche la parte di report integrata con WordPress. Ma questo prodotto manca ancora un po’ di maturità e il tracciamento di link esterni, per entrare nello specifico, non funziona troppo bene
  • Google Sitemaps – Un plugin che non può mancare e che automatizza il processo di creazione del file Xml utilizzato da Google Sitemaps (in passato ho parlato di Sitemap anche qui su Fucinaweb)
  • Feedburner feed replacement – WordPress già rende disponibili flussi Xml in diversi formati. Perché ricorrere a Feedburner, potreste chiedere. Per diversi motivi, di cui il principale è capire se qualcuno dei vostri lettori li sta utilizzando, e come…
  • Search and replace – Un’utility, pregevole soprattutto se vi trovate a dover sostituire massicciamente un testo nello storico dei vostri interventi. Da usare con opportuna cautela

Altri di meritevoli?