La soluzione proposta consiste nel definire due o più gruppi di colonne assegnando varie classi (Es: essential, optional, etc..) quindi utilizzare delle media-query CSS per visualizzare e nascondere gruppi di colonne in base alle dimensioni del display.

Si tratta dunque di un esempio di design responsivo.

Trovando la soluzione molto interessante ho costruito un plugin jQuery che rende estremamente semplice realizzare sulle proprie pagine web quanto spiegato nell’articolo.

>>> Vai alla demo! <<<

MediaTable in Azione:

In questo primo screenshoot vediamo una tabella di cui sono visualizzate solamente le colonne veramente importanti. Siamo su di uno schermo di piccole dimensioni!

Cliccando sul menu “columns” (il cui nome è configurabile) si apre un menu contenente l’elenco completo delle colonne disponibili nella tabella. Possiamo variare a piacere il numero di colonne visualizzate mettendo in relazione informazioni differenti.

Questo menu è generato automaticamente! Il sorgente di questo esempio, come spiegato successivamente, è una semplice tabella dati HTML!

>>> Vai alla demo! <<<

Come si usa MediaTable?

MediaTable richiede la definizione di una tabella HTML definita correttamente ovvero con THEAD e TBODY. Le colonne di intestazione vanno raggruppate per classe in base alla priorità di visualizzazione.

Via CSS si imposteranno dei breakpoint su cui definire quali gruppi di colonne visualizzare.
Il plugin costruisce inoltre un menu delle colonne disponibili per consentire una selezione manuale esplicita delle colonne da visualizzare.

Il nostro esempio utilizza 3 gruppi di colonne:

• essential – visibili su qualunque schermo
• optional – visibili dai 768px (iPad portrait)
• n/a – visibili dai 1024px (iPad landscape)

Un’ulteriore classe “persist” è utilizzata per identificare colonne che non sono gestite dal menu. Impostando una colonna con le classi essential e persist essa non potrà mai essere nascosta!

<table class="mediaTable">
<thead>
<tr>
<th class="essential persist">Employee</th>
<th class="essential">xHTML</th>
<th class="optional">HTML5</th>
<th class="essential">CSS</th>
<th class="essential">JS</th>
<th class="optional">jQuery</th>
<th class="optional">jQueryUI</th>
<th>jQuery Mobile</th>
<th>Sencha Touch</th>
<th class="essential">PHP</th>
<th>PHP (OO)</th>
<th class="optional">CakePHP</th>
</tr>
</thead>
<tbody>
<tr>
<td>Marco Pegoraro</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
</tr>
<tr>
....
</tr>
</tbody>
</table>

Il codice javascript per l’inizializzazione del plugin è estremamente semplice:

0

$('.mediaTable').mediaTable();

Tutte le tabelle aventi classe “mediaTable” verranno attivate per consentire la selezione dei campi ed il comportamento responsivo rispetto alle dimensioni dello schermo.

>>> Vai alla demo! <<<

Compatibilità:

Ho testato il plugin sui seguenti sistemi:

• Mac OsX, Firefox 9.0.1
• Mac OsX, Firefox 4.0
• Mac OsX, Chrome 16
• Mac OsX, Safari 5.1.2
• Windows7, IE9
• Windows7, IE8, IE7, IE6 (with respond.js for media-query)
• Windows7, Firefox 7.0.9

Fork on GitHub:

Il plugin è di libera distribuzione!

Link al progetto pubblico su GitHub!

Segnala presso:

Qualunque tipo di funzione/effetto e/o trasformazione del DOM di una pagina web può essere incorporata in un plugin jQuery con lo scopo di migliorare l’organizzazione del proprio codice Javascript.
Invece di un’accozzaglia di istruzioni generiche avremo il riferimento ad un set ordinato di plugins.

http://jsbin.com/apojah/14/edit/

Wrapper jQuery:

