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.
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
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.
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.
Visto che siamo in tema di nostalgia, ecco un simpatico emulatore dello storico microprocessore del 6502; montato negli anni ’80 in console e computer come l’Apple, Nintendo NS e il Commodore 64 (che poi passo al 6510, …). Questo simpatico gioiellino è scritto interamente in Javascript, funzionante in pratica su tutti i browser (da Safari a Opera), con il solo difetto di essere leggermente lento. Tuttavia vale la pena provarlo. Sul sito (http://www.6502asm.com/) trovate alcuni simpatici esempi, lenti ma curiosi.
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.
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...