Ha estat la millor DrupalcampSpain que s’ha fet fins ara.

Bromes a part, han estat uns dies intensos, plens de conferències, xerrades informals entre passadissos, plens de networking i en definitiva, plens de gom a gom de Drupal. Al final l’assistència fou tot un èxit (es calculen unes 375 persones vingudes de tot el món, encara que principalment de l’estat o més específicament, del país) i la qualitat de les xerrades fou força bona.

Tot seguit faig un petit resum del meu pas durant els tres dies:

Divendres 26 – Presentació i primeres xerrades

Només arribar al Citilab, i fer el registre, ja et donaven una bossa plena fins dalt de merxandatge, una samarreta de la Drupalcamp, una enganxina i un programa dels tres dies (amb això ja vaig preveure que la cosa anava en serio). Després de fer les primeres xerrades amb en Robert, en Pedro, en Conrad i en Jaume, i de menjar una mica, vaig entrar a l’auditori per veure la sessió inaugural: tot un espectacle que donava a entendre que allò seria una cosa gran!

Després d’això, tocà anar a la sessió anomenada “Spaces/Context/Features/Purl. Qué es y cómo se come?“: una exposició força interessant de què són aquests 4 mòduls i on vaig veure que algun d’aquests era precisament el que jo estava buscant des de feia molt de temps.

Tot seguit, a la mateixa sala em vaig quedar a escoltar la sessió “Unit testing & Integration testing. Implementación en Drupal” on s’explicà una mica el tema de tests però no pas com jo m’esperava ni al nivell que es preveia. Tot i així, alguna cosa en vaig treure de bo i ho tinc apuntat com un tema a estudiar en breu.

Una vegada acabada la sessió, cap a casa que al dia següent tocava una jornada llarga.

Dissabte 27 – El dia llarg

Dissabte fou el dia estrella de la Drupalcamp: 21 conferències programades, desenes de xerrades informals improvisades, la fira de treball i el sopar de la nit.

A primera hora, i només arribar, tocà la sessió “Ecommerce para Drupal: Introducción a Ubercart” d’en Pedro, on explicà com començar una botiga electrònica amb Ubercart des de l’inici, a més a més, de solucionar algunes de les preguntes que em rondaven pel cap. Una de les millors sessions que vaig assistir, no tant pel que vaig aprendre jo, sinó pel que crec que va aprendre l’auditori sencer, ja que s’explicava molt bé, ordenadament i de forma clara i directa.

Tot seguit, l’equip català de traducció del Drupal varem fer una xerrada informal per a organitzar-nos, veure’ns les cares i en definitiva, poder llançar-nos en la traducció del Drupal d’una forma més ordenada i amb una gran qualitat associada. Personalment, en vaig sortir molt content tot i que amb deures pendents

Una vegada acabada, i havent esmorzat, me’n vaig anar a la xerrada de “Open Atrium para la gestión de proyectos“. Feia temps que volia saber una mica d’aquest nou producte i amb la xerrada buscava veure quin ús se’n feia i per on anava la cosa encaminada. Alguna conclusió en vaig treure.

Tot seguit fou la fira de treball. Jo vaig anar a veure que es coïa, i després de donar un parell de voltes i escoltar què es proposava, vaig acabar xerrant amb el meu amic Robert sobre drupal.cat i d’altres temes.

Per la tarda, i havent dinat, li tocà al torn a “Drush Make y Feature Server” una xerrada molt més que interessant i de la que vaig aprendre’n molt, sobretot de la primera part. Ja tinc apuntat aquest tema per profunditzar-hi de debò en les properes setmanes.

Després, li tocà el torn a “Building Maps with OpenLayers in Drupal“, la única xerrada en anglès a la que vaig assistir. Personalment, pensava que seria una altra cosa, però mira, al cap i a la fi, vaig practicar el meu anglès i vaig veure com anava el tema de mapes en Drupal, que també és força interessant (i complex!).

Per acabar el dia, i ja de baixada, vaig assistir a “Programación con la API de views. Un caso práctico“, una xerrada que segons el títol semblava que anés per una banda, però al final fou per tot el contrari. Un tema molt interessant, encara que crec que l’exemple que van proporcionar no fou dels més clars que podien haver posat.