Il primo accorgimento utile è incorporare il codice del plugin in un oggetto wrapper il cui scopo è duplice:

1. isolare il codice del plugin dallo spazio degli script della pagina
2. utilizzare $ come riferimento interno a jQuery in modo sicuro

0
1
2

;(function($){
... qui va il codice del plugin ...
})(jQuery);

Tutte le variabili dichiarate mediante la sintassi “var” saranno locali al plugin mentre rimane possibile accedere a variabili globali dichiarate esternamente.

Passare la variabile “jQuery” al wrapper rende possibile l’utilizzo della funzione $ tipica di jQuery all’interno del codice del nostro plugin anche in presenza di altri framework esterni (es MooTools).

Struttura base del plugin:

Un plugin è un’estensione di jQuery che agisce su di un contesto formato da un elenco di nodi DOM identificati da una query xPath.

$('p').hide();

La precedente istruzione identifica un elenco di nodi DOM composto da tutti i paragrafi (p) presenti nel documento HTML e passa tale contesto alla funzione hide() di jQuery. Tale funzione restituisce il contesto stesso rendendo possibile la concatenazione di più plugins:

$('p').hide().fadeIn();

Per questo motivo il codice base del nostro plugin sarà:

0
1
2
3
4
5
6
7
8

$.fn.customPlugin = function() {
 
  $(this).each(function(){
    ... azioni sul singolo elemento DOM ...
  });  
 
  return this;
 
};

Viene eseguito un ciclo applicando una funzione ad ogni elemento del contesto. Successivamente il plugin restituisce il contesto stesso per consentire la concatenazione dei plugins come accennato sopra.

Ottimizziamo il ciclo sul contesto:

E’ importante capire che in Javascript ogni function() è trattata come un oggetto.
Il codice di questo esempio, seppur molto diffuso, crea un nuovo oggetto per ogni elemento di contesto quindi incide significativamente sulla memoria e sulla prestazioni del plugin stesso.

Possiamo ottimizzare il tutto spostando la logica applicata al singolo elemento in una funzione esterna locale al wrapper del plugin:

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

;(function($){
 
  /**
   * Metodo locale utilizzato dal plugin jQuery sugli elementi DOM
   *
   */
  var __loop = function() {
 
    $(this).fadeOut().fadeIn();
 
  };
 
  /**
   * Plugin - Estensione jQuery
   */
  $.fn.customPlugin = function() {
 
    // Applico la logica agli elementi del contesto (DOM)
    $(this).each(__loop);
 
    // Mantengo la possibilità di concatenare plugins.
    return this;
 
  }; // EndOf: "customPlugin()" ###
 
})(jQuery);

In riga #19 applichiamo la funzione __fn() che è definita esterna al plugin ma localmente al wrapper creato. In questo modo Javascript utilizzerà sempre il medesimo oggetto passando di volta in volta dati differenti.

Questo concetto è estremamente importante in quanto con jQuery è utilizzo comune passare nuove funzioni come parametri di metodi applicati ad elementi DOM. Aver cura di definire tali funzioni (solitamente callback) in modo esplicito nel wrapper del plugin è fondamentale per migliorare le prestazioni del nostro codice.

Configurazione del Plugin:

Praticamente il 100% dei plugins jQuery utilizzano il primo parametro passato come oggetto di configurazione interna.

0
1
2
3

$('p').customPlugin({
speed:'fast',
color:'red'
});

Una configurazione classica consiste in un oggetto le cui proprietà sono utilizzate dalla logica interna al plugin stesso per personalizzare le funzionalità erogate secondo diverse esigenze.

L’utilizzo di un oggetto di configurazione fa nascere alcune problematiche di organizzazione del codice quali:

• necessità di applicare dei valori di default per opzioni non rese esplicite
• necessità di passare l’oggetto di configurazione alla funzione __loop()

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

