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.
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.
Come avrete notato ho dato qualche ripulita al Blog, sia a livello grafico che a livello di strumenti e Plugin. Dato che Snap ha recentemente aggiunto alcune configurazioni, ho eliminato l’anteprima direttamente dal link! Per ottenere l’anteprima bisogna passare con il mouse sopra l’iconcina snap che appare in alto a destra. Inoltre ho impostato l’anteprima in modalità “large”, così si vede meglio!
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.
Magnetk
Finalmente Adobe ha rilasciato la 
Ultimi Commenti
Giovambattista Fazioli: @kOoLiNuS: Tranquillo, ti posso anticipare che probabilmente WPX cleanfix sarà gratuito, e...
kOoLiNuS: @kOoLiNuS: mancava un
e un 
kOoLiNuS: @Giovambattista Fazioli: mi sono iscritto, ma al momento io mio è un uso amatoriale della piattaforma...
Giovambattista Fazioli: @kOoLiNuS: Si, questo è un problema noto. Si verifica quando le tabelle in questione sono di...
kOoLiNuS: @Giovambattista Fazioli: Grazie per la patch! Però ho rilevato che su un paio di tabelle (se serve ti dico...