Diumenge 28 – Darreres xerrades i clausura

El matí de diumenge ja es notava la ressaca en l’ambient.

La primera xerrada a la que vaig assistir, fou “Construyendo el futuro: Distribuciones y Productos basados en Drupal“. Quan vaig decidir assistir-hi, pensava que no sortiria tan interessat i amb tantes preguntes al cap. La xerrada que més m’ha donat a pensar de tot el cap de setmana i una que en comptes d’explicar, el que feia era plantejar-nos preguntes, que poc a poc, i guiats, varem anar responent. La conferència tractà de la línia que segueix Drupal (on som, cap a on volem anar, què ens espera al futur), de quines necessitats tenen els diversos col·lectius associats (usuaris, desenvolupadors, integradors) i de quin rumb està prenent tot el món que envolta aquest programari (productes i serveis). Molt més que interessant.

Sortint de la xerrada, i amb la sang que em bombejava al cap de totes les preguntes que hi tenia, vaig entrar a “Plantillas, como tomar el control sin perder (mucho) pelo en el intento“. Una xerrada d’iniciació al món de les plantilles però sense entrar en res tècnic. Personalment, crec que hi faltà un últim ingredient, però tot i així, per a la gent que començava, suposo que no va estar gens malament.

I per acabar amb les xerrades, vaig assistir a “Iniciación a Skinr” per voler saber una mica més d’aquest mòdul. Personalment, crec que té una aplicació força reduïda en el món de les webs (tal i com es coneixen) però que sí que pot entrar una mica més en entorns on es necessiti poder donar a l’usuari la capacitat de personalització de diversos elements de la pàgina; encara que crec que a aquest mòdul encara li queda una maduració per arribar al nivell que s’espera d’ell.

Doncs bé, per acabar de tancar els tres dies, li tocà el torn a la sessió de clausura. Un moment de rialles, reflexions i molt bon rotllo. Se sortejaren diversos llibres (que no me’n tocà ni un ) i es feu un petit anàlisi dels tres dies. Personalment, crec que ha estat tot un èxit i espero que l’any vinent hi hagi molt més i molt millor (si és que es pot)! Per acabar, només dir que tot això no hagués estat possible sense la super colla de voluntaris que varen fer tot el possible perquè tot això fos el que va ser! Gràcies a tots!!

Què m’emporto de la Drupalcamp Spain 2010?

• Un munt d’experiències i nous coneixements.
• Un llistat de temes per estudiar i aprofundir.
• Dues xapes: una de Development Seed i una altra d’Open Atrium.
• Dues samarretes: la de regal i una ben xula que vaig comprar.
• Uns quants quilos que he engreixat del munt de menjar boníssim que hi havia.
• Una bona estona de networking.
• I en definitiva, tot un món per a seguir investigant

• Vull que el número d’identificació sigui obligatori!
• El correu electrònic ha d’estar en el format correcte!

O altres típics requeriments que requereixin de fer una validació del formulari.

Davant d’aquest escenari, el primer que ens ve al cap és fer les validacions amb JavaScript a la capa client. Bé, no està malament. Fer les validacions a la capa de client, és ràpid en temps de computació, senzill (normalment) i proporciona una resposta ràpida a l’usuari, fet pel qual assegurem una bona experiència d’usuari mentre introduïm dades. Una de les primeres normes de la usabilitat a formularis és: com més aviat sàpiga l’usuari que s’ha equivocat, més aviat podrà reaccionar-hi (compte amb la interpretació d’aquesta frase made-by-me!). Però mai hem d’acabar aquí!

Fer les validacions només a la capa client és una decisió completament errònia. On de debò s’han de fer aquestes comprovacions és a la capa servidor. Allà és on s’ha de mirar si cert camp existeix, si el format de tal camp és el correcte, de si la relació entre dos camps és correcta, etc. És a la capa servidor on tot aquest algorisme s’ha d’executar per prevenir qualsevol error que pugui tenir l’aplicació. És allà on s’executa la lògica de l’aplicació i on les validacions, com part d’aquesta lògica que són, s’han d’executar. Si només ho féssim a client, què passaria si no tinguéssim disponible el JavaScript? Quin seria el comportament de l’aplicació? Possiblement, acabéssim en un estat d’inconsistència no desitjat per ningú.

Sovint quan es planteja aquest argument (validacions dobles a capa client i servidor), molts arquitectes d’aplicacions (remarco la paraula perquè és el títol que es posen ells, no el que els hi posaria jo) posen el crit al cel i diuen la del porc argumentant que s’està fent una tasca dues vegades i que el rendiment de l’aplicació en general es veu ressentit. Si alguna vegada us trobeu davant d’això, només heu de dir:

D’acord, llavors, les validacions que es facin només a la capa de servidor!

Veureu com els hi canvia la cara

Cal tenir ben presents quines són les implicacions de deixar un processament de dades a una capa tan fràgil com pot ser un navegador, i la nostra tasca és argumentar i deixar ben clar el per què a client no és lloc per fer aquest tipus de processament.

Tingueu aquest consell sempre ben present perquè segur que al llarg de la vostra vida professional us caldrà utilitzar-lo més d’un cop.

Logotip de la DrupalcampSpain 2010

Els propers dies 26, 27 i 28 de febrer es durà a terme al Citilab de Cornellà la primera Drupalcamp de l’estat, l’esdeveniment del món drupaler més gran de la península.Durant aquests tres dies es duran a terme diverses xerrades, tallers, xerrades informals (anomenades BOFs), a més a més, de ser un lloc únic per a poder augmentar el nostre networking drupaler amb gent propera. Igualment, servirà com a lloc per a poder contactar entre diverses empreses i professionals per tal d’iniciar possibles col·laboracions o simplement, per intercanviar punts de vista i experiències.

Com no podia ser menys, jo ja m’he inscrit (els primers 50 tenien un descompte de 10€ i calia aprofitar-lo), i per tant, hi seré, a poder ser, els tres dies. Igualment, he proposat una sessió sobre com traduir Drupal de forma correcta i ordenada (actualment hi ha una mica de merder al voltant d’aquest tema). A més a més, em ronda pel cap proposar una sessió sobre integració de maquetes HTML+CSS+JS a Drupal, cosa que mai he trobat informació i exemples precisos sobre un cas pràctic.

Doncs bé, si teniu cap proposta sobre alguna cosa que us agradaria saber sobre Drupal, digueu-ho i intentarem trobar algú que ho pugui explicar en una sessió.

Si necessitem saber si una variable ha estat declarada però sense valor assignat, podem comparar-la amb el “valor” undefined. Així podem veure:

var x;
// x === undefined retornaria cert
x = 5;
// x === undefined retornaria fals

Però si el que de debò volem fer és comprovar si aquesta variable ha estat definida en algun punt del script, no podem fer aquesta comprovació, ja que al intentar cercar el símbol “x” a la seva taula de noms, ens donaria un error de referència. Llavors, podem fer-ho o no? La resposta és sí! Només cal comprovar el seu tipus: si no té un tipus definit, vol dir que no està definida dins la taula de noms. Total, que podem fer:

// typeof(y) === undefined retornaria cert
var y;
// typeof(y) === undefined retornaria fals

I ja per acabar amb nota: com fer per saber si certa variable està definida directament en l’àmbit global de l’script? Doncs bé, com bé sabem, qualsevol variable definida a l’espai global, està també definida com un camp de l’objecte global. Llavors, els que ens dediquem a la programació web, i per tant tenim l’objecte window com a objecte global, podem fer la comprovació:

window.z === undefined
// retornaria cert si la variable z no ha estat definida

Doncs res, aquest ha estat el truc del dia. Espero que us sigui útil!

Portada del llibre Javascript. The Definitive Guide

Si alguna vegada esteu interessats en comprar un llibre sobre un llenguatge de programació i descobriu que un autor anomenat David Flanagan n’ha escrit un, no us ho penseu més: agafeu-lo. No tinc el plaer de conèixer-el en persona, però el que us puc ben assegurar és que aquest home, abans d’escriure res sobre un tema, ho estudia tot. I això us ho puc ben assegurar perquè no és pas el primer llibre que llegeixo d’aquest home i me n’adono de la minuciositat en que descriu un concepte o com va esfilagarsant un tema fins a deixar-lo tot explicat i ben explicat sobre paper.

El llibre que ens ocupa, JavaScript. The Definitive Guide, és per definició, el llibre de lectura obligatòria si volem intentar conèixer de debò aquest llenguatge de programació. Aquest llibre ens demostra que JavaScript no és, com la gent pensa, un llenguatge de programació només per la web i que només serveix per a validar formularis, fer menús desplegables i fer que la meva pàgina sigui més molona. No! JavaScript, i més d’un se sorprendrà al llegir això, és un dels llenguatges de programació més difícils i complexes que existeixen. Tampoc us espanteu, sinó que aquest llenguatge de programació amaga més d’una sorpresa, i fins que no llegeixes un llibre on s’explica tot amb pèls i senyals, no te n’adones de fins a on arriba el seu potencial.

Aquest llibre, com el seu nom indica, vol ser la guia definitiva de JavaScript, i sota el meu punt de vista, ho compleix sense cap tipus de dubte. La seva lectura, salvant la barrera inicial de ser un llibre de quasi bé un miler de pàgines escrites en anglès, es fa molt amena, avançant per tots els conceptes del llenguatge d’una forma natural i seguint un guió gens qüestionable, que ens durà, a través de centenars d’exemples, a comprendre parts completament desconegudes per molts.

Només mirant el llom interior del llibre, podem veure que aquest es divideix en quatre parts; encara que el llibre tracta només amb dos grans temes:

• La primer part, anomenada Core JavaScript, tal i com el seu nom indica, explica el nucli del llenguatge amb un detall excepcional. En aquesta part podem trobar els següents capítols:
  • Lexical Structure
  • Datatypes and Values
  • Variables
  • Expressions and Operators
  • Statements
  • Objects and Arrays
  • Functions
  • Classes, Constructors, and Prototypes
  • Modules and Namespaces
  • Pattern Matching with Regular Expressions
  • Scripting Java
• La segona part, anomenada Client-Side JavaScript, se centra més en el navegador com a plataforma de desenvolupament d’aplicacions en JavaScript. Hi podem trobar:
  • JavaScript in Web Browsers
  • Scripting Browser Windows
  • Scripting Documents
  • Cascading Style Sheets and Dynamic HTML
  • Events and Event Handling
  • Forms and Form Elements
  • Cookies and Client-Side Persistence
  • Scripting HTTP
  • JavaScript and XML
  • Scripted Client-Side Graphics
  • Scripting Java Applets and Flash Movies
• La tercera part, anomenada Core JavaScript Reference, és una referència completa de totes les classe, objectes, mètodes, propietats i demés del nucli del llenguatge definits per JavaScript 1.5 i ECMAScript versió 3.
• La quarta part, anomenada Client-Side JavaScript Reference, és una referència de tots els elements que podem trobar dins d’aquest tema, des de DOM (nivell 1, 2 i 3), canvas, etc.

Què, te’l compres? T’he convençut? Fes-ho, veuràs com em dones la raó de que és un llibre d’aquells que s’han de tenir sempre a mà.

El nou lloc és força més intuïtiu, amb un disseny lleuger centrant l’atenció en el contingut i no tant en la forma de mostrar-lo. Al contrari de l’anterior lloc, sembla que en aquest s’hagin parat un moment i hagin rumiat l’arquitectura de la informació, ja que tots els continguts de la web estan categoritzats en diferents seccions de fàcil identificació i la navegació entre els diferents apartats es fa de forma força intuïtiva.

Com a nota irònica, al seu blog es comenta que el CSS usat no passa el seu validador. Segons argumenten, la majoria d’errors són per temes de hacks, regles pròpies d’alguns navegadors, etc.

Doncs res, nous aires pel W3C que ja tocava!

Cap allà als mitjans dels noranta, Internet Explorer 4.0 introduí aquest event no estàndard, però a diferència d’altres ocasions, aquest cop feu una cosa útil i els navegadors amb motor Gecko ho acabaren introduint a la versió 1.7 de Mozilla (Firefox 1.0).

Aquest event, tal i com resa el seu nom, es dispara just abans de l’event onunload, és a dir, abans que es descarregui el contingut actual de la pàgina, i per tant, ens permet executar algun tipus d’acció en aquest moment.

A diferència dels altres events, aquest funciona força diferent: per tal de mostrar un missatge a l’usuari abans de descarregar la pàgina, el que cal fer és retornar una cadena amb el missatge que es vulgui mostrar. Un exemple podria ser:

window.onbeforeunload = function(e) {
  return "No heu enviat el formulari. Si tanqueu la pàgina perdreu tots els canvis fets fins ara.";
}

Així, en cas d’abandonar la pàgina, se’ns mostraria un quadre amb el missatge:

Esteu segur que voleu sortir d’aquesta pàgina?

No heu enviat el formulari. Si tanqueu la pàgina perdreu tots els canvis fets fins ara.

Premeu D’acord per a continuar, o cancel·la per a romandre a la pàgina actual

Les frases que hi ha just abans i després de les nostres les posa el navegador (en aquest cas Firefox) i no es poden eliminar, substituir ni evitar de cap tipus de les maneres.

Val a dir que en cas que el navegador no tingui implementat aquest event, aquests simplement l’ignoraran i no mostraran pas el missatge a l’usuari.

Pàgines protegides

Recapitulem. La raó principal d’aquest article és que fa poc a la feina em varen demanar que implementés una funcionalitat per a protegir pàgines: volien poder mostrar un missatge quan un usuari intentés abandonar la pàgina enmig d’un formulari dins d’un procés amb un cert flux o bé intentés abandonar una pàgina, la construcció de la qual fos molt costosa. Un exemple ideal per a treure l’event onbeforeunload de la nostra cartera de recursos. Anem a construir-ho.

Per tal de poder marcar si una pàgina la tractem com a protegida o no, és a dir, si registrem l’event onbeforeunload per mostrar un missatge a l’usuari en cas d’abandonar la pàgina, afegirem la classe protected a l’element /body de la pàgina:

<body class="protected">

Així, si usem jQuery, podem afegir les següents línies de codi per a tenir-ho fet:

$('body.protected').each(function () {
  window.onbeforeunload = function(e){
    return "Si abandones, ho perdràs tot per sempre!";
  };
});

Però tenim un petit inconvenient: si fem clic en un enllaç o si enviem el formulari fent clic a un botó, se’ns mostrarà el missatge, cosa que volem evitar. Això es pot resoldre inhabilitant l’event en cas de fer clic a certs elements:

$('body.protected p.botons input, body.protected a.sense-onbeforeunload', context).click(function () {
  window.onbeforeunload = null;
});

I així de fàcil obtenim el que busquem. Fàcil, oi? I segur que a més d’un li sembla útil, i fins i tot, més que necessari en alguna situació quotidiana.

Recursos

• Onbeforeunload event. Internet Explorer Developer Center
• Window.onbeforeunload. Mozilla Developer Center
• onbeforeunload: tiende una mano al usuario

Si en el seu moment vaig recomanar el llibre Bulletproof Web Design per aquells que volen entrar al món de la maquetació web, recomano ara el CSS Mastery per tots aquells que volen accedir a uns coneixements més avançats d’aquest món, i poder passar així a fer projectes més complexes.

Andy Budd ens avisa des d’un principi: això no és pas un llibre per a novells, sinó que està fet per aquells que vulguin donar una volta més de cargol a la maquetació web. Ho diu amb raó, ja que el llibre comença amb un primer capítol de repàs, però ràpidament accelera per donar pas als següents capítols per entrar en tècniques més complexes, trucs usuals i sobretot, els hacks que no ens podem treure mai de damunt.

És un llibre fàcil de seguir si tenim uns mínims coneixements de CSS i HTML, però sobretot, és fàcil aprendre coses noves i fàcil poder-les posar en pràctica, ja que el llibre bé carregat d’exemples, explicacions de casos d’ús i amb alguna que altra referència de casos reals disponibles a la xarxa. En definitiva, un llibre molt més que recomanable: imprescindible!

Al revisar una mica l’índex, podem veure que el llibre està distribuït en onze capítols, nou dels quals són exposició de tècniques (separades per temàtica) i els dos darrers són l’elaboració de dos exemples o casos d’estudi amb tota la informació adquirida al llarg del llibre:

Setting the foundations

En aquest capítol, com ja he comentat abans, l’autor fa una petita introducció repassant conceptes com els d’especificitat, organització dels documents, els diferents tipus de selectors, etc. Es recomana una lectura, encara que sigui en diagonal, per tal d’entrar en matèria.

Visual formatting model recap

Repàs als diferents models de caixa, flotats i posicionament absolut/relatiu. Problema del doble marge i d’altres trucs.

Background images and image replacement

Repàs al concepte d’imatge de fons. Caixes amb cantonades arrodonides, tècniques per a la simulació d’ombres i repàs a diferents tècniques de reemplaçament d’imatges.

Styling links

Tal i com indica el títol, en aquest capítol es repassen diferents tècniques per a donar estils als enllaços, des d’estilitzar enllaços externs, tècniques per a l’ús d’sprites com a imatges de fons entre d’altres coses.

Styling lists and creating nav bars

En aquest capítol s’aborden diferents tècniques per a realitzar barres de navegació, tan verticals com horitzontals (tècnica d’sliding doors). També explica com crear un mapa d’imatge entre d’altres temes.

Styling forms and data tables

Un dels capítols d’on vaig treure més suc en el seu moment. No només explica temes de CSS sinó que també exposa conceptes sobre el marcat correcte per una taula, estructuració i accessibilitat a formularis i més moltes més coses.

Layout

El típic tema de tot llibre de CSS: layout fix, elàstic, líquid i combinat.

Hacks and filters

Capítol força interessant on s’exposen les tècniques per a separar fulls d’estils per diferents medis o navegadors, trucs per aplicar regles a certs clients, etc.

Bugs and bug fixing

Un altre capítol interessant i força inusual. S’hi recullen els bugs més importants dins del món de la maquetació i diferents tècniques per a identificar tant a aquests com d’altres que no estiguin documentats encara.

Case study 1: More than doodles

És el capítol més llarg de tot el llibre. En ell s’hi descriuen tots els passos que cal seguir per acabar construint la maqueta d’una pàgina, a simple vista força complexa. S’usen molts dels conceptes exposats al llibre, i sobretot s’hi fa especial atenció al tema de les llistes i del model de caixes.

Case study 2: Tuscany luxury resorts

Un exemple força interessant de pàgina amb layout fluid. A més a més, s’apliquen tècniques de posicionament de caixes força interessants i de reemplaçament de text per imatges que cal tenir força en compte.

En definitiva, i per tancar la ressenya, un llibre que cal comprar i llegir per ser un bon expert en el tema.

Per a exemplificar la construcció, crearem un petit giny per a construir contingut tabulat en pestanyes.

Partim d’un fragment HTML com el següent:

<div class="pestanyes">
  <h2>Pestanya 1</h2>
  <div>
    ...contingut...
  </div>
  <h2>Pestanya 2</h2>
  <div>
    ...contingut de la segona...
  </div>
  <h2>Pestanya 3</h2>
  <div>
    ...i una mica més...
  </div>
</div>

Si ens centrem en el giny, podríem redactar una petita explicació funcional com la següent:

• En estat de repòs, es mostren les pestanyes amb la primera activa i només es mostra el contingut relacionat amb aquesta.
• Una vegada cliquem a una pestanya, aquesta passa a ser l’activa i el contingut que es mostra passa a ser el relacionat amb aquesta.

Ara només falta traduir això a codi JavaScript.

Comencem creant l’estructura general del plugin:

$('.pestanyes').each(function() {
  ...
});

I les estructures necessàries per a crear el giny. Primer de tot caldrà amagar les capçaleres i el contingut d’aquestes i crear l’estructura per a les pestanyes que a nosaltres ens sigui còmode de treballar-hi. Per exemple una d’ideal seria una senzilla llista <ul><li>...</li></ul>.

Anem a passar tot això a codi JavaScript:

$('div.pestanyes').each(function () {
  // creem una referència a les capçaleres i al contingut de les pestanyes
  var $headings = $('h2', this);
  var $content = $headings.next();

  // amaguem les capçaleres i els continguts
  $headings.hide();
  $content.hide();

  // creem l'estructura de les pestanyes
  var tabHtml = '';
  $headings.each(function() {
    tabHtml += '<li>' + $(this).text() + '<\/li>';
  });

  // i l'afegim al document
  $(this).prepend('<ul class="tabs">' + tabHtml + '<\/ul>');
}

Una vegada creada l’estructura, només queda marcar l’estat inicial amb la primera pestanya i el seu contingut relacionat com a actius:

var $tabs = $('ul.tabs li');
$tabs.eq(0).addClass('active');
$content.eq(0).show();

Ara només ens queda centrar-nos en la interacció amb les pestanyes. Quan un usuari faci clic en una pestanya, cal resetejar l’estat actual (eliminar la marca d’actiu) i marcar la pestanya que s’ha clicat com a activa, juntament amb el seu contingut relacionat.

$tabs.click(function() {
  // eliminem la classe i amaguem el contingut
  $tabs.removeClass('active');
  $content.hide();

  // marquem la pestanya activa i mostrem el contingut que calgui
  $(this).addClass('active');
  var tabIndex = $tabs.index(this);
  $content.eq(tabIndex).show();
});

Si ho posem tot junt, podem veure el resultat i una aplicació a un cas a l’exemple.

Però fins aquí no hem fet res de res per construir un plugin. Posem-nos a treballar-hi.

Adaptació del codi per a ser un plugin vàlid

Quan pensem en crear un plugin jQuery, el que ens ve al cap és crear una funcionalitat reutilitzable dins del domini d’un objecte jQuery, és a dir, estendre l’objecte. Així, si ens centrem en el nostre exemple, la idea és acabar creant un codi tal que per poder crear un contingut tabulat, hàgim d’escriure simplement:

$('div.pestanyes').tabs();

Si el que volem és estendre l’objecte jQuery el que haurem de fer, igual que en qualsevol altre objecte JavaScript, és afegir una nova propietat al seu objecte prototype. Així, una cosa d’aquest tipus seria vàlid:

$.prototype.tabs = function () {
  // el nostre codi
}

Però si hagués decidit fer-ho així, ja s’hauria acabat l’entrada, i aquesta no és pas la idea.

Si mirem les primeres línies de la biblioteca jQuery, podem veure la creació d’un alies força interessant:

jQuery.fn = jQuery.prototype

Així, si volem usar aquesta notació, podem ampliar directament l’objecte tot fent:

$.fn.tabs = function () {
  // el meu codi
  return this;
}

S’ha afegit el retorn del propi objecte per a poder permetre l’encadenament de crides:

$('#element')
  .tabs()
  .mesCoses();

El plugin que estem construint és força senzill, però què passaria si tinguéssim variables globals, funcions auxiliars i demés? Alguna cosa com aquesta:

var foo = 0;
$.fn.myPlugin = function () {
  foo += 5;
  myMethod();
  return this;
}
function myMethod() {
  ...
}

Amb aquest escenari, algú sense gaires llums (o amb ganes de tocar la pera) podria usar el plugin des la següent forma (i des de l’espai global de noms):

var myMethod = 'bar';
$('#element').myPlugin();

Però per sort, nosaltres tenim un as sota la màniga anomenat closure. Així, podem englobar tot el codi del nostre plugin dins d’una funció anònima:

(function () {
  var foo = 0;
  $.fn.myPlugin = function () {
    foo += 5;
    myMethod();
    return this;
  }
  function myMethod() {
    ...
  }
}) ();

Sembla que tot ja està fet, no? Queda un últim punt. Per a assegurar la compatibilitat amb d’altres biblioteques, no podem usar l’àlies de l’objecte jQuery $ així com així, sinó que hauríem d’usar jQuery com a mètode d’accés a l’objecte. Però això no és gaire còmode, no? Tranquils! Aprofitant que tenim la funció anònima englobant el nostre codi, podem crear un àlies segur per a jQuery fàcilment passant-lo com a paràmetre d’aquesta:

(function($) {
  ...
})(jQuery);

Ara ja estem en condicions de crear el nostre primer plugin. Podeu veure el codi resultant a l’exemple.

Ampliacions

Una vegada que tenim el plugin funcionant, ens podem centrar en fer-lo més real. El primer que ens podem preguntar és: què és un plugin sense opcions? Doncs si en volem, només cal donar-li un parell de voltes i fet.

Considerem dues opcions de configuració:

• Pestanya activada per defecte, que serà un enter (per defecte 0) que indicarà l’index de la pestanya (activatedIndex)
• Efecte visual al canviar de pestanya, que serà el nom d’una funció (per defecte null) dins l’espai de noms de l’objecte jQuery (animation)

I si ho afegim al codi que ja tenim:

$.fn.tabs = function (options) {
  var config = $.extend({
    activatedIndex: 0,
    animation: null
  }, options || {});

  ...
}

Ara el mètode tabs accepta un paràmetre que és un objecte de configuració. S’usa el mètode $.extend per tal d’estendre un objecte amb els valors per defecte amb els passats com a paràmetre.

Ara, els únics canvis que cal fer són força trivials. Pel cas de l’índex de la pestanya a activar:

// marquem la pestanya i el contingut desat a la configuració com actiu
var $tabs = $('ul.tabs li');
$tabs.eq(config.activatedIndex).addClass('active');
$content.eq(config.activatedIndex).show();

I pel cas de l’animació al canviar de pestanya:

if(config.animation) {
  $content.eq(tabIndex)[config.animation]();
} else {
  $content.eq(tabIndex).show();
}

I per acabar, només falta veure-ho tot ajuntat i funcionant al seu exemple corresponent.

Fonts

No creieu pas que sóc un geni. Ni molt menys. Aquesta entrada està basada en una de molt millor del meu amic Choan, el qual em va iniciar en el meravellós món del JavaScript. Només he volgut explicar-ho des de la meva òptica, usant alguna que altra alternativa de notació i amb un exemple ben diferent.

<div style="margin: 5px;">
    <em>Aquest contingut el vull en lletra cursiva</em>
    <small><a onclick="window.location='/lipsum'" href="http://www.example.com">Lorem ipsum dolor</a></small>
</div>

Normalment la majoria de programadors som ben conscients de la incorrecció del fragment anterior, però sovint ens trobem incorreccions d’aquest tipus completament encobertes, i sempre seguint el mateix patró: el mal ús dels noms de classe dels elements.

Usaré exemples de la xarxa per a il·lustrar el que vull dir. Si anem a la portada de la pàgina d’una institució molt important del país podem trobar coses així (canvio els texts per centrar l’atenció):

<ul id="ul_home">
	<li><a class="vermell_nobullet_2" href="http://www.example.com">Ipse quat erimo</a></li>
	<li><a class="vermell_nobullet_2" href="http://www.example.com/dog">Sailer due rit</a></li>
</ul>

<div class="marge_superior">
    <h2><span id="actualitat" class="titol_seccio">Lorem ipsum</span></h2>
</div>
<div id="altres_serveis" class="border_top">
    <div class="border_bottom">
        <a class="text_gris" href="http://www.example.com/bird">Dolor et sumum</a>
    </div>
</div>

El valor de l’atribut @class d’alguns dels elements ja ens dóna informació de com s’estilitzaran al veure-ho associat al seu full d’estils.

Però sovint no es veu tan fàcilment la incorrecció a l’assignació dels noms de les classes. Per exemple, és ben normal trobar-nos sempre al fragment de descripció de l’organització d’un document, classes del tipus:

<body class="3-columnes">
    <div class="columna-esquerra">
        Lorem ipsum
    </div>
    <div class="columna-central">
        Dolor set
    </div>
    <div class="columna-dreta">
        Icse et luopir
    </div>
</body>

Hi veieu res d’estrany? Per saber si les classes són reveladores de la forma final, només cal que us feu la següent pregunta: podríeu saber quina és la forma final de la pàgina només llegint l’HTML? Si la resposta és sí, les classes són errònies. Si és no, doncs la cosa ja està millor.

Per exemple, una forma correcte de fer la divisió del document podria ser:

<body class="layout-complet">
    <div class="contingut-primari">
        Lorem ipsum
    </div>
    <div class="contingut-secundari">
        Dolor set
    </div>
    <div class="contingut-terciari">
        Icse et luopir
    </div>
</body>

Oi que ara ja no us espereu com serà el document final?

Per tant, cal anar amb compte a l’hora d’assignar els noms a les classes. Sempre cal tenir ben present de separar la forma o presentació del contingut i anar una mica amb peus de plom a l’hora de cercar els valors. Així aconseguirem que els nostres documents siguin 100% independents de la forma en que es visualitzen.