$.fn.customPlugin = function() {
 
  // Proprietà di configurazione interna.
  var cfg = false;
 
  // Estendo la proprietà di configurazione con l'oggetto di
  // configurazione contenuto nel primo parametro del plugin.
  if ( !arguments.length || $.isPlainObject(arguments[0]) ) {
 
    cfg = $.extend({},{
      color: 'black'
    },arguments[0]);
 
  }
 
  // Applico la logica agli elementi del contesto (DOM)
  $(this).each(function(){ __loop.call( this, cfg ); });
 
  // Mantengo la possibilità di concatenare plugins.
  return this;
 
};

Come prima cosa si noti l’aggiunta di una proprietà locale al plugin cfg la quale è instanziata a false e successivamente estesa da un oggetto contenente la configurazione di default del plugin stesso. (riga #3 -> #13)

La configurazione è contenuta nel primo parametro tra quelli passati al plugin, inoltre il valore di cfg viene modificato solamente se tale parametro è un oggetto. Questo condizionale è la base di una semplice tecnica per utilizzare il medesimo plugin con tipi di input differenti come avviene in quasi tutti i widget di jQuery UI.

$('#foo').dialog({ .. config .. }).dialog('open');

Utilizziamo le Closures:

Anche la riga #16 è cambiata: abbiamo dovuto aggiungere una closure per consentire il passaggio della configurazione alla funzione locale __loop().

L’utilizzo della closure è un compromesso di ottimizzazione.

Cerchiamo di isolare tutta la logica possibile in una funzione esterna che verrà invocata con parametri diversi dal codice interno alla closure. La closure verrà invece creata per ogni elemento DOM del contesto causando un leggero spreco di memoria.

Mantenere essenziale il codice delle closure demandando tutta la logica a funzioni esterne è importantissimo per garantire buone performance al nostro codice!

Rispondere a diversi tipi di input:

Abbiamo accennato a jQueryUI ed a come metta a disposizione una serie di widget la cui caratteristica comune è erogare comportamenti diversi in base a tipi di chiamate diverse:

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

(function($){
 
  /**
   * Logic methods
   */
 
  var __loop = function( cfg ) {
 
    $(this).data( 'customPlugin', cfg );
 
  };
 
  var __colorize = function() {
 
    var cfg = $(this).data('customPlugin');
 
    $(this).css( 'background-color', cfg.color );
 
  };
 
  /**
   * Plugin - Estensione jQuery
   */
  $.fn.customPlugin = function() {
 
    // Proprietà di configurazione interna.
    var cfg = false;
 
    // Estendo la proprietà di configurazione con l'oggetto di
    // configurazione contenuto nel primo parametro del plugin.
    if ( !arguments.length || $.isPlainObject(arguments[0]) ) {
 
      cfg = $.extend({},{
        color: 'black'
      },arguments[0]);
 
    }
 
    // Inizializzazione Plugin:
    // Applico la logica agli elementi del contesto (DOM)
    if ( cfg !== false ) {
      $(this).each(function(){ __loop.call( this, cfg ); });
 
    // Azioni su plugin intanziato:
    } else if ( arguments.length ) {
 
      switch ( arguments[0] ) {
 
        case 'colorize':
          $(this).each(function(){ __colorize.call( this ); });
          break;
 
      }
 
    }
 
    // Mantengo la possibilità di concatenare plugins.
    return this;
 
  }; // EndOf: "customPlugin()" ###
 
})(jQuery);
 
/**
 * Codice eseguito al caricamento della pagina
 */
$(document).ready(function(){
 
  // Inizializzazione del plugin
  $('p').customPlugin({
    color:'red'
  });
 
  // Esempio di utilizzo delle azioni del plugin
  $('input').click(function(){
 
    $('p').customPlugin('colorize');
 
  });
 
});

In questo esempio applichiamo il nostro plugin a tutti paragrafi (p) del documento (riga #69). Questa operazione andrà ad attivare il metodo locale __loop() la cui logica è salvare la configurazione del plugin all’interno del DOM del nodo interessato.

Successivamente sfruttiamo il click su di un bottone per invocare il metodo “colorize” del plugin stesso. In questo caso entra in scena il metodo local __colorize(). Questo è reso possibile dal controllo sul tipo di dato effettuato sul primo parametro passato al plugin. Rispettivamente in riga #30 e poi in riga #46.

Seguendo la struttura esposta nell’articolo il codice del plugin è diviso in due macro sezioni: un “router” di azioni ed un certo numero di metodi interni.

Il router è gestito nella funzione che estende jQuery. Controlla il tipo di input e si occupa di stabile che tipo di azione è richiesta.

I metodi interni si occupano di dar seguito alla decisione del router e devono “fare la magia”. Solitamente i metodi interni sono invocati per ogni elemento DOM identificato dal contesto del plugin come nei precedenti esempi.

Il passo successivo è massimizzare l’ottimizzazione dei metodi interni!

Ottimizzare con le Variabili Cache:

Ogni metodo locale di logica riceve come contesto il riferimento ad un preciso nodo DOM facente parte dell’xPath su cui è stato lanciato il plugin. Nel nostro esempio significa che il codice $(this) all’interno dei metodi __loop() o __colorize() è il riferimento ad un singolo paragrafo.

Sempre all’interno di questi metodi potremo aver bisogno di effettuare nuove ricerche su nodi:

$(this).find('strong')

a cui applicare vari metodi jQuery oppure altri plugin a cascata.

Ogni volta che si utilizza jQuery per effettuare una ricerca viene impegnata memoria e CPU. Noi possiamo agire e salvare i risultati di una query in una variabile locale così da alleggerire il carico del computer client. Vediamo il codice di __colorize():

0
1
2
3
4
5
6
7
8

var __colorize = function() {
 
  var $this = $(this);
 
  var cfg = $this.data('customPlugin');
 
  $this.css( 'background-color', cfg.color );
 
};

In riga #2 viene creata la variabile locale $this con riferimento al nodo DOM.
Nelle righe #4 e #6 riutilizziamo questa variabile per applicare metodi jQuery.

Questo è ovviamente un esempio banale ma possiamo immaginare l’impatto positivo di questo accorgimento quando la logica comincia a complicarsi un po’!

Conclusioni:

In questo articolo abbiamo raccolto le basi per la costruzione di un plugin jQuery versatile e prestazionale.

Grazie a questa struttura diventa semplice realizzare strumenti complessi che contengano configurazione e azioni.

Nel prossimo articolo studiamo in dettaglio alcune linee guida utili alla realizzazione di un “widget” ovvero un plugin complesso che mette a disposizione un controllo di interfaccia facilmente riutilizzabile in progetti differenti.

Al momento in cui scrivo il progetto di “widget collection” jQuery più affermato è sicuramente jQueryUI il quale mette a disposizione controlli di interfaccia evoluti quali dialog window, date picker, sortable list, etc.

Noi impareremo a creare componenti “custom” il cui utilizzo sia però ispirato alle linee guida di jQueryUI, fino ad arrivare alla creazione di nuovi widget completamente compatibili con jQueryUI e le sue linee guida.

Segnala presso:

$('#target').imagesLoaded(function(){
  alert("All images in #target were loaded!");
});

E’ anche possibile gestire una configurazione più dettagliata impostando callback di successo e di errore, quest’ultima lanciata nel caso una o più immagini non siano correttamente caricate nel tempo di timeout impostato:

$('#target').imagesLoaded({
  success: function(){ alert('Ok!'); },
  error: function() { alert('Ko!')); },
  timeout: 1000,
});

Nel precedente codice di esempio è impostato il timeout ovvero il tempo massimo di durata del controllo e le callback personalizzate in caso di successo o di fallimento del controllo. Le funzioni di callback ricevono come contesto il riferimento a $(‘#target’);

Fork on GitHub!

https://github.com/thepeg/ImagesLoaded

Segnala presso:

Source code on GitHub!
https://github.com/thepeg/AutoFancybox

Di seguito un esempio di codice Javascript di inizializzazione (1 riga!) ed un esempio di HTML che permette di lanciare un IFRAME in lightbox.

// Document onReady()
$('.auto-fancybox').autoFancybox();

<!-- Inside your document -->
<a href="http://goo.gl/VgLDo" title="Lavora con me!"
  class="auto-fancybox"
  data-type="iframe"
  data-width="90%"
  data-height="90%"
>Lavora con me!</a>

Opzioni Supportate

Il plugin supporta quasi tutte le opzioni ufficiali di FancyBOX. Trattandosi di attributi HTML5 i nomi sono scritti completamente in minuscolo quindi l’opzione di configurazione “showTitle” diventa l’attributo “data-showtitle”.

• padding
• margin
• opacity
• modal
• cyclic
• scrolling
• width
• height
• autoscale
• autodimensions
• centeronscroll
• ajax
• swf
• hideonoverlayclick
• hideoncontentclick
• overlayshow
• overlayopacity
• overlaycolor
• titleshow
• titleposition
• titleformat
• transitionin
• transitionout
• speedin
• speedout
• changespeed
• changefade
• easingin
• easingout
• showclosebutton
• shownavarrows
• enableescapebutton
• type
• href
• title
• content
• index

Segnala presso:

Inizialmente ho letto parecchie discussioni sull’argomento in oggetto: “native VS webapp” e in questo articolo vorrei sintetizzare alcune mie valutazioni.

Potendo dedicare allo studio delle applicazioni mobile solamente poche ore la sera ho subito approciato il mondo delle WebApp perchè mi consentono di sfruttare competenze preesistenti: HTML5, Javascript, CSS.

WebApp

Per il primissimo approccio ho utilizzato jQuery Mobile con il quale ho realizzato una semplicissima photogallery la cui interfaccia responsiva si adatta al dispositivo che la richiede: se usi un computer vedrai una pagina web con effetto lightbox mentre se usi un iPhone, Android, iPad vedrai un’interfaccia simile a quelle native.
Inoltre il passaggio tra le immagini è gestito dal touch e non dal click. [vedi esempio].

Successivamente mi sono dedicato a SenchaTouch, un prodotto veramente incredibile e completo ma dotato di scarsa documentazione libera: l’azienda che lo produce campa vendendo formazione!
Attualmente mi sto dedicando allo studio di questo prodotto e ho aperto un piccolo blog dedicato dove pubblico i miei “appunti di viaggio” su piccole e grandi cose che scopro sull’argomento.

Principali vantaggi di un’applicazione web based:

• sviluppo su tecnologie open: html, javascript, css
• sviluppo su browser web: safari, chrome
• deploy dell’applicazione su server FTP
• installazione semplice: basta collegarsi all’indirizzo dell’app
• possibilità di funzionamento off-line (in assenza di connettività)
• compatibilità semplificata con Android, Blackberry

Applicazione Nativa

Lo studio di applicazioni native l’ho approciato qualche tempo fa scontrandomi subito con la pessima sintassi del linguaggio ObjectiveC.

Sostanzialmente i framework (volutamente al plurale) di sviluppo su cui si basano le applicazioni native sono incredibili collezioni di oggetti e componenti pronti da utilizzare e configurare.

L’applicazione risulta così una composizione creativa di oggetti mentre la realizzazione di componenti ex-novo è tutt’altra cosa.

In linea di massima ritengo che per chi proviene dal mondo web la curva di apprendimento sia piuttosto lunga rispetto all’applicazione web based a parità di obiettivo.

Principali vantaggio di un’applicazione nativa:

• AppStore: visibilità, diffusione, guadagno
• prestazioni decisamente superiori
• accesso all’hardware: fotocamera, file system, accelerometro, etc
• funzionamento off-line nativo

Applicazione Ibrida con PhoneGap!

Una possibilità di congiungere le due diverse soluzioni in un compromesso che possa sfruttare i relativi vantaggi è l’applicazione ibrida web/nativa. Questa soluzione si può ottenere con PhoneGap.

L’applicazione ibrida è un wrapper che consente il funzionamento dell’applicazione web. Una sorta di piccolo browser preconfezionato.

Solo questo punto rende possibile distribuire l’applicazione su AppStore consentendo dunque il funzionamento off-line nativo!

Cataloghi, manuali, reference, schede tecniche sono esempi di applicazioni che trovano in questa soluzione la miglior soluzione possibile: velocità di sviluppo abbinata a capacità di distribuzione su AppStore!

PhoneGap mette anche a disposizione delle API Javascript per poter accedere a funzionalità avanzate del dispositivo quali:

• file system
• fotocamera
• libreria media
• accelerometro
• bussola
• contatti
• geolocalizzazione
• connettività
• notifiche
• storage db

Con questo sistema sono riuscito, nell’arco di una giornata, a realizzare il prototipo di un’applicazione che mantiene sincronizzati sul device (in questo caso un’iPad) una serie di files (pdf) pubblicati su di un server FTP remoto. Una sorta di client Dropbox ma mooolto più semplice.

In conclusione presumo che proseguirò sulla strada dell’applicazione ibrida perchè rappresenta un punto di giunzione tra le due diverse filosofie di sviluppo. Inoltre offre un sistema piuttosto semplice per realizzare applicazioni compatibili con più dispositivi!

Segnala presso:

1. Compatibilità cross-library
2. Configurazione globale del plugin
3. Separazione delle API dal codice funzionale del plugin stesso

1. Definizione di uno Scope anonimo:

/**
 * jQuery Bacheca
 * Plugin Dimostrativo
 */

;(function($){
  // Plugin's code goes here
})( jQuery );

2. Configurazione Globale del Plugin 

$.bacheca = {

  // Versione ed altre info eventuali.
  version: '1.0,
  author: 'Marco Pegoraro',
  doc: 'http://www.documentazionedelplugin.com',

  // Configurazione globale del plugin.
  defaults: {},

};

Questa istruzione estende jQuery e aggiunge una nuova proprietà chiamata con il nome del plugin stesso.

NOTA: I dati qui collezionati saranno pubblici ed accessibili da qualunque porzione di codice abbia accesso al namespace jQuery. Questo è un fatto importante perchè chi utilizza il nostro plugin potrà scrivere istruzioni simili alla seguente per configurare a livello globale il comportamento del plugin stesso.

$.bacheca.defaults.var1 = "foo";

Qualunque istanza del plugin bacheca riceverà questa variabile nella configurazione locale (a meno che non venga sovrascritta dalla configurazione dell’istanza stessa!)

Può essere molto utile poter controllare, a livello di pagina, se un determinato plugin è caricato o meno con un’istruzione simile a questa:

if ( $.bacheca ) { /* plugin exists */ } else { /* plugin missing */ }

3. Il Plugin

Il plugin vero e proprio è semplicemente una funzione che estende la collection di jQuery aggiungendo nuove funzionalità.

$.fn.bacheca = function() { /* plugin logic */ }

Molti sviluppatori implementano le funzionalità direttamente nel codice logico del plugin ma io trovo sia più corretto organizzare il plugin come un metodo pubblico di accesso ad API  private.

Questo significa che tutta la logica del plugin è inaccessibile da codice globale e la possiamo utilizzare solamente attraverso il plugin stesso mediante istruzioni simili a:

$('#bacheca').bacheca({ bgcolor: "#eee" });
$('#bacheca').bacheca( "write", "Nuova frase in bacheca" );
$('#bacheca').bacheca( "clear" );

Come si può vedere da questo esempio stiamo utilizzando sempre il plugin “bacheca” il quale avrà comportamenti differenti in base alla tipologia del primo parametro. nel caso il primo parametro venga riconosciuto come nome di una API essa verrà invocata ricevendo tutti i parametri aggiuntivi.

Il codice da utilizzare per implementare quanto esposto è:

// Collezione di metodi di interfaccia (API)
apis = {};

// Definizione del plugin
$.fn.bacheca = function( method ) {

  // Cerco il metodo richiesto tra le API esposte.
  if ( apis[method] ) {
    return apis[ method ].apply( this, Array.prototype.slice.call( arguments, 1 ));

  // Lancio il metodo di inizializzazione in presenza di un oggetto di configurazione.
  } else if ( typeof method === 'object' || ! method ) {
    return apis.init.apply( this, arguments );

  // Lancio un'eccezione jQuery in caso il metodo API non sia trovato.
  } else {
    $.error( 'Method "' +  method + '" does not exist on jQuery.bacheca' );

  }
}

Come anticipato il plugin non contiene logica funzionale ma è solo un “passa carte” verso metodi elencati in un array chiamato “apis”.

L’oggetto “apis” viene definito all’interno dello scope del plugin e risulta quindi essere un oggetto “privato” il cui utilizzo è riservato al codice del plugin stesso.
In questo modo possiamo esporre funzionalità all’esterno garantendo che esse non siano modificabili da altro software (altri plugins, etc).

4. API Collection

Il plugin definito nel paragrafo precedente non fa altro che cercare metodi all’interno della collezione delle API.

Il nostro lavoro di sviluppo del plugin consiste proprio nell’estendere queste API a partire dal metodo “init()”, che riceverà la configurazione del plugin stesso, proseguendo poi per i metodi di azione.

5. Bacheca::init()

apis.init = function( cfg ) {

  // Estendo la configurazione di default con la configurazione locale
  var cfg = $.extend( {}, $.bacheca.defaults, cfg );

  // Ciclo gli elementi identificati dal selettore
  return $(this).each(function(){
    $bacheca = $(this);
    $bacheca.html( cfg.content );
    if ( cfg.bgcolor != null ) $bacheca.css( 'background', cfg.bgcolor );
  });
}

Questo metodo riceve la configurazione locale applicata all’istanza del plugin. Ogni istanza del plugin (ogni suo utilizzo) può essere configurato a piacere ed è importante che queste configurazioni siano mantenute isolate le une dalle altre.

In questo primo e semplice plugin la configurazione è utilizzata semplicemente per definire il contenuto iniziale della bacheca ed il suo colore di sfondo. Gli altri metodi API non fanno uso di questa configurazione dunque non ci siamo occupati di gestirla al meglio (lasciamo l’argomento ad un articolo dedicato).

6. Bacheca::write(), Bacheca::clear()

apis.write = function( word ) {
  return $(this).append('<p>'+word+'</p>');
}

apis.clear = function() {
  return $(this).html("");
}

Questi due metodi API esposti dal plugin sono estremamente semplici e consentono di manipolare il contenuto della bacheca.

7. Utilizzo del plugin:

<!-- Codice HTML -->
<div id="bacheca"></div>

// Codice Javascript globale:
$(document).ready(function(){
  $('#bacheca')
    .bacheca({ bgcolor:"green", content:"Test Contenuto" })
    .bacheca('clear')
    .bacheca('write','Il mio nome è Marco')
  ;
});

Segnala presso:

Task4 riconosce la lingua in uso nel tuo browser e tenta di caricare la traduzione necessaria.

E’ anche possibile impostare in modo esplicito la lingua desiderata.

Se l’indirizzo del tuo progetto è “http://task4.it/nomeprogetto” e vuoi utilizzare l’interfaccia in lingua inglese utilizza semplicemente il seguente indirizzo:

 http://task4.it/en/nomeprogetto

Partecipa al progetto!

Task4 può essere utilizzato gratuitamente da chiunque dunque ci servono più  traduzioni possibili!
Scarica il pacchetto di localizzazione e contribuisci al progetto!

Segnala presso:

Venerdì un cliente mi domanda come si fa ad attivare i commenti in una pagina del suo sito e io un po’ imbarazzato gli risposi:
“bè, non si può! Bisogna fare un blog!”.

Egli mi guarda cercando di capire il mio punto di vista e rispose:
“ma perchè? basta mettere un form no?”

Io rimango sempre felicemente sorpreso di come la gente percepisce “facile” costruire un sistema web. Pensano che una pagina sia un oggetto fisico sul quale “appoggiare” altri oggetti fisici. Pensano che i “moduli” siano veramente i pezzi di un puzzle.

Dopo aver preparato un piccolo preventivo ci ho pensato su parecchio e ho detto: “e perchè no?”

Siamo ormai abituati a inserire Google Analytics (codice Javascript), Google Maps (Iframe o Javascript), Flick (tanto Javascript), Facebook (addirittura un markup inventato + Javascript)… insomma, perchè non inserire un blog esattamente come fosse un filmato YouTUBE?

Così è nato il servizio BlogMyPage.org

BlogMyPage.org permette di ottenere un semplice codice Javascript (ma sono previste numerosi metodi di integrazione) da inserire in una qualunque pagina web (al momento è richiesto jQuery) per aggiungere a tale pagina un sistema di discussione perfettamente funzionante!

Al momento il servizio è in BETA. Lo stiamo provando e lo stiamo migliorando.

Per provarlo è necessario ricevere un codice di invito (Vi ricordate GMail all’inizio?). Per ovvie ragioni regalo un codice di invito a chiunque faccia una donazione tramite i pulsanti PayPal che trovate nel sito!

BlogMyPage.org

Segnala presso:

Trovo questo tipo di strumento molto utile ma estremamente limitativo nella definizione della larghezza del layout che fissata a 950px.

Esistono strumenti per creare versioni ad-hoc del foglio di stile ma io ho affrontato il problema da un punto di vista differente realizzando un plugin jQuery che, presa la larghezza di un elemento “.container” (il wrapper della pagina realizzata con blueprint) aggiusta le regole del framework per adattarlo a tale dimensione.

Vai alla Demo »

Segnala presso:

Ovviamente la miglior soluzione possibile è dotarsi di un buon filtro anti-spam (gMail?) perchè qualunque tipo di mail obfuscator si concretizza in un problema di usabilità ed una barriera di usabilità!

Ho comunque creato una soluzione Javascript basata su jQuery che propone un piccolo e semplicissimo approccio al problema.

L’idea di base è pubblicare nel codice sorgente della pagina un indirizzo mail volutamente errato e gestirne una correzione automatica mediante Javascript.

L’errore consiste nello scambiare il primo e l’ultimo carattere dell’indirizzo mail per cui “info@consulenza-web.com” diventa “mnfo@consulenza-web.coi”.

Ovviamente il nuovo indirizzo mail è formalmente corretto ed un qualunque spam bot o mail crowler lo identifica correttamente. Purtroppo per il malintenzionato questo indirizzo produrrà solamente degli invii falliti.

jquery.mcrypt.js

Il plugin qui proposto di occupa di ripristinare automaticamente l’indirizzo corretto in modo che l’utente non percepisca l’errore.

<script>
$('document').ready(function(){
  $('.mailto').mcrypt();
});
</script>

<a href="mailto:mnfo@consulenza-web.coi" class="mailto">mnfo@consulenza-web.coi</a>

Questa porzione di sorgente è sufficiente per creare un po’ di problemi agli spam engine! Ovviamente non è una soluzione definitiva e nemmeno molto elaborata… però è semplice ed efficace per il suo scopo!

Segnala presso: