Tra le varie librerie – o insieme di librerie (veri e propri framework), dedicate ad Ajax, estensione dell’interfaccia HTML e Web2.0 che mi è capitato di vedere, Ext è sicuramente degno di nota. Il sito Web e la documentazione sono ben fatti e organizzati, inoltre i demo online sono da non perdere. L’interfaccia grafica, la compatibilità con Prototype e Scriptaculous e l’impletazione dei Yahoo Utils, ne fanno un sistema quantomeno interessante! Attenzione però alla licenza! Nonostante si presenti come open source e gratuito, per usi personali, richiede un pagamento per potenziarne l’uso e l’assistenza. Quest’ultima, infatti, non è mai da sottovalutare in framework di una certa complessità.
In particolare cito questo sistema, che sto ancora analizzando in dettaglio, in quanto è stato utilizzato per creare Fresh Feed Reader, una delle applicazioni di esempio fornite con la versione Alpha di Adobe Apollo (vedi Adobe Apollo Alpha Release). Fresh, quindi, è un duplice esempio dell’uso di Apollo, che dimostra le sue capacità di sfruttare HTML e Javascript al massimo. Fresh, infatti, non è un’applicazione Apollo pura, ma usa il framework Ext- e quindi Javascript e HTML – all’interno del motore Apollo! Fantastico!!
Ecco un nuovo ed interessante tool per la compressione e l’oscuramento di codice Javascript (vedi anche Reverse Engineering: i compressori di codice).
Sul sito Web di Dean Edwards è possibile scaricare anche il codice sorgente Javascript di questo compressor. Inoltre l’autore ha reso disponibili le versioni server per Microsoft .NET Framework versione 1.1, Perl, WHS e PHP5.
Online è disponibile una versione funzionante da provare subito, meno complessa - a dire il vero - di quelle che avevo presentato tempo fa. Permette, infatti, di comprimere il codice con due sole scelte: il Base62 encode, che oscura il codice e il Shrink variables, l’ottimizzatore di variabili. Rispetto alla precedente versione sono stati risolti alcuni bachi che, in situazioni di hack estremi (e davvero interessanti) come:
1
var isMSIE =/*@cc_on!@*/false;
non rispettavano l’output generato. Ora sono correttamente supportati sia i conditional comments di Microsoft, sia gli operatori +/- in condizioni come:
Packed scripts should successfully unpack on all browsers that support JavaScript. Only basic JavaScript functionality is used to decode the packed script.
Some browsers may not support the packer itself. The web interface requires DOM support. Legacy browsers will display a disabled interface.
Quindi massima attenzione all’utenza finale e al tipo di browser da supportare… come sempre del resto!
In questo Post vorrei analizzare l’uso di script unobtrusive dal punto di vista del Web Designer. Normalmente, infatti, uno script non intrusivo è tale nei confronti del navigatore finale! Ma può esserlo anche per il Web Designer?
Unobtrusive Javascript dal punto di vista del Web Designer
Mettendoci nei panni di un Web Designer potremmo identificare due categorie di unobtrusive Javascript: true unobtrusive Javascript e pseudo unobtrusive Javascript.
Entrambe le categorie, tuttavia, non sono completamente non intrusive (sempre dal punto di vista del Web Designer). Un reale e completo unobtrusive Javascript non dovrebbe richiedere nessun intervento nella pagina Web, ma questo è – per ora – sostanzialmente impossibile. L’operazione minima richiesta durante l’installazione di uno script è comunque l’inserimento dell’inclusione dello script stesso! Viene dunque ammessa tale operazione che – effettivamente – non costringe il Web Designer ad apportare modifiche straordinarie alla struttura della pagina. Il semplice posizionamento dell’inclusione dello script all’interno del Tag head può essere quindi considerato non intrusivo.
Il true unobtrusive Javascript
Gli script di questo tipo sono quelli che richiedono la sola inclusione dello script unobtrusive e non ;pretendono nessun’altra operazione! Script di questo tipo sono, ad esempio (il solito e citatissimo), Snap. Una volta inserito il codice di inclusione il Web Designer non deve svolgere nessuna operazione ulteriore, in quanto lo script di Snap opera su Tag standard.
Gli pseudo unobtrusive Javascript
Questi si differenziano dai precedenti in quanto richiedono una taggatura ulteriore per funzionare correttamente. Esempi di questo tipo sono i Control.Tabs di Ryan Johnson o la libreria per gli slideshowLightbox JS. Quest’ultima soluzione, ad esempio, richiede l’inserimento nel Tag A dell’attributo rel per identificare i link che devono essere modificati. Lightbox JS, in particolare, richiede addirittura la presenza esplicita sia di Prototype che di Scriptaculous. Come indicato sul sito di Lightbox JS, l’inclusione dello script deve essere di questo tipo:
Inoltre per identificare un gruppo di immagini, per aggiungere la capacità di scorrere avanti e indietro le immagini, i Tag A devono essere impostati nel modo seguente:
La necessità di tali costrizioni risulta evidente; non esiste un modo semplice per distinguere un elemento link (Tag A) da un altro. In particolare non è possibile capire quale elemento il Web Designer vuole visualizzare in un modo o in un altro. Dev’essere necessariamente il Web Designer ad indicare in qualche modo i Tag e i loro comportamenti. Sono quindi richieste – intrusive – del tutto comprensibili, che non sminuiscono affatto l’utilità e le potenzialità di questi script. Comportano solo un dettaglio maggiore e qualche riga di codice in più al Web Designer.
È interessante, comunque, il doppio aspetto dell’unobtrusive Javascript, analizzato sia dal punto di vista dell’utente finale sia dal punto di vista Web Designer.
Visto che ne abbiamo parlato bene nei Post precedenti, è giunto il momento di parlarne male (scherzo), o quantomeno di evidenziare alcuni difetti della tecnica di unobtrusive Javascript. Se il codice unobtrusive Javascript viene eseguito quando la pagina è completamente caricata, ne deriva che maggiore sarà la quantità di dati (HTML) che forma la nostra pagina e maggiore sarà il tempo di attesa prima che il nostro codice venga eseguito.
Tutto ciò può tradursi in ritardi di esecuzione con un conseguente e fastidioso effetto di sfarfallio se si opera su elementi visivi della pagina. Prendiamo ad esempio il codice usato da Ryan Johnson per creare degli oggetti TabStrip. Se guardate attentamente il demo online vi accorgerete che per un secondo circa, al caricamento della pagina, si vede chiaramente un layout standard sostituito subito dopo da oggetti TabStrip. Ricaricando nuovamente la pagina, grazie alla cache del browser, il problema tende a diminuire (provate a pulire tutta la cache del browser per verificare i tempi).
Tutto questo ci deve far riflettere sui limiti di questa tecnica. Lo stesso Snap soffre esattamente dello stesso rallentamento, soprattutto in pagine spesso estremamente alte come quella di undolog.com. Caricando la home page di questo Blog risultà evidente che Snap viene eseguito qualche secondo dopo, ovvero quando la pagina è completamente caricata.
Per definizione dell’unobtrusive Javascript questo problema è difficilmente risolvibile a livello generale. Tuttavia nello sviluppo di un sito proprietario si possono prendere alcuni accorgimenti tesi a eliminare o ridurre tali difetti. Un modo abbastanza semplice è quello di creare una sorta di preload, elemento diffuso in ambiente Adobe Flash. Si può quindi impostare il Tag body – che contiene tutti gli elementi della pagina – in modo che risulti invisibile, lasciando al codice Javascript il compito di renderlo visibile quando ha terminato le – eventuali – modifiche al DOM:
Il codice unobtrusive Javascript, al termine delle sue operazioni:
1 2 3
document.getElementById("ibody").style.display=""; // Se usate prototype
$("ibody").style.display="";
Soluzione, tuttavia, banale e non sempre applicabile. Inoltre, anche se abbiamo in qualche modo risolto il problema del primo caricameno, navigare in un tal modo a lungo andare potrebbe davvero risultare fastidioso per i navigatori. Non essere intrusivi, quindi, ha un prezzo da pagare. Anche operando a livello di oggetto, per esempio impostando solo gli elementi interessanti in modalità nascosta, il fatto che il codice parta alla fine del caricamento dell’intera pagina porta inevitabilmente con sè le stesse identiche problematiche.
Come promesso ecco qualche esempio concreto di unobtrusive Javascript, strumento davvero potente e versatile se usato a dovere. Sul sito/Blog di Ryan Johnson è possibile scaricare due esempio davvero ottimi di unobtrusive Javascript:
Ryan Johnson, nei suoi script, fa uso della libreria Prototype, come molti del resto. Ha scritto anche alcune estensioni relativamente alla Prototype, poi introdotte – in forma diversa – nell’ultima versione della libreria. Usare Prototype per illustrare il funzionamento di codice unobtrusive Javascript è generalmente più comodo – come vedremo più avanti, tuttavia ecco un primo esempio grezzo che non richiede nessuna librerie esterna. Cominciamo ricordando che il concetto che sta alla base del unobtrusive Javascript è quello di partire da una qualsiasi pagina HTML (standard e non necessariamente scritta da noi – altro importantissimo punto di forza) e sfruttare Javascript per apportare alcune modifiche.
Schematimamente il concetto è quello di eseguire una funzione che analizza il codice HTML, attraversa quindi il DOM e in punti particolare aggiunge o modifica funzionalità. Normalmente si sfruttano due metodi per eseguire codice Javascript al caricamento di una pagina: il primo è quello che non racchiudere il codice in nessuna funzione e quindi lasciare che il browser esegua immediatamente il codice caricato nel punto in cui compare la chiamata:
Tuttavia quando si deve operare sul DOM di una pagina si presuppone che essa si a completamente caricata, cioè che tutti i TAG della pagina sia presenti e disponibili per essere rintracciati. Così la soluzione migliore diventa quella di essere sicuri che la pagina sia completa. Ciò è possibile agganciandosi all’evento onload del TAG body ad esempio, che viene rilasciato quando il caricamento della pagina è completo.
1 2 3
window.onload= miafunzione; // oppure, che è lo stesso
window.onload=function(){alert("Hello");}
Da evitare, ovviamente, la soluzione canonica che definirla intrusiva sarebbe un eufemismo:
Altra tecnica, più rozza e ugualmente intrusiva (in quanto costringerebbe l’utente finale a posizionare il codice in un punto particolare), è quella di inserire il nostro script alla fine del documento, prima della chiusura del Tag body; tecnica oramai obsoleta e usata in rari casi (vedi Google Analytics!).
Anche questo frammento di codice non è racchiuso in una funzione. Esso aggiungerà un event listener per l’evento load della finestra, richiamando la nostra funzione miafunzione(). I browser moderni, come FireFox ad esempio, useranno la funzione addEventListener() definita nella specifica DOM Level 2, mentre Internet Explorer userà la sua funzione proprietaria attachEvent(). Tuttavia non siamo ancora alla perfezione: in questa maniera, infatti, si rimpiazzeranno tutti gli – eventuali – eventi onload creati da altri script, il che non è proprio “non intrusivo”.
Per risolvere rapidamente la questione, che per via dei diversi comportamenti dei browser sarebbe quantomeno complicata da esporre qui, conviene usare libreirie come Prototype che forniscono un’elengantissimo metodo per superare il problema:
Al caricamento della pagina verrà mostrato prima l’alert “Hello 2″ e poi l’alert “Hello 1″. In pratica si carica in modo FILO (First Input Last Output) un stack, garantendo comunque l’esecuzione di tutti gli eventi agganciati al load del documento, esattamente quello che si voleva ottenere. In questo modo una pagina può caricare – virtualmente – infiniti unobtrusive Javascript che si agganciano alla load del documento.
Ma cosa si può fare con questa tecnica? Molte cose interessanti. Un esempio che possiamo commentare (vedi anche Prototype: l’uso del doppio dollaro ($$)) ci viene da Tobie Langel. Con poche righe di codice e scaricando le librerie Prototype e Scriptaculous si può dare un simpatico effetto ai classici anchor delle nostre pagine. Prima di tutto create una pagina HTML con il seguente codice:
Grazie all”uso di Event.observe() e alla funzione doppio-dollaro ($$) è possibile modificare in modo semplice il comportamento del classico anchor. In questo caso viene agganciata una nuova funzione al caricamento della pagina HTML. Quando scatta l’evento load vengono rintracciati nel DOM tutti i link (Tag <A>) con l’href che inizia con cancelletto (#, escludendo quello con solo cancelletto!). A questi elementi viene agganciata una funzione all’evento click, similmente a quanto fatto con la load del documento. A questo punto entra in gioco Scriptaculous che produce un effetto di scroll verso l’elemento punatato dal nostro link – modificato!
Permettere agli utenti di interagire con una pagina Web ha prodotto negli ultimi anni un notevole aumento nell’uso di script lato client: codice Javascript in grado di rispondere e manipolare in tempo reale tutta una serie di informazioni. Il Web2.0 è la massima espressione di questa capacità di interazione, dove l’utente finale – il navigatore -partecipa attivamente alla costruzione e all’evoluzione del sito Web, interagendo con esso e contribuendo personalmente. Si parla quindi di User-Generated Content (o UGC – contenuto generato dagli utenti) che vede il “navigatore” sicuramente meno passivo!
Per realizzare questa interazione, per permettere quindi all’utente finale di aggiungere il suo contributo, sono state sviluppate una serie di tecniche che hanno modificato l’aspetto e il comportamento delle pagine Web (statiche sino ad oggi, mentre adesso simili alle tradizionali applicazioni dei Desktop) negli ultimi anni. Modificare il contenuto di una pagina, inviare dei file, dare il proprio voto ad un video o a un documento, registrarsi o modificare i propri dati, sono solo alcune delle operazioni richeste in tanti servizi (2.0 beta) presenti sul Web.
Magnetk e Joyent hanno creato Slingshot, un tool che permette ad una applicazione Rails di funzionare offline! Contemporaneamente è stata rilasciata la Alpha 3 di Gran Paradiso, ovvero FireFox 3, anch’esso pronto a sfidare questa nuova frontiera dell’offline. Possiamo affermare senza esagerazione, almeno da quanto si legge sulla rete, che è iniziata una vera e propria competizione che vede schierati Adobe Apollo, FireFox 3 e nuovi contendenti come Slingshot.
Slingshot, tuttavia, si propone di far sviluppare (o portare) applicazioni Rails direttamente sul Desktop e di farle girare in modo “semplice e trasparente“;
Joyent Slingshot allows developers to deploy Rails applications that work the same online and offline (with synchronization) and with drag into and out of the application just like a standard desktop application.
Per una dimostrazione di Slingshot vedi il filmato Quicktime.
Non esiste, quindi, una vera e proprio diretta concorreza tra Slingshot e Apollo. Quest’ultimo, infatti, ha in definitiva un target diverso, come indicato da Wikipedia
“A cross-OS runtime that allows developers to employ their existing web development skills (Flash, Flex, HTML, Ajax) to build and deploy desktop Rich Internet Applications.”
Interessanti – invece - sono le caratteristiche di FireFox 3 (come gli Animated PNG – APNG), che si pone in maniera diversa dalle soluzioni sopra esposte.
La caratteristica che condividono i contendenti, quindi, è questa nuova tendenza a lavorare – o a permettere di lavorare – offline! È curioso che questo interesse sia esploso quasi all’improvviso, in un momento storico che vede la rete al centro di molti interessi. Inoltre, proprio in questi ultimi anni, la diffusione della banda larga ha portato gli utenti a rimanere continuamente connessi in rete, un cordone ombellicale impensabile sino a pochi anni fa; l’era del Dial-Up è ormai finita.
Proprio questa necessità di connessione perpetua ha dato il via alla generazione 2.0 (web2.0), al contributo sociale di tutti in quanto tutti connessi. L’offline è, nonstante tutto questo, un esigenza tecnica, non un cambio di tendenza. Probabilmente è di sicuro interesse poter investire su tecnologie di questo tipo. Il Wireless, molto probabilmente, dominerà nel prossimo futuro, ma a differenza di un cavo potrebbe essere maggiormente soggetto a improvvisi mancamenti (!
Poter lavorare sconnessi ha evidentemente tutta una serie di vantaggi che – come spesso accade – oggi non riusciamo nemmeno a vedere chiaramente.
Oramai è solo questione di tempo, Mozilla ha aperto la strada con Javascript 1.7. Comunque sia, è chiaro che l’attuale Javascript ha delle limitazioni. Per esempio non lo si può proteggere da un Reverse Engineering (vedi Reverse Engineering: i compressori di codice); possiamo rendere la vita difficile a chi vuole scrutare il nostro codice, ma impedirlo è quanto mai improbabile.
L’ECMA su cui è basato l’attuale Javascript lascia a desiderare. Chi viene da Java, C++ o ActioneScript 3.0, si trova notevolmente a disagio a trattare le variabili senza specificarne il tipo.
La struttura ad oggetti è anch’essa primitiva, con varie differenze di implementazione (che andranno ad aumentare) nelle diverse versioni dei browser. Librerie come Prototype sono state ideate proprio per superare alcuni limiti di estensione del DOM, oltre che implementare in modo efficiente e cross browser Ajax (XMLHttpRequest).
Consiglio, per mantenersi informati, di seguire l’evoluzione Mozilla/Adobe/ActionScript su: ECMAScript 4 Sulla documentazione di Javascript 1.7 vedi: New in JavaScript 1.7
Finalmente Adobe ha rilasciato la versione Alpha di Apollo. Siamo ancora lontani dalla versione finale, tuttavia è possibile verificare alcune delle sue funzionalità grazie ai Demo delle applicazioni (file .air) proposte online. L’installazione (Apollo runtime) di questa Alpha pesa circa 6Mb – per Windows. I Demo (Apollo sample applications) non arrivano a pesare nemmeno 600Kb. Dopo aver installato il runtime di Apollo nulla sembrerà cambiato sul vostro PC (non viene aggiunto nessun link sul desktop o sulla barra delle applicazioni), nonostante abbiate installato – di fatto – il nuovo browser di Adobe! Vedi Web2.0: Adobe ci prova con Apollo?
Scegliere la tecnologia da usare nello sviluppo di una Web Application è di vitale importanza, per non ritrovarsi nei guai subito dopo. Il tipo di Web Application, le sue caratteristiche di funzionamento, sono il primo punto da prendere in considerazione per poter scegliere il FrameWork e le tecnologie correlate.
Ho spesso discusso sull’efficacia di script Javascript nei confronti di tecnologie diverse come Adobe Flash o Java. Tuttavia è bene sottolineare un aspetto importante spesso sottovalutato: l’accesso al DOM. Javascript, in questo caso, è il candidato (per non dire il solo) prediletto per questo tipo di operazione.
Strumenti con Snap, ad esempio, funzionano su un semplicissimo meccanismo: quando la pagina HTML è caricata (e dopo aver inserito il caricamento dello script Javascript) viene eseguita una scansione della pagina HTML e aggiunto un nuovo codice in punti particolari. Nel caso specifico di Snap vengono identificati tutti i link a pagine esterne (o interne nella configurazione dell’ultimo rilascio), i TAG <A> per indenderci. Questi vengono modificati in modo tale che al passaggio del mouse si apra una finestra di anterpima del link (vedi questo stesso Blog per un esempio).
Non solo Snap ma molti altri script Javascript fanno praticamente la stessa cosa. Ultimamente questa tecnica si è largamente diffusa grazie alla libreria Prototype, che mette a disposizione tutta una serie di metodi (come il famoso $ o doppio-dollaro $$ – vedi Prototype: l’uso del doppio dollaro ($$)) sia per rintracciare che modificare – al volo – gli elementi di una pagina HTML.
Muoversi all’interno del DOM HTML è dunque compito specifico di Javascript. Storicamente, tra l’altro, Javascript fu introdotto proprio per leggere e scrivere i contenuti di una pagina HTML.
Se ad esempio volessimo fare alcune modifiche ad una pagina HTML tramite Adobe Flash, ci aggorgeremmo – o presto o tardi – di essere costretti ad invocare una funzione Javascript. Il nuovo ActionScript 3.0, ad esempio, mette a disposizione una classe (ExternalInterface) adatta a tale scopo. Una volta (nelle precedenti versioni di ActionScript) si usava il comando getURL() – oggi sostituita dalla migliore flash.net.navigateToURL() – o fscommad() per chiamare una funzione Javascript:
1
getURL("javascript:miaFunzione()");
Inoltre:
The ExternalInterface class is the External API, an application programming interface that enables straightforward communication between ActionScript and the Flash Player container; for example, an HTML page with JavaScript, or a desktop application with Flash Player embedded.
Notate quel “desktop application” che tanto ricorda Apollo!
Oggi, grazie a ExternalInterface, è possibile invocare una funzione Javascript in modo quantomeno più pulito (questa classe permette una gestione notevolmente più efficace rispetto a getURL(), come ad esempio il passaggio di parametri):
1 2 3 4 5 6
/* calls the external function "addNumbers"
passing two parameters, and assigning that function's result
to the variable "result" */ var param1:uint = 3; var param2:uint = 7; var result:uint = ExternalInterface.call("addNumbers", param1, param2);
1 2 3 4 5 6
<script><!-- // adds two numbers, and sends the result back to ActionScript function addNumbers(num1, num2){ return(num1 + num2); } // --></script>
Cosa possiamo concludere quindi? Tra tutti i vari framework e librerie disponibili l’analisi iniziale del progetto che si vuole realizzare rimane di fondamentale importanza. Sbagliare questa fase può compromettere seriamente le successive fasi di qualsiasi progetto Web2.0. Javascript, quindi, vince su tutti quando si deve interagire con il DOM.
Tra le varie librerie – o insieme di librerie (veri e propri framework), dedicate ad Ajax, estensione dell’interfaccia HTML e Web2.0 che mi è capitato di vedere, Ext è sicuramente degno di nota. Il sito Web e la documentazione sono ben fatti e organizzati, inoltre i demo online sono da non perdere. L’interfaccia grafica, la compatibilità con Prototype e Scriptaculous e l’impletazione dei Yahoo Utils, ne fanno un sistema quantomeno interessante! Attenzione però alla licenza! Nonostante si presenti come open source e gratuito, per usi personali, richiede un pagamento per potenziarne l’uso e l’assistenza. Quest’ultima, infatti, non è mai da sottovalutare in framework di una certa complessità. 
Magnetk
Finalmente Adobe ha rilasciato la 
Ultimi Commenti
Giovambattista Fazioli: @Nik: Sono contento! In bocca al lupo dunque!!
Nik: Lunedì ho l’esame di informatica su java, grazie mi sei stato utilissimo, il libro che ho era poco chiaro...
Marco: Ti ringrazio moltissimo, mi hai illuminato
ho risolto impostando [cc_objc] //OptionViewController.m -...
Giovambattista Fazioli: @Marco: Ti consiglio un approccio credo più corretto. Se hai eseguito il subclass del tab...
luigi: molto chiaro e semplice devo ammettere che anche scrivendo da un pà difficilmente uso delegati creati da...