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.
Il servizio XFruits, che uso su questo Blog per la versione in PDF, si arricchisce di un nuovo e interessante strumento: VocalFruit.
Ora i nostri feed rss possono essere ascoltati. Il nuovo servizio è disponibile per gli utenti registrati con un credito iniziale di 100 vocals. In realtà mi sono dovuto registrare nuovamente, piccolo mistero, tuttavia l’ho provato e funziona davvero bene. Probabilmente la scelta dei crediti dipende dal costo della tecnologia usata per lo speaker, quindi deduco che potrebbe presto diventare a pagamento! Sul sito le informazioni sono ancora relativamente poche, a dire il vero, ma l’idea sembra interessante.
Per adesso sono disponibili le lingue Inglese, Francese e Spagnolo, per l’Italiano temo si dovrà aspettare un po’ (al limite non lo faranno mai, come spesso accade). Le caratteristiche del servizio permettono di utilizzare la sintesi vocale generata, a partire dei feed rss, sul Web o sul nostro sito, sul cellulare o su un lettore MP3.
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.
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.
Con l’ultimo rilascio di Prototype, Andrew e Christophe hanno velocizzato e migliorato la funzione ‘doppio dollaro’ ($$ utility), la quale permette di selezionare un elemento specificando il selettore (praticamente tutti i selettori supportati dalle specifiche CSS3).
L’utilità di questa funzione va ben oltre la popolare $, che può essere utile ma, in fin dei conti, non svolge nessuna operazione degna di nota. L’utility ‘doppio dollaro’ ($$) invece permette davvero di selezionare qualsiasi tipo di elemento, fornendo ottimi strumenti per filtrare gli elementi nel DOM.
Vediamo alcuni esempi ripresi dal sito ufficiale:
1 2 3 4 5
$$('div');// -> Tutti i DIV del documento. Stessa cosa di document.getElementsByTagName('div')!
$$('#contents');// -> Uguale a $('contents'), ma ritorna sempre un array.
$$('li.faux');// -> Tutti fli elementi LI con class 'faux'
$$('#contents a[rel]');// -> Tutti i TAG A (links) al di sotto di un elemento con ID "contents" e con un attributo rel
$$('a[href="#"]');// -> Tutti i TAG A (links) con un'attributo href con valore "#" (eyeew!)
Il punto di forza, tuttavia, risiede nella possibilità di escludere alcuni elementi in favore di altri, ad esempio:
1
$$('a:not([rel~=nofollow])');// -> Tutti i TAG A (links), esclusi quelli che contengono un attributo rel impostato a "nofollow"
Ancora più interessante è:
1
$$('a[href^=#]:not([href=#])')
Questo, in pratica, trova tutti i TAG A con l’attributo href che inizia con ‘#’ ma non prende in considerazione quelli che sono uguali a ‘#’ solamente. In altre parole vengono ignorati i links che non puntato ad un valido ID!
Questa eccezionale caratteristica del ($$) ha ispirato Tobie Langel per creazione di un semplicissimo script (disarmante) in grado di aggiungere un simpatico effetto di scroll quando all’interno di una stessa pagina HTML ci si sposta per Anchors, con la tecnica – appunto – href=”#”.
Per un Demo clicca qui.
Papervision3D è un motore 3D estremamente performante per Adobe Flash 8 e 9. Le sue caratteristiche sono davvero impressionanti. Grazie all’estrema velocità di esecuzione di Flash sono stati possibili effetti di texture mapping davvero notevoli. Dal Blog ufficiale è possibile vedere le demo davvero eccezionali. Inoltre è disponibile un Videogame da provare.
Una questione trascurata nell’ambito del Web2.0 è la protezione del codice sorgente. In un ottica Open Source, dove il Web2.0 trova nella beta la sua massima espressione, condividere e far partecipare la comunità lascia sicuramente in secondo piano questioni legate alla protezione del codice sorgente. Ricordiamo, infatti, che gli script Javascript vengono scaricati all’interno del browser dal Web Server, come file testuali, quindi totalmente visibili all’utente finale. Mentre il codice Server è protetto per definizione (è impossibile accedere al codice di una pagina PHP tramite il protocollo HTTP del browser, salvo i rari casi di malfuzionamento del Web Server), il codice client potrebbe essere soggetto ad un Reverse Engineering.
Esiste tuttavia una semplice protezione ideata, ai suoi esordi, per dimuire la dimensioni degli script Javascript; oggi diventati veri e propri framework in alcuni casi. Esistono infatti applicativi e siti Web che permettono di comprimere (crunch) il codice Javascript, ma non solo. Questa caratteristica, in modalità diversa, può essere applicata anche al codice HTML e ai fogli di stile CSS. Il codice Javascript, in particolare, oltre ad essere compresso può essere nascosto, ottenendo così una protezione del codice (a vista) tale da rendere più articolata la procedura di Reverse Engineering.
Le differenze tra HTML, CSS e Javascript sono importanti e sostanziali. Mentre la compressione di pagine HTML e fogli di stile può solo agire sull’eliminazione di caratteri inutili o superflui, come ‘a capo’, ‘spazi doppi’, ecc…, Javascript è un linguaggio di programmazione che può quindi eseguire uno speciale codice per decomprimere se stesso.
JavascriptCompressor.com è un servizio gratuito, utilizzabile online, che permette di comprime un codice sorgente Javascript. Le opzioni lo rendono estremamente versatile, garantendo al contempo l’oscuramento del codice.
Ovviamente questo è un esempio, con codici piccoli comprimere non ha davvero molto senso, si rischi di peggiorare le cose e basta (a meno che non siate interessati esclusivamente all’oscuramento del codice a vista).
MemTronic Cruncher Compressor è anch’esso un servizio online (come il precedente funzionano anche in modalità offline) parzialmente gratuito, nel senso che alcune funzioni sono disponibili solo nella versione a pagamento (come la funzione Obfuscade). Rispetto al precedende servizio dovrebbe offrire maggiori prestazioni e sicurezza nel crittaggio del codice. Io li uso indistintamente, a seconda dei casi.
Peterbe.com non permette di comprimere Javascript (salvo che elimando spazi e ‘a capo’), ma propone un compressor per HTML, CSS e XHTML. Io, ad esempio, lo uso per comprimere i fogli di stili.
A meno di usare algoritmi particolari di crunching, che tuttavia appesantirebbero l’elaborazione dei dati, è sempre possibile eseguire un Reverse Engineering del codice, anche quello compresso. O presto o tardi, infatti, il codice originale deve essere inviato all’interprete del browser, il quale lo riconosce (per ora) solo in chiaro. In un futuro, con nuove versioni dei browser, questo impedimento potrebbe essere superato. Sarebbe infatti vantaggioso se venisse implementata, all’interno dei browser, una qualche tecnologia in grado di accettare codice Javascript pre-compilato, in binario per intenderci (caso mai crittato). In questo modo si abbatterebbero i tempi di download degli script, consentendo una naturale protezione dal Reverse Engineering e, non ultimo, maggior performance a livello di esecuzione degli script.
Xopus è un editor XML (HTML) in WYSIWYG mode funzionante all’interno del browser. L’avevo già notato qualche tempo fa, grazie ad un articolo uscito su Ajaxian. Ne parlo ora in quanto rimane un’interessante proposta nel panorama web2.0/editor. È un’esperienza interessante! Xopus è sviluppato davvero bene (con supporto italiano), con un’ottima implementazione del menu contestuale, anche se ancora non pienamente cross-browser; alla attuale release 3.1 è supportato solo Microsoft Internet Explorer (versione 6 e 7) tuttavia gli sviluppatori hanno promesso quanto prima una versione compatibile almeno con Firefox (il 1 febbraio è stata rilasciata in alpha la versione 3.1.1 compatibile in Firefox 2.0+).
Come già discusso altrove, la questione della compatibilità (il cross browser) attraverso i browser, rallenta e penalizza lo sviluppo di strumenti che, anche non ricorrendo a tecnologie particolari come Applet Java o Adobe Flash, potrebbero portare un notevole contributo alla Comunità! Conttibuto impedito – alla fine – dalle inutili lotte interne degli attuali produttori di browser: IE, Firefox, Opera, Mozilla, Safari, … !
Visionando i demo si intravede anche qualcosa in più del semplice editor HTML, per dirla in parola povere. Xopus propone infatti sia la struttura classica dell’editor, sia funzioni avanzate sullo stile di Microsoft Word. È possibile, infatti, inserire all’interno della pagina veri e propri oggetti intelligenti che rispondono a determinate caratteristiche, rendendo Xopus un caso particolare.
Come indicato sul sito:
Xopus is a good solution for any business that has a back-end content management system and a front-end publishing-system and therefore two systems which use the same information. To structure that information, to make both ends meet, is therefore a must.
Poete guardate il video dimostrativo che introduce le avanzate caratteristiche di editing. Inoltre potete provare direttamente una demo.
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...