Oltre a servizi "semplici" come lettori di feed RSS, che consentono naturalmente di raggruppare in un solo posto notizie di qualsiasi sito di informazione serio, potete configurare widget per svolgere le funzioni più disparate, quali ad esempio mostrare gli ultimi messaggi di posta su (quasi) tutte le tipologie di account di posta possibili, le condizioni del tempo, il vostro calendario di Google e così via. In questo momento le widget esistenti sono 91733 .

Ma ne mancava una che mi serviva assolutamente e l'ho realizzata qualche giorno fa!

Avrete intuito che si tratta di una widget che interagisce col sito aNobii e che serve a mostrare i libri che possedete in numero variabile (a scelta, da 1 a 10) e presi tra diverse possibili categorie (tutti, quelli che state leggendo, quelli finiti e l'unione di questi ultimi due gruppi).

Le due possibili visualizzazioni che ho previsto consistono in una compatta (che avete già visto nella prima immagine) e un'altra più dettagliata che potete vedere in quest'altra immagine:

Ma la cosa più bella è che la tecnologia utilizzata per svilupparla ne rende possibile l'integrazione anche nei seguenti servizi web/applicativi:

• iGoogle
• Dashboard di Mac OS X
• Opera
• iPhone
• iPod touch
  
• Windows Live (beta)
• Windows Vista (beta)
• Yahoo! Widgets (a breve)

Fatemi sapere se la utilizzate, cosa ne pensate, se c'è qualcosa che non va o volete qualcosa in più .

Related posts:

1. aNobii WordPress Widget Mentre effettuavo il passaggio dal blog vecchio a questo mi...
2. Inviti per LLOOGG Cos'è LLOOGG? È un servizio molto semplice che viene descritto...
3. italia.it: Applicazione Pratica di XSS Innanzitutto, cos'è XSS? L'acronimo sta per "Cross-Site Scripting" (la X...

Dopo aver dedotto dalla documentazione e da alcuni plugin esistenti le "best practice" da seguire per scriverne uno, ma soprattutto dopo una discreta litigata con Javascript per interfacciarmi al sito aNobii, che, a quanto ne so, non fornisce API per uno scambio semplice di informazioni, è nato:

Cos'è aNobii?

È un servizio web che permette di crearsi una libreria virtuale (non nel senso di negozio) con i propri libri, creare gruppi o semplicemente parteciparvi, e conoscere gente simpatica e divertente .

A cosa serve?

Semplicemente consente di mostrare sul proprio sito basato sulla piattaforma WordPress una widget che mostra un numero variabile (da 1 a 10, a scelta dell'utente) di libri scelti a caso dal proprio scaffale su aNobii.

Cosa devo fare per utilizzarlo?

Non mi dilungo qui sul blog a spiegarvelo, poiché trovate tutto presso questa pagina. (l'ho scritto in inglese, ma mi auguro che uno che utilizzi WordPress conosca l'inglese ).

Related posts:

1. italia.it: Applicazione Pratica di XSS Innanzitutto, cos'è XSS? L'acronimo sta per "Cross-Site Scripting" (la X...
2. Google Patent Search Google sta spaziando ormai in qualsiasi direzione: ora ha sviluppato...
3. Un Fiore Tecnologico Quella che vedete nell'immagine (cliccate per ingrandire, ovviamente) è una...

Il logo di cui si parla, personalmente di stile obsoleto, in quanto ricorda elaboratori degli anni '80, ma svecchiato da gioiosi omini con le braccia sulle 10:10, è questo:

Per non parlare del fatto che mi ricorda abbastanza quello di Ubuntu

Senza entrare in dettagli complicati e di poco interesse per i non addetti ai lavori, certifica il fatto che il sito rispetti numerosi parametri che lo rendano conforme agli standard ed, in particolare, accessibile a persone diversamente abili (non vedenti, ipovedenti, daltonici, non udenti, disabili motori, ecc.).

Gran parte di questi parametri non può essere verificata in maniera automatica per svariati motivi, però alcune caratteristiche basilari sono, per loro stessa natura, validabili da strumenti automatizzati: in particolare la struttura sintattica della pagina e, in un secondo momento, i fogli di stile (CSS), che permettono di gestire la parte di presentazione delle informazioni contenute nella pagina stessa.

Per fare un paragone, è possibile controllare in modo automatico se un testo contiene solo vocaboli italiani, mentre è impossibile controllare con certezza, senza l'ausilio umano, se un testo ha una semantica coerente.

Visto che le caratteristiche verificabili in modo automatico sono oggettive, partirò da quelle (quando farò riferimenti a "requisiti" intendo quelli elencati in questa pagina):

• ho iniziato cliccando sul link in fondo all'articolo di Punto Informatico, quindi sono finito in questa pagina:
  • mi colpisce l'immagine nella sezione sinistra, quella con una specie di Wonder Woman ;
  • come faccio sempre con qualsiasi cosa possa essere un link, prima di cliccare, tengo il cursore sopra per vedere nella barra di stato il link e per osservare l'eventuale tooltip associato;
  • leggo il tooltip "portale urp (Questo link si apre in una nuova finestra)" e scoppio a ridere! Chi conosce anche solo l'XHTML 1.0 Strict, senza saper nulla di accessibilità, avrà già capito dove voglio andare a parare: per far aprire un link in una nuova pagina è necessario utilizzare l'attributo "target", violando le specifiche di XHTML 1.0 Strict, ovvero la specifica seguita per la costruzione del sito stesso. E ciò porta a violare il "Requisito 1": "Per tutti i siti di nuova realizzazione, utilizzare almeno la versione 4.01 dell' HTML o la versione 1.0 dell' XHTML, entrambe con DTD (Document Type Definition - Definizione del Tipo di Documento) di tipo Strict.". Inoltre contraddice l'affermazione "Tutte le pagine sono state validate con il Validatore del W3C (Validator W3C).";
  • per curiosità valido effettivamente la pagina e, magia, passa la validazione! Subito mi salta alla mente Javascript, ed infatti tramite Javascript viene aggiunto in un secondo momento l'attributo "target" a quei link per i quali l'attributo "rel" è impostato ad "external". In fase di validazione, naturalmente, non viene applicato Javascript, quindi l'imbroglio va a buon fine;
  • incidentalmente, guardando il resto del codice JS, vedo che anche la ricerca tramite il form di Google causa l'apertura di un'altra finestra;
  • mi potreste dire: "Il requisito è rispettato, la pagina è valida (staticamente) e l'effetto introdotto da quella porzione di codice Javascript è, in definitiva, utile". Per capire la gravità, pensate che mi sarebbe sufficiente creare una pagina che contenga unicamente il codice XHTML minimo necessario ad introdurre uno script Javascript per creare dinamicamente una pagina assolutamente valida staticamente e che contravvenga a qualsiasi regola.

• mi sposto nella pagina "Tasti d'accesso" e la valido. Un errore (il validatore segnala solo la prima occorrenza, ma si ripete per svariati link) proprio sull'attributo "target", che in questa pagina non viene aggiunto dinamicamente ma scritto direttamente nel codice XHTML. Qui non ci sono scuse che possano reggere ;
• vado alla pagina "22 Punti check-list". Stessa situazione del punto precedente, ma in un link differente;
• vado alla pagina dei "Credits" (che magari non dovrebbe chiamarsi così nella versione italiana del sito!) e la valido. Altre soddisfazioni: oltre al solito attributo "target", questa pagina presenta in svariati elementi gli attributi "align" e "border", aboliti nella versione XHTML Strict in quanto non appartengono allo strato di dati, ma di presentazione. Questo è un errore evidente, basilare e non giustificabile;
• ora basta con la validazione sintattica, sono già "contento" ! Passo a validare il CSS: questo si può fare semplicemente solo sull'"Homepage", supponendo che in un sito istituzionale non facciano la porcata di modificarlo dinamicamente in base alla pagina in cui ci si trova. Nessun errore, ma ben 243 warning. Chi ha un po' di dimestichezza con i CSS saprà che i warning solitamente sono ignorabili, ma a chi ha sentito parlare di accessibilità trilla un campanellino: possono essere indicatori di problemi.

Non essendo, per ora, particolarmente esperto di accessibilità, e richiedendo una valutazione estremamente lunga, sfrutto uno strumento automatico capace di valutare alcune caratteristiche sotanzialmente oggettive. Per semplicità l'ho provato solo sull'homepage ed effettivamente passa i test oggetivi: questo non vuol dire che sia accessibile, ma è un buon inizio . Per una verifica vera serve l'intervento dell'uomo e la consulenza di disabili, cose che, da quanto dichiarano, hanno fatto per ottenere il bollino.

Proseguo con un elenco di errori ed osservazioni (anche sull'accessiblità, dettate dal mio buon senso più che dalle conoscenze sul campo) sul sito stesso:

• nella pagina dell'"Accessibilità": un po' di rispetto per l'inventore del web! Si chiama Tim Berners-Lee e non Tim Barnes Lee; da cambiare il pusher di citazioni? ;
• nella pagina dei "Tasti d'accesso": prima vengono spiegate delle combinazioni che funzionano solo sotto Windows, poi viene spiegato come funzionano sotto Windows e sotto Mac; oltre alla ridondanza di informazioni (spiegare due volte come funzionano sotto Windows, la prima implicitamente, pensando che il mondo sia costituito da Windows-iani) non vedo perché non sia contemplato il sistema operativo Linux.
  Inoltre, negli esempi, viene indicato di premere Invio dopo la sequenza, cosa assolutamente inutile.
  Per finire, non esiste il tasto Crlt, ma il tasto Ctrl.
  Non sarebbe molto più chiaro e conciso definire prima le scorciatoie e poi indicare come utilizzarle in ciascun sistema operativo?
• la sezione che contiene i link per modificare la dimensione dei caratteri ed il contrasto tra testo e sfondo è presente solo nell'homepage e sparisce una volta che ci si muove in una qualsiasi altra pagina; immaginatevi di aver navigato un po' il sito, aver raggiunto dopo lunghe fatiche una pagina a lungo agognata ed avere la necessità di modificare qualche parametro: facile, grrr, dovete tornare all'homepage e poi ricercare la pagina precedente!!!
• i tre link che permettono di modificare la dimensione del testo hanno come contenuto testuale "A", che verrà letto da uno screen-reader ovviamente "A" in tutti e tre i casi, quindi un ipovedente dovrebbe andare ad intuizione/tentativi per capire cosa fa ciascuno di essi;
• la parola "Ambiente" per definire il "Contrasto" tra testo e colori è alquanto curiosa (mi ricorda più un suono che un qualcosa di visivo), così come sarebbe meglio sostituire "default" con parole più comuni ad un utente non informatico come "standard" o "normale";
• quando sparisce la sezione descritta precedentemente, appare al suo posto un'altra sezione che indica il percorso di navigazione, fondamentalmente una sorta di "Voi Siete Qui". Bene, utile, ma curiosamente funziona con un buon campione di pagine testate, tranne che con quella dell'"Accessibilità"!
• guardate in alto a destra: giustamente c'è un link che permette di visitare il sito in lingua inglese. È naturale pensare che, una volta cliccato, faccia sì che tutti i testi nella pagina vengano sostituiti con la corrispondente traduzione inglese. Naaa, sarebbe troppo scontato! Innanzitutto, se lo cliccate, la zona dei link in alto a destra sparisce magicamente, spaesando l'utente che si aspetterebbe di poter ritornare alla versione italiana. Cosa molto peggiore, si finisce in una pagina che non c'entra assolutamente nulla con l'homepage sulla quale ci si trovava e nella quale è tradotta solo una minima parte. Per completare il casino (per usare un tecnicismo), la navigazione delle pagine in inglese si sposta dal menu a sinistra (che rimane in italiano e porta a pagine in italiano) al menu a destra, che permette di raggiungere un numero estremamente scarno di pagine, cioè una sola. Credo che un non vedente, in particolare, troverebbe tutto ciò alquanto fastidioso;
• l'homepage presenta una caterva di link; chi utilizza uno screen-reader se ne deve sorbire davvero troppi prima di poter raggiungere quello che cerca. Se levassero, tanto per dire, il link "Lo Stemma e il Gonfalone" e lo inserissero nella pagina "La Storia della Provincia" ed accomunassero altri link in categorie più generali sarebbe tutto meno pesante da leggere;
• per finire, alcuni tasti di accesso rapido non funzionano con Firefox 2.0.0.3pre sotto Mac.

Credo di aver detto tutto ciò che mi è saltato all'occhio per ora, a voi la parola se scoprite altre cose succose
Se qualcuno si vuol dilettare gli propongo degli spunti da cui partire: accessibilità di form e di tabelle.

Nessun post attinente.

L'acronimo sta per "Cross-Site Scripting" (la X serve per evitare il conflitto con la sigla CSS, che indica tutt'altro).

È spiegato molto bene, in inglese, qui. Per i più pigri, diciamo che si tratta di inserire codice maligno, solitamente Javascript, in pagine create da altri utenti.

Ciò che si può fare è modificare qualsiasi informazione: nel mio caso le modifiche sono create appositamente in modo sufficientemente macroscopico per essere facilmente notate, ma un lavoro più "di fino" renderebbe i dati modificati assolutamente indistinguibili dagli altri.

Per spiegarvi come è possibile utilizzare in modo pratico questa falla di sicurezza vi propongo semplicemente dei link validi al sito. Se osservate gli URL vedrete che non è un mio sito modificato, ma proprio quello dell'Italia. Naturalmente quanto segue funziona solo al momento in cui è stato scritto questo e si spera che nell'immediato futuro la falla sia chiusa.

1. Primo link, provate a rispondere alla domanda proposta in entrambi i modi e, nel caso rimaniate sul sito, cercate di scovare le 4 modifiche presenti ; nel caso in cui non funzioni più il link si osservi la seguente immagine:
   

   

2. Secondo link, che rende il sito, come dire, più dinamico, se possibile, di quello che è (record personale di incisi in una frase così corta!). In questo caso, se non funzionasse il link, immaginatevi le immagini del sito che danzano per lo schermo.

Capirete quante altre porcate si possano fare e come si possa manipolare l'informazione. Quello che vi ho mostrato è più simpatico che dannoso, ma si fa presto a pensare ad un problema ben più grave: se ci fosse un form di login, sarebbe molto facile redirigere i dati inseriti dagli utenti (username e password) verso di me, attuando ciò che viene denominato phishing.

AGGIORNAMENTO: ieri hanno finalmente hanno corretto questo grossolano bug, comunque potete vedere sempre lo screenshot del primo link .

Nessun post attinente.

Chi conosce già AJAX può saltare la breve introduzione.

<INTRODUZIONE>

AJAX è un acronimo che significa Asynchronous Javascript And XML (ovvero Javascript asincrono ed XML) è ha fatto la sua comparsa il 18/02/2005 in un post di Jesse Garrett all'interno del blog.

Benché l'acronimo sia nuovo, non si tratta una nuova invenzione o di una nuova tecnologia, ma una modalità avanzata nell'utilizzo di Javascript per sviluppare applicativi client-side capaci di comunicare col lato server in modo veloce e soprattutto asincrono, in particolare senza la necessità di ricaricare interamente le pagine, ma semplicemente parti di esse.

Esempi celeberrimi dell'utilizzo di AJAX sono gli strumenti che Google mette a disposizione, quali Google Suggest, Gmail o Google Maps.

Nel 1998 Microsoft cominciò a sviluppare una tecnologia, chiamata Remote Scripting, che in pratica era molto simile ad AJAX, ma sotto altro nome. Tuttavia il successo si ebbe solo con il clamore suscitato dalle capacità degli applicativi sviluppati da Google in termini di accessibilità ed usabilità, caratteristiche non tenute in considerazione con tecnologie quali Flash ed Applets.

Per ulteriori informazioni rimando a questo link.

</INTRODUZIONE>

Come ho già accennato, lo scopo che mi ero preposto era di permettere all'utente che visitasse il mio sito web (http://gboccard.web.cs.unibo.it/) di modificare l'immagine di sfondo a suo piacimento, ma utilizzando un file presente sul proprio hard disk e non raggiungibile in alcun modo tramite un URL. La difficoltà risiede proprio in questa scelta, poiché con Javascript, per ovvi motivi di sicurezza, non si ha la possibilità di accedere a file presenti sull'hard disk dell'utente che visita la pagina web che non siano Cookie.

Quindi il primo passo è stato trovare un modo per poter inviare un file: la scelta è stata abbastanza ovvia ed obbligata, cioè l'utilizzo di un form come il seguente:

<form name="formChangeLogo" id="formChangeLogo" action= "http://gboccard.web.cs.unibo.it/cgi-bin/base64converter.php5" method="post" enctype="multipart/form-data">

Scegli un nuovo background:<input id="formChangeFile" name="file" type="file"><br />

<input name="submit" value="Muta!" type="submit" />

</form>

L'elemento input di tipo file è il classico pulsante con la scritta di default "Sfoglia..." o "Browse..." che permette di selezionare un file presente sul proprio file system. Ma cosa succede se si preme il pulsante input di tipo submit? Si causa l'invio del file all'URL indicato nell'attributo action dell'elemento form (di questo tratterò dopo) ma, purtroppo, anche il ricaricamento della pagina e questo è esattamente ciò che voglio evitare. La soluzione più ovvia, forse l'unica, che mi è venuta in mente è di introdurre il form all'interno di un iframe nascosto in modo tale che l'invio avvenga in modo trasparente all'utente e soprattutto senza la necessità di ricaricare la pagina. Quello che si ottiene è un iframe contenente il seguente codice:

<html>
<head></head>
<body>

<form name="formChangeLogo" id="formChangeLogo" action= "http://gboccard.web.cs.unibo.it/cgi-bin/base64converter.php5" method="post" enctype="multipart/form-data">

Scegli un nuovo background:<input id="formChangeFile" name="file" type="file"><br />

<input name="submit" value="Muta!" type="submit" />

</form>

</body>
</html>

Il problema del ricaricamento della pagina è risolto, ora resta da vedere come far sì che il client riceva il file che ha inviato al server, ovvero allo script PHP http://gboccard.web.cs.unibo.it/cgi-bin/base64converter.php5 (non visitate questo link, ha solo un senso nell'ottica di ricevere dati inviati in POST dal form descritto, ma http://gboccard.web.cs.unibo.it/base64converter.php5.txt). Qui entra in gioco lo script PHP, il quale rimanda al client lo stesso contenuto dell'iframe (cioè il form), in modo da poter essere utilizzato ancora, ma soprattutto:

• la versione convertita in base64 dell'immagine, in modo tale da poter essere embedded all'interno del codice Javascript, ottenuta tramite il comando base64_encode;
• una chiamata ad una funzione Javascript, in modo tale da causare automaticamente la modifica dell'immagine nel momento in cui la risposta giunge dal server al client.

Il codice che svolge tale funzione è, in particolare, il seguente:

$tmpName = $_FILES['file']['tmp_name']; // si riceve il file lato server
$fileSize = $_FILES['file']['size'];

$fp = fopen($tmpName, 'r');
$content = fread($fp, $fileSize); // si legge il file lato server

$embeddedPic=base64_encode($content); // si converte il file in base64

// si crea uno script Javascript che contiene nella variabile embeddedPic il file convertito in base64 e si crea una chiamata ad una funzione Javascript già presente lato client

$script = <<<END
<script>
var embeddedPic = "data:image/*;base64,$embeddedPic";
top.window.changeLogo(embeddedPic);
</script>
END;

// si invia lato client l'intero contenuto dell'iframe con l'aggiunta del codice Javascript appena creato

echo <<<END
<html>
<head>
$script
</head>

// segue il resto della pagina contenente l'iframe

END;

A questo punto il gioco è fatto: all'arrivo del codice generato lato server dallo script PHP, viene invocata la funzione Javascript changeLogo, già presente lato client che, nell'esempio che ho illustrato, non fa altro che modificare il background del body:

function changeLogo(base64image)
{
document.body.style.backgroundImage="url("+base64image+")";
}

Per concludere, faccio notare che il file inviato al server non viene in alcun modo salvato, ma solamente letto e rimandato al client. Questo evita di dover adottare delle politiche di cancellazione dei file inviati dagli utenti.

Mi piacerebbe avere dei pareri riguardo questa tecnica e, soprattutto, se esiste un modo meno macchinoso per ottenere lo stesso risultato, rispettando tutte le restrizioni che ho rilevato e illustrato.

Nessun post attinente.

http://gboccard.web.cs.unibo.it/chee.html

Provate a capire di cosa si tratta osservandolo e, se proprio non ce la fate, procedete cliccando sui vari indizi (hint), che ho ordinato in modo tale da condurre alla soluzione svelando parti sempre più chiare del "meccansimo".

Nessun post attinente.

Di per sè, questa estensione non fa altro che eseguire del codice Javascript contenuto in quelli che vengono definiti user script. Gli user script contengono un riferimento alle pagine web al caricamento delle quali deve essere eseguito il codice Javascript contenuto negli stessi.

Gli utilizzi classici possono essere:

• rimuovere annunci pubblicitari e/o popup;
• dare la possibilità di salvare video presenti su YouTube o Google Video;
• aggiungere o rimuovere caratteristiche legate all'accessibilità (come link per raggiungere più velocemente una pagina o rimuovere link mai utilizzati);
• modificare la struttura (layout) e la presentazione (skin) di una pagina a proprio piacimento;
• riempire automaticamente dei form;
• visitando un sito commerciale, dare la possibilità di vedere i prezzi degli stessi prodottti presenti su altri siti;
• ...e l'elenco può essere infinito.

I passi fondamentali da seguire per installare questa estensione sono descritti in modo molto user-friendly sul sito ufficiale http://greasemonkey.mozdev.org/, quindi non mi dilungo.

Piuttosto passerei ad analizzare lo scheletro di uno user script, utilizzando come esempio uno semplice che ho scritto per modificare il sito Repubblica.it reperibile all'indirizzo:

http://gboccard.web.cs.unibo.it/js/greasemonkey/repubblicaMOD.user.js

Innanzittuto, il nome dello script deve terminare con l'estensione ".user.js". Questo fa sì che, una volta installata l'extension, Firefox riconosca la natura dello script e aggiunga in alto a destra nella pagina un bottone (Install) che permette semplicemente di installare lo script.

La prima parte dello script contiene i metadati che descrivono lo script stesso:

// ==UserScript==
// @name Repubblica.it MOD
// @namespace http://gboccard.web.cs.unibo.it
// @description Alcune modifiche al sito Repubblica.it
// @include http://*.repubblica.it
// ==/UserScript==

Le differenti parti sono:

• il cosiddetto wrapper è la sezione che contiene tutti gli altri metadati; può essere introdotta in qualsiasi posizione sensata nello script, ma è buona norma metterla all'inizio; inoltre deve rispettare esattamente la seguente sintassi:

// ==UserScript==
// ...
// ==/UserScript==

• @name permette di indicare il nome dello script, così come verrà mostrato quando lo si installa o lo si gestisce in un'apposita finestra. Benché sia opzionale, è assolutamente consigliato specificare un nome, possibilmente corto, altrimenti di default viene utilizzato il nome del file privato dell'estensione ".user.js";
• @namespace consente di fornire un URL per differenziare script aventi lo stesso nome, ma creati da autori differenti. Nonostante sia opzionale, conviene specificarlo, altrimenti di default si assume quello del dominio da cui viene scaricato lo script;
• @description è una descrizione delle funzionalità dello script. Pur essendo opzionale, è buona norma inserirla per dar modo all'utente di capire la funzione che svolge lo script: non si può assumere che l'utente debba capire dal codice cosa è in grado di fare lo script;
• @include serve a specificare alla visita di quali siti deve essere eseguito lo script; per specificare più URL (senza l'uso di wildcard) bisogna ripetere il metadato su più righe; inoltre, è possibile utilizzare la wildcard "*" per indicare un match con una qualsiasi sequenza di caratteri (anche nulla): ad esempio, http://*.repubblica.it fa match con tutte le pagine aventi un URL che inizia con "http://", che prosegue con una qualsiasi sequanza di caratteri (quindi, ad esempio, www, multimedia, finanza, ecc.) e che termina con la stringa ".repubblica.it". Anche questo metadato è opzionale, ma se non lo si mette assume di default il valore "*", causando l'esecuzione dello script su tutti i siti;
• @exclude utilizza la stessa sintassi di @include, ma serve, come dice il nome, ad escludere uno o più siti dall'esecuzione dello script.

La parte restante dello script non è altro che codice Javascript con l'aggiunta di nuove API introdotte da Greasemonkey, che facilitano alcune operazioni comuni.

Per chi è alle prime armi con Javascript, una riflessione fondamentale: gli user script vengono eseguiti mentre viene caricata la pagina, quindi non è detto necessariamente che tutti gli elementi su cui compiono le operazioni per cui sono scritti siano presenti nella pagina nel momento dell'esecuzione. Questo naturalmente causa il malfunzionamento dello user script stesso. Il problema si risolve semplicemente associando all'evento onload della pagina una chiamata a funzione: tale funzione verrà invocata solamente quando l'intera pagina è stata caricata completamente. Per fare ciò consiglio di utilizzare questa funzione (utilizzabile anche in altri contesti, poiché cross-browser):

function addEvent(obj, evType, fn){
   if(obj.addEventListener)
       obj.addEventListener(evType, fn, false);
   else if(document.addEventListener && obj == window)
       document.addEventListener(evType, fn, false);
   else {
       if(!obj[evType]) obj[evType] = new Array;
       if(!obj[fn]) obj[fn] = fn;
       obj[evType][obj[evType].length] = obj[fn];
       obj["on" + evType] = function(){
           for(var i = 0; i < obj[evType].length; i++){
               obj[obj[evType][i]](window.event);
           }
       };
   }
}

Come si può veder dal mio user script di esempio, tale funzione viene invocata così:

addEvent(window, "load", jackallOnLoad);

e l'unico parametro da modificare per i propri scopi è il terzo, che deve essere il nome della funzione da invocare quando la pagina è completamente caricata.

Per chi non avesse intuito cosa fa il mio user script, le azioni sono semplici, ovvero si limita a centrare il contenuto della pagina principale del sito:

document.getElementsByTagName("body")[0].
     getElementsByTagName("table")[0].style.margin="auto";

e modificare il logo principale in tutte le pagine che lo contengono:

document.getElementById("brand").
     getElementsByTagName("img")[0].src=newLogo;

Per chi fosse curioso, quella roba strana assegnata alla variabile newLogo è una immagine jpeg convertita in base64, in modo da poter essere embedded nel codice Javascript.

Uno script carino e più utile è questo:

http://gboccard.web.cs.unibo.it/js/greasemonkey/googleX.user.js

viene applicato alle pagine di Google e sostituisce la barra contenente i radio button Web, Immagini, Gruppi, ecc. con una barra stile Mac:

Non è una mia idea, ma ho speso un po' di tempo per adattare la versione che avevo trovato per farla funzionare con le nuove pagine di Google. Sicuramente da provare.

Eccovi una linkografia dei siti più o meno strettamenti correlati all'argomento:

• http://greasemonkey.mozdev.org/: sito ufficiale dell'extension Greasemonkey;
• http://userscripts.org/: sito di riferimento in cui vengono raccolti gli user script;
• http://dunck.us/collab/GreaseMonkeyUserScriptsSpecific: sito in cui gli script sono divisi in base al sito web cui si applicano;
• http://dunck.us/collab/GreaseMonkeyUserScriptsGeneric: come sopra, ma si tratta di script di carattere generale, applicabili a più siti;
• http://diveintogreasemonkey.org/: la migliore risorsa per chi vuole imparare a scrivere user script.

Nessun post attinente.