Et de continuer à savourer de plus belle les discussions et autres flacons présents sur la table de banquet.

Paradoxe

Ce discours a de quoi étonner, surtout pour les personnes m’ayant physiquement fréquenté ces derniers temps. Pourtant cette année, rien ne s’est passé comme je l’imaginais ou ne l’espérais, que ça soit sur le plan professionnel ou personnel. Pourtant tout a été indispensable, des échecs à la réussite. Je dirais même que la réussite a en majeure partie puisé dans l’échec ; tout particulièrement en 2011.

Cette année j’ai appris que l’aspiration à un idéal ne devait pas compromettre sa propre intégrité.

Cette année j’ai appris qu’un idéal peut voler en éclat du jour au lendemain, obligeant à reconstruire un modèle de vie en un cycle solaire.

Cette année j’ai appris qu’être freelance et travailler chez soi, même en sortant souvent, c’est un état d’exception insupportable pour le moral.

Cette année j’ai appris à revenir en phase avec mon ombre.

Cette année j’ai appris à suivre les étoiles dans la nuit.

Cette année j’ai appris.

Contribution en baisse/berne

Que ça soit au niveau du rythme de publication sur ce blog, ça n’a pas dû dépasser la frénésie d’un article tous les 2 mois. J’en connais qui attendent encore des billets envisagés et annoncés il y a 1 an. Engloutir 3 ou 4 heures par billet est quelque chose qui m’est devenu plus difficile à envisager.

Idem dans le choix des sujets où plus ça va, et moins l’aspect technique me paraît prédominant. Le meilleur framework du monde n’empêchera pas un projet de foirer. Pour une durée de vie somme toute réduite (6 mois de projet pour 2 ou 3 ans de vie avant de tout réécrire).

Fatalement, coder sur des projets personnels en dehors des heures de travail a subi la même cure d’amaigrissement : cela s’est traduit par des petites livraisons sur des projets déjà existants. De tête, rien de neuf … mis à part une implémentation HTML du Game of Life de Conway.

S’il fallait créer, ce fût avec des images puisqu’en 2011, je capturais une photo tous les 3 jours, en moyenne ; en numérique et en argentique.

La solitude quotidienne du freelance

À bientôt 12 mois d’exercice, ce que j’avais initialement estimé être le paradis s’est transformé en poids pesant : travailler de chez soi est humainement insupportable à moyen et long terme.

J’aurais dû m’en douter : passer de l’extrême à un autre, de l’open space bruyant au bureau individuel chez soi, ça n’a forcément rien de bon. C’était très bien au début, parce que j’en avais besoin. C’était très bien à certains moments, parce que j’en avais besoin.
Par contre, ne pas croiser une seule personne pendant ses horaires de travail, c’est particulièrement étrange.
C’est pesant.

Ça m’a fait comprendre pourquoi la thématique des lieux de coworking intéresse tant que ça les indépendants. La discussion est source de distraction … mais le lien social est indispensable en journée ET en soirée.

Juste en soirée, ce n’est pas viable. Period.

La pression (soci|idé|anim)ale

Cette année j’ai perdu un idéal me propulsant sans crier gare dans la situation du drogué en manque, sans autre choix que de renoncer à sa poudre blanche. Gérer la situation en ayant à gérer les projets professionnels, les clients et le calendrier n’a pas été une partie de plaisir.
Fort heureusement l’été est prompt à une indulgence de délais.

Cette crise a envahi plusieurs pans de ma vie, telle une contagion invisible, et m’a fait comprendre et réaliser un certain nombre de concepts :

• avant d’en être conscient, on est décidément incapable de faire nos pas dans la vie sans reproduire ce qu’on a vu étant jeune, nos parents en premier lieu, que ce soit par mimétisme ou par opposition ;
• quand on est propulsé dans le vide, on n’a pas le choix : il faut être inventif et rapidement arriver à déterminer ce qu’on est, ce qu’on veut, pour remonter la falaise et reprendre son chemin ;
• avancer vers l’inconnu fait partie de notre quotidien : on peut tout perdre du jour au lendemain, et on n’a pas le choix que de jongler avec les faits ;
• si l’inconnu est omniprésent, suivre un chemin que l’on a choisi est indispensable ;
• renoncer à un idéal n’est pas renoncer à soi, à une partie de soi : il y a tout le reste, tout ce qu’on connaît, ce qu’on ne connaît pas encore et ce qu’on ne connaîtra jamais.

D’un autre côté, tout ceci a eu pour effet de renforcer le désir de singularité : si l’homme est un animal social (Aristote ne connaissait pas Facebook), il reste la pierre fondatrice de sa socialité. Autrement dit, il doit disposer de ses propres raisons d’exister, individuellement.

Pour rendre un développeur heureux, il faudrait finalement passer plus de temps avec lui, à parler, qu’à choisir l’architecture de code la plus abstraite car la plus évolutive possible.

L’aventure humaine

Avec ou sans surprise, on en revient aux hommes, et aux femmes. Ces gens qu’on connaissait peu, de loin ou qui sont géographiquement loin. Ces gens qui s’ouvrent, partagent et écoutent.

Ceux qui courent en haut des colines, ressentent et t’aident de leur silence empli de compassion. Ceux qui partagent une bouteille et un morceau de fromage parce qu’il n’y a que ça de vrai. Ceux qui te prêtent une épaule sur un fond de carte postale aux odeurs de lavande. Ceux dont le père n’est pas mort à Venise. Ceux qui te font découvrir une musique transportant au plus haut de la stratosphère. Ceux qui courent avec toi dans le métro un jour de grève. Ceux que tu ne connais que depuis 1h et t’accompagnent dans un des meilleurs concerts de ta vie. Ceux pour qui un verre de rouge accompagné de cigare restera la meilleure conclusion nocturne. Ceux dont la couleur flamboyante de leur manteau te recouvrira d’une nouvelle envie.

Ces gens qui te rencontrent et 1 an plus tard, tels des mousquetaires, signent avec toi un pacte d’associés, pour construire un projet faisant saliver les investisseurs, et ravissant chaque client y ayant recours (d’ailleurs, on recrute des développeurs Web experimentés et j’en parle à la BFM Académie).

Et c’est là où je me dis que travailler chez soi, c’est du gâchis social.

Conclusion

Le fil rouge de cet article est un triptyque problème/conflit/solution. À ce titre, je ne saurais que trop vous conseiller la lecture de l’ouvrage Le conflit de Georg Simmel (ainsi qu’une bonne palanquée de ses écrits). On y retrouve beaucoup d’exemples sociologiques, historiques et amoureux des conflits, ce qu’ils ont engendré … très souvent en bien d’ailleurs. Comme il écrit, le conflit est déjà une étape avancée dans la résolution d’un problème. C’est donc sain.

Il aurait été évidemment bien plus agréable et hype de dire que c’était une année awesome et libertaire.
Sauf que ça n’a pas été le cas et pour rien au monde, je n’aurais voulu qu’il en soit autrement.

2011 aura été exceptionnelle jusqu’au bout.

Seulement voilà, lors de toute tentative de mise à jour, que ce soit du blog, d’une extension ou d’un thème, un écran de configuration de paramètres FTP apparaît. Comme nous sommes des feignants, on ne voudra en aucun cas ouvrir un serveur FTP, qui n’aurait d’ailleurs pour d’autre intérêt que de faciliter les intrusions dans votre système.

Où trouver l’information ?

En cherchant un peu, je suis tombé sur l’ensemble des directives de configuration de WordPress, dont les constantes liées au système de fichier.
Cette section précise ce qu’il faut savoir, même si c’est suffisamment technique pour perdre toute personne ne comprenant rien au code (et on ne leur en voudra pas).

Le problème vient du fait que si l’utilisateur propriétaire du système de fichier n’est pas le même utilisateur du serveur HTTP, WordPress bascule automatiquement en mise à jour via FTP.

L’astuce consiste à forcer WordPress en mode direct (système de fichier) et à donner les droits d’écriture au groupe propriétaire correspondant à celui du serveur HTTP (www-data pour Apache et Nginx sous Debian et Ubuntu).

Configuration de wp-config.php

Forcer le mode direct est très simple. Il suffit d’éditer le fichier wp-config.php, celui-là même qui contient les identifiants de connexion à la base de données et autres joyeusetés. Et d’y rajouter cette ligne, avant la première directive par exemple :

define('FS_METHOD', 'direct');

Enregistrez, et c’est plié.

Réglage des permissions

Côté permissions, ça peut également se régler en 2 coups de terminal. Partons du principe que le groupe propriétaire de votre serveur HTTP est www-data, à la base de votre installation WordPress, il suffit de faire ceci :

chgrp -R www-data wp-content/upgrade wp-content/themes wp-content/plugins wp-content/uploads
chmod g+wx wp-content/upgrade wp-content/themes wp-content/plugins wp-content/uploads

Cette manipulation attribue www-data comme propriétaire des répertoires que vous souhaitez rendre accessibles en écriture et ce, de manière récursive. Dans un second temps, elle attribute les droits d’écriture et d’exécution au groupe propriétaire (peu importe le nom du groupe).
Si vous êtes perdu(e) avec la commande chmod, un peu de lecture pour apprendre à le manipuler (ça sauve la vie).

Conclusion

A ce stade des choses, tout est fonctionnel : tentez d’installer une nouvelle extension, ça passera comme une lettre à la poste.
Si vous rencontrez des difficultés, c’est très certainement parce que les permissions des fichiers qui tentent d’être modifiées ne sont pas suffisantes pour le groupe propriétaire du serveur HTTP. Ajustez la procédure des permissions par rapport à votre besoin.

C’est pas sorcier, il suffisait de le savoir  :-)

J’ai eu besoin récemment d’inclure un éditeur visuel dans un plugin WordPress. Je pensais que c’était une tâche aisée sans chercher sur Google : il n’y avait qu’à faire comme les développeurs de WordPress !

J’ai pensé à tort et ça m’a confirmé une fois de plus que le code source de WordPress était un joyeux bazar.

Le besoin

Mon besoin était tout bête : sur une seule page de mon plugin, j’avais besoin de transformer un bête champ texte en éditeur avancé avec possibilité d’uploader des images et tout ça.

Avec ce simple besoin, j’ai cependant constaté :

1. qu’il était pénible de remonter le cheminement logique de l’éditeur jusqu’à l’inclusion des scripts
2. qu’il n’y a pas de façon standard d’ajouter l’éditeur : il y a bien une fonction wp_tiny_mce mais elle ne fait pas tout … c’est à dire que sans inclure ses dépendances (non documentées), cette fonction n’est d’aucune utilité
3. qu’on trouve à boire et à manger dans le code de WordPress. Pour le code is poetry, on est plutôt proche du SMS kikoololesque

Après avoir trouvé ma solution, je suis cependant tombé sur un article expliquant comment inclure TinyMCE dans WordPress. Elle est juste mais nous verrons que seule la moitié du chemin a été faite avec.

La solution

<?php
add_action('admin_menu', 'include_tinymce');
function include_tinycme()
{
  add_action('admin_head', 'wp_tiny_mce');
  wp_enqueue_script('jquery-ui-core');
  wp_enqueue_script('jquery-ui-tabs');
  wp_enqueue_script('editor');
  wp_enqueue_script('media-upload');
  add_thickbox();
}

Plusieurs remarques par rapport à ce code :

• Le choix de l’action
  Le mien s’est porté sur admin_menu. Vous pourriez en choisir une autre, du moment qu’elle s’exécute avant admin_head. J’ai choisi celle-là parce que c’est là que j’y construis les menus de l’administration : WordPress est initialisé et n’a pas encore été affiché.
• Le choix wp_enqueue_script
  J’aurais pu caller cette fonction en tant que filtre de admin_head et utiliser la fonction print_script MAIS je soupçonne cette dernière fonction de ne pas vérifier si un autre script du même nom a été inclus.
  J’ai choisi de ne pas créer de conflit : wp_enqueue_script ne chargera qu’1 fois et 1 seule le script nommé. Pas de chichi.
• L’inclusion de l’éditeur
  Pour afficher l’éditeur, il suffira d’appeler la fonction the_editor() en lieu et place de son textarea. Vous noterez toutefois que vous serez obligé(e)s de nommer l’éditeur content sous peine de devoir ajouter quelques filtres supplémentaires.

Après à vous de vous débrouiller avec l’architecture de votre plugin. Personnellement j’ai tout basculé dans des classes depuis un bon moment pour éviter tout conflit de nom.

La solution optimisée

Cependant ne crions pas victoire si vite : avec ce qu’on a fait, nous avons juste réussi à inclure TinyMCE sur toutes les pages de l’admin WordPress. Ce n’est pas ce que je recommanderai pour deux raisons :

1. le respect des performances utilisateurs : charger 150Ko de JavaScript pour rien sur une page sans TinyMCE, c’est du gâchis
2. on ne fait pas une généralité pour une exception

Heureusement pour nous WordPress est bien fichu car il nous fournit 2 variables globales (*hm*) d’exception :

• $plugin_page
  Cette variable contient le nom de la page renseignée par les méthodes add_management_page() et add_options_page(). On aurait pu passer directement par admin_print_script* mais il faisait flemme d’ajouter une fonction de plus.
  Exemple :

  <?php
  add_management_page('Titre', 'Label', 8, 'test_management_page', 'mon_callback');
  //$plugin_page vaudra 'test_management_page'

• $pagenow
  Cette variable contient le nom du fichier actuellement exécuté.
  Si vous vous trouvez sur wp-admin/tools.php?page=test_management_page, $pagenow vaudra tools.php

Avec ces deux variables, on est capable de charger ce qu’on veut, où on veut et quand on veut.

Au final, ça nous donnerait ceci :

<?php
add_action('admin_menu', 'include_tinymce');
function include_tinycme()
{
  global $plugin_page;
  if ($plugin_page === 'test_management_page')
  {
    add_action('admin_head', 'wp_tiny_mce');
    wp_enqueue_script('jquery-ui-core');
    wp_enqueue_script('jquery-ui-tabs');
    wp_enqueue_script('editor');
    wp_enqueue_script('media-upload');
    add_thickbox();
  }
}

Là on a bien terminé le travail.

Conclusion

Il n’y a au final pas grand chose à chose à ajouter pour disposer de TinyMCE. Encore faut-il le savoir.

On peut cependant regretter le manque de flexibilité de cette manipulation :

• j’ai definé la liste des fichiers en cherchant les noms de fonctions JavaScript manquantes (merci Firebug et l’affichage des exceptions en console)
• la liste des dépendances de wp_enqueue_script n’est absolument pas complète : editor devrait appeler wp_tiny_mce et media-upload (voire jquery-ui-*)

Un jour WordPress nettoiera son code pour faciliter la maintenance …

Il existe cependant une méthode alternative reposant sur Subversion (SVN). C’est la méthode idéale pour tout développeur WordPress ou gestionnaire de blogs. C’est celle que j’emploie depuis la version 2.6 grâce notamment à la constante WP_CONTENT.

Explications et application concrète.

Avant toute chose, sachez que ce tutorial est optimisé pour les personnes qui versionnent entièrement leur projet. Il n’est pas question ici d’avoir une arborescence libre et de procéder à des checkout un peu partout. C’est possible mais pas du plus grand intérêt.

L’avantage évident ici est de pouvoir déployer son blog n’importe où en un rien de temps.

Structure des fichiers

Installer WordPress en tant que dépendance SVN revient à mélanger 2 techniques :

• Installer WordPress dans son propre répertoire
  
• Installer WordPress proprement depuis SVN

Je suis pénible donc je n’ai pas spécialement envie de modifier un fichier core ou autre chose que wp-config.php. Tout le contraire de ce qu’indique la première méthode.

La seconde explication m’a toutefois posé légèrement problème puisqu’un peu brutale et posant soucis chez OVH.

Celles et ceux qui voient la capture d’écran ci-dessus peuvent constater que tout WordPress a été déplacé dans un sous-répertoire wordpress au même niveau que wp-content.
On ne garde à la racine que le fichier .htaccess et wp-config.php.

Sur le répertoire racine, j’ai appliqué ces propriétés pour WordPress 2.7 :

• svn:ignore :
  

  wp-config.php

• svn:externals :
  

  wordpress http://svn.automattic.com/wordpress/branches/2.7

Je ne versionne volontairement pas le fichier wp-config.php car c’est le seul fichier susceptible de changer d’une instance à une autre. Je le récupère depuis wordpress/wp-config-sample.php et je le personnalise selon mes besoins.
Et puis versionner des mots de passe … qui y tient ?

Configuration

Après cette restructuration, on aura toutefois besoin de configurer 2-3 bricoles. Vraiment rien de méchant promis.

Le .htaccess

Voici ma configuration. Elle peut être aisément déportée dans votre déclaration de Virtual Host pour des raisons de performance. Sur un serveur mutualisé vous n’avez en général pas accès à ce dernier type de configuration.

<IfModule mod_rewrite.c>
Options -Multiviews -Indexes +FollowSymlinks
RewriteEngine On
RewriteBase /
# Moving to dependency
RewriteRule ^(index.php|wp-[a-z0-9-]+\.php|xmlrpc.php)?$ wordpress/$1 [L]
RewriteRule ^(wp-admin|wp-includes)/(.*)$ wordpress/$1/$2 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . wordpress/index.php [L]
</IfModule>
# BEGIN WordPress
# END WordPress

Ce fichier est très inspiré de la configuration SVN proposée sur le Codex WordPress. Seulement voilà, cette renvoie tout sur index.php … et omet ainsi tous les accès aux fichiers situés à la racine, avec entre autre :

• wp-cron.php
• wp-link-opml.php
• wp-trackback.php
• xmlrpc.php

Je vous fais grâce des contrôleurs de flux (Atom, RSS & cie) et des appels en directs à index.php effectués par certains plugins.

Donc non on ne peut pas vraiment se passer de ces fichiers. D’où ces 2 règles :

• RewriteRule ^(index.php|wp-[a-z0-9-]+\.php|xmlrpc.php)?$ wordpress/$1 [L]
  

  On capte tous les fichiers PHP (les contrôleurs) originellement situés à la racine de WordPress.

• RewriteRule ^(wp-admin|wp-includes)/(.*)$ wordpress/$1/$2 [QSA,L]

  Et là c’est pour le confort de conserver les adresses initiales … mais aussi pour éviter de modifier un bout de paramétrage dans l’admin. Le jour où vous décidez de rebasculer à l’ancien système, ça se fera sans douleur

Enfin, pourquoi avoir poussé les commentaires WordPress vers le bas ? Tout simplement pour éviter que nos règles personnalisées soient écrasées par WordPress lors d’une mise à jour des permaliens. Nos règles primeront toujours ainsi.

Le fichier wp-config.php

Dans le fichier wp-config.php, nous n’allons rien modifier. Nous allons juste ajouter forcer 2 paramètres. Ils indiqueront à WordPress où se trouve le véritable répertoire wp-content (renommable mais je ne jouerai pas avec).

Le blog

Bon j’ai menti un peu toute à l’heure en indiquant qu’on ne toucherait qu’à wp-config.php. Cependant la modification est on ne peut plus mineure et ne concerne que l’upload de medias.

En effet si on ne touche pas à l’emplacement des fichiers envoyés, WordPress considère qu’ils sont uploadés dans wordpress/wp-content/uploads. C’est fort gênant mais heureusement, en préfixant le chemin par ../ ou en tapant un chemin absolu tout rentrera dans l’ordre.

À noter qu’il s’agit du seul paramétrage hors d’un fichier. Si j’avais pu m’en passer je l’aurais fait.

Dépendance SVN pour la traduction

C’est en tombant sur un autre article traitant de svn:externals pour WordPress que j’ai été interpelé sur la prise en charge des langues via SVN également.
Le système n’est pas parfait puisqu’on ne peut gérer qu’une seule langue par ce biais là. Ça ne conviendra donc pas aux blogs multilingues.

La technique consiste à transformer wp-content/languages en svn:externals.
Ça donnerait ceci pour la version française de WordPress 2.7, au niveau du svn:externals du répertoire wp-content :

languages http://svn.automattic.com/wordpress-i18n/fr_FR/branches/2.7/messages/

Simple et efficace mais ça reste encore de la bricole.

Cas particulier : plugins et i18n

Je vous expose le problème mais malheureusement vous ne pourrez pas y faire grand chose. Par contre ami développeurs, pour rendre votre code de plugin 100% portable, merci de prendre note

Le chargement des traductions s’effectue à l’aide de la fonction load_plugin_textdomain(). Elle prenait seulement 2 paramètres jusqu’à l’arrivée de WordPress 2.6. Ça n’a pas été crié sur les toits mais elle prend désormais 3 … et c’est du 3ème argument qu’il faut utiliser désormais :

1. $domain : l’espace de nom des traduction (inchangé)
2. $abs_rel_path : chemin relatif par rapport à l’emplacement de WordPress (déprécié, on y mettait PLUGINDIR.'/'.dirname(plugin_basename(__FILE__)) en général)
3. $plugin_rel_path :  chemin relatif par rapport à l’emplacement des plugins (c’est qui nous intéresse ; dirname(plugin_basename(__FILE__)) nous suffira désormais)

Vous trouverez un exemple sur le Codex, du côté de l’internationalisation des plugins.
Un exemple de code pérenne :

load_plugin_textdomain('votreplugin', dirname(plugin_basename(__FILE__)), dirname(plugin_basename(__FILE__)));

Et si jamais vous utilisez votre plugin en lien symbolique ça ne fonctionnera pas … mais on s’éloigne du sujet

Et pour WordPress Mu ?

Je ne m’attarderai pas dessus mais les manipulations sont sensiblement les mêmes. Je n’ai pas encore eu l’occasion d’essayer mais j’ose imaginer qu’il n’y a pas tant de différences que ça

Conclusion

Le jour où vous souhaitez migrer vers une autre version majeure de WordPress, c’est simple : il suffit de changer les externals vers le tag adéquat.

Pourquoi ne pas utiliser le trunk directement me demanderez-vous ? Le trunk de WordPress est plutôt instable puisque c’est là que se construit la prochaine version de manière systématique. L’utilisation des branches permet de bénéficier des correctifs sans avoir à modifier le moindre external.
Si vous avez un grand besoin de stabilité, alors utilisez les tags qui sont en principe figés.

On remarquera aussi que malgré son âge, WordPress commence à peine à proposer des solutions d’industrialisation.
Les liens symboliques sont en effet très mal gérés. Tentez d’utiliser un seul répertoire source pour plusieurs blogs avec des liens symboliques et tout s’effondre.

La preuve en est aussi avec le manque de ressources disponibles sur le Web et traitant ce sujet. Ça m’étonnerait d’être le premier à vouloir déployer du WordPress via SVN.
Les choses s’améliorent mais pour le côté code is poetry, on en est encore loin.

J’ai eu peur il y a 2 semaines en arrivant à Paris-Web 2008 : en discutant avec plusieurs personnes, il se trouve que peu d’entre elles connaissaient les frameworks CSS. Je craignais de n’attirer personne avec ce sujet lors des ateliers du samedi.

Les frameworks CSS ont été mentionnés la première fois dans la conférence Working in the Now (visualiser la présentation). Au final, on n’était pas loin de faire salle comble avec plus d’une vingtaine de participants à vue de nez.

Une petite scéance de rattrapage s’impose

Pourquoi avoir choisi ce sujet ?

J’ai lu un article sur l’importance du rythme vertical l’an dernier sur Biologeek et ça m’a sensibilisé au fait qu’on pouvait rendre la lecture d’un site tout simplement en rendant prédictible la position du texte.

Entre temps j’ai également lu l’excellent Transcender CSS d’Andy Clarke. J’y ai été sublimé par des présentations de sites totalement en grille.

Depuis je suis devenu fan de Blueprint CSS (je crois que ça s’est remarqué lors de mon intervention ). J’ai commencé à l’utiliser sur des projets personnels puis dans un cadre professionnel. J’utilisais déjà symfony comme framework PHP et jQuery comme framework JavaScript alors pourquoi pas Blueprint ?

Comme le suggérait très justement Christian Heilmann dans sa présentation, l’utilisation d’outils déjà existants est nécessaire pour réduire les coûts de production. C’était déjà un bon alibi mais je les apprécie aussi parce qu’on gagne un temps fou ! On se concentre sur le code métier, pas le reste.

La présentation

Je n’en dis pas plus, je vous laisse lire la présentation. Ayez toutefois en tête qu’en vrai elle dure facilement 1h.

Ce qu’il faut en retenir

J’ai rencontré 2 types de réactions lorsque j’ai parlé des frameworks : les enthousiastes et les réfractaires.

Je ne reviens pas sur les enthousiastes : il suffit de lire ma présentation. Les atouts les ont clairement séduit.
Je m’intéresserai plutôt aux réfractaires. Assez paradoxalement, ce n’est pas dans la salle que je les ai eu mais en dehors. Les principaux arguments étaient :

• ça rajoute des kilo-octets superflus
• on perd le contrôle de notre code
• j’utilise déjà le mini-framework d’un collègue ou qui existait dans mon entreprise avant que j’arrive

Ces arguments sont tout à fait acceptables … mais ça dépend dans quel contexte.

Exemple de mise en forme en grille

Les sites à la recherche de performances exceptionnelles, ceux pour qui un Ko supprimé économise plusieurs Go de bande-passante par jour … oui ceux-là ont un grand intérêt à réfléchir à l’adoption d’un framework, aussi compressé qu’il soit.
Je ne me fais pas de soucis pour eux : en général ils ont leur propre framework, totalement adapté à leur besoin. Cependant ça n’empêche pas d’aller prendre des idées ailleurs et de découvrir de nouveaux concepts. Puis de les intégrer.

Lorsqu’on adopte un outil de développement rapide (RAD), la conception ne se fait plus par rapport à nos habitudes mais par rapport à des principes établis. On ne fait plus forcément comme on veut mais les meilleurs frameworks disposent de fonctionnalités répondant à cette problématique. Le compressor de Blueprint en est un parfait exemple.
Il permet de construire une version de Blueprint adaptée à son besoin, inclut des feuilles de notre choix et compresse le tout en un seul fichier prêt à la mise en production.

Maintenant l’avantage d’un framework c’est qu’une communauté ou un groupe de personnes compétentes en ont la gestion. Ces mainteneurs produisent une documentation, des spécifications et un code suffisamment compréhensible à lire. Ce n’est pas forcément le cas de Joe le développeur à qui on aura demandé 36 choses en même temps.
Je fais davantage confiance à un outil éprouvé avec succès sur des milliers de projets qu’un outil développé sur un coin de bureau, malgré toute la bonne volonté de son concepteur.
C’est également un risque certes mais un bon outil délaissé aura tout de même le mérite de fonctionner … et d’avoir davantage de chances de trouver un repreneur.

Une remarque intéressante a également émergé de l’atelier : faut-il utiliser un framework CSS avant ou après que la créa graphique ait été établie ?
Je réitère ma réponse : l’idéal est que tout soit pris en charge le plus tôt possible. Autrement dit, intégrer les contraintes du framework dès la conception graphique est un gros atout. Le découpage de la maquette n’en sera que facilité et ça évitera tout bricolage.
Certains outils l’ont d’ailleurs bien compris en proposant des supports pour graphistes au format PSD, Visio, Fireworks etc.

Feuilles de dessin pour 960 Grid System

Conclusion

Quoiqu’il en soit, les frameworks CSS sont à mon avis promis à un bel avenir dès lors que les critères d’industrialisation auront débarqué au sein des agences Web.

Aujourd’hui une petite agence a tout à gagner à maîtriser de tels outils et à annoncer qu’elle développera mieux, plus vite et moins cher. Le prix ne fait pas tout : ce sont les outils et la qualité du développement. Tous les frameworks cités sont également des logiciels libres.

J’espère que cet aperçu rapide aura ouvert les yeux à certains d’entre vous. Je suis preneur de vos retours, surtout en entreprise. Ça vaut également pour celles et ceux qui ne sont toujours pas convaincu de l’intérêt des frameworks CSS

Remarque : il y avait 2 ateliers complémentaires à Paris-Web :

• Optimiser ses CSS
• Cascade et héritage : concevoir, organiser, optimiser et maintenir ses feuilles de style

Tout développeur, que ce soit à l’école ou en apprenant sur le tas, écrit du code. J’espère n’avoir perdu personne à ce stade de l’explication

Inconsciemment on cherchera à utiliser un style d’écriture avec lequel on se sent à l’aise, qu’on pourra et saura relire facilement et dans le meilleur des cas, qui pourra être relu par une autre personne sans avoir à engager d’interprète.

Tout développeur tend donc à utiliser des conventions de programmation (coding standards), que ce soit en HTML, PHP, CSS, JavaScript ou même en Cobol. Et utiliser des conventions, c’est bien !

Quelle convention de nommage adopter ?

Avant de choisir une convention, encore faudrait-il savoir quelles conventions existent :

• pas de convention
• convention hongroise
• convention PEAR
• convention symfony
• convention Zend Framework
• convention WordPress (que j’abhorre)
• etc.

Autant dire qu’il y a de tout et pour tous les goûts.
Ce qu’il faut retenir d’une convention c’est qu’elle explicite des règles de développement :

• sur le nommage des éléments
• sur l’indentation des éléments
• sur les structures de contrôle (if, else, tout ça quoi)
• sur la syntaxe des commentaires
• sur la syntaxe de la documentation (le code auto-documenté c’est bon !)
• sur l’organisation des fichiers, éventuellement

C’est pour ça que partir sur une convention parfaite sur le papier mais inapplicable est une vaste fumisterie. L’idéal étant de pouvoir reprendre du code dans un projet sans avoir eu besoin de lire la documentation pour en comprendre l’organisation.

Mon conseil : essayez, choisissez mais ne prenez pas non plus trop laxiste en terme de notation.
Une chose est sure : quand on a essayé une belle

Mes conventions de nommage en PHP

J’avoue, la notation utilisée dans symfony m’a tellement plu que je la réutilise quasiment partout. Ci-dessus, une illustration montrant du code pour un plugin WordPress (en PHP 4 malheureusement …). Elle en présente un bon aperçu.

Notation

J’utilise UpperCamelCase pour le nommage des classes sauf s’il y a un préfixe qui, lui, reste en minuscule.
Exemples : class AmazonWidgetsShortcodes, class sfUploader.

Pour ce qui est méthodes de classes, j’utilise lowerCamelCase. Comme ça on sait qu’on reste dans un objet et c’est pas plus mal.

Enfin, pour les fonctions orphelines, helpers & cie, c’est tout en minuscule séparé par des underscore (un nom particulier à ça ? lowered_and_underscored ? )
Exemple : add_filter()

Indentation

Dans l’indentation il y a 2 camps : celui des espaces et celui des tabulations.

J’ai suivi celui des espaces pour une simple et bonne raison : 1 tabulation a une taille différente selon les éditeurs, que ça soit votre IDE, votre shell ou n’importe quel logiciel de texte. L’idéal est d’avoir un rendu identique dans tous les éditeurs sans paramétrage.

En revanche, là encore je suis mais j’aime, je suis sur une tabulation à 2 espaces : c’est bête mais je trouve ça plus esthétique et on arrive moins rapidement à la limite de 80 caractères.

Cette « limite » n’est que virtuelle mais ouvrez un terminal, 80 lignes par défaut. C’est plus confortable de rester en-dessous de ce nombre. Ceci dit je fais quelques exceptions, des fois

Structures de contrôle

On pourrait résumer à 1 ligne = 1 action et 2 types d’utilisation.

Tout d’abord les structures dans le code à proprement parler :

• un espace entre l’opérateur et la parenthèse ouvrante
• un retour à la ligne à chaque accolade
• pas d’espaces dans les lignes vides (résidus d’indentation)
• systématiquement les accolades, même en cas de ligne unique après l’opérateur
• opérateur ternaire quand ça reste simple, pas trop long et plus lisible

Côté templating en revanche j’utilise la syntaxe alternative de PHP à raison d’un opérateur par ligne :

<ol class="posts">
<?php foreach($posts as $post): ?>
  <li id="post-<?php echo $post->getId() ?>">
    <a href="<?php $post->getPermalink() ?>">
      <?php echo $post->getTitle() ?>
    </a>
  </li>
<?php endforeach ?>
</ol>

Syntaxe de la documentation

Enfin, pour terminer sur la partie PHP, PHPDoc est surpuissante en plus d’être simple à utiliser. Comble du bonheur, sa syntaxe est réutilisable dans d’autres langages.

PHPDoc est le principe du code autodocumenté :

1. vous commentez votre code avec la syntaxe PHPDoc
2. vous générez sa documentation avec le programme PHPDoc (en HTML, PDF etc.)

L’idéal est de documenter en même temps qu’on produit le code. Par principe on revient rarement sur son propre code juste pour le loisir de le décrire, par manque de temps ou par flemme.

Mes conventions de nommage en JavaScript

Ne vous inquiétez pas, je ne vais pas tout recommencer pour JavaScript Je suis à peu près la même logique qu’en PHP à part pour les accolades.

En effet si je conserve un comportement similaire pour les structures de contrôles (1 accolade par ligne) :

• je ne fais pas de retour à la ligne sur les accolades/parenthèse ouvrante d’une fonction/objet anonyme
• je ne fais pas de retour à la ligne après une accolade/parenthèse fermante s’il y a une virgule ou parenthèse après

var OncleTom = {
  age:      25,
  pensee:   function(){
    return this.age * Math.random()
  }
};

Mes conventions de nommage en CSS

Inutile de paraphraser ce que j’ai déjà écris dans mon article sur les bonnes pratiques de codage CSS.

Deux lectures en une oui

Conclusion

Bon au final on voit que ce n’est pas si compliqué que ça d’apporter un brin de rigueur.
On pourra même s’amuser à compléter le tout par la disposition des méthodes et fonctions d ans un fichier par ordre alphabétique (j’en connais un que ça fera sourire ).

Les vues Outline fournissent un plan du code et certains logiciels ne semblent pas disposer d’une fonction de tri. Et au cas où un jour vous n’auriez pas votre IDE favori sous le nez, ça ne mange pas de pain de fonctionner ainsi.

Que l’on travaille seul à plusieurs, et à plus fortes raison dans ce dernier cas, l’utilisation de notations et conventions est un gage de qualité. Ça rend le travail plus facilement interopérable avec d’autres développeurs, plus facile à relire, plus facile à maintenir.

Ça n’empêchera jamais des bugs ou de sortir du mauvais code mais c’est ça, c’est une autre histoire.

Enfin, j’aimerais terminer cet article en écrivant qu’il a fait l’objet d’une chaîne par le Padawan PHPiste Damien Alexandre. C’était l’occasion de faire une réponse qui passe inaperçue

Ça ne m’empêchera en revanche pas de refiler la patate chaude à NicoDePrendreUnCafé, de tenter d’insuffler de l’activité au blog de Xavier Lacot, de Spipifier Gastero Prod, d’extirper une technique ninja pyjama à remouk et pourquoi pas lire avec attention l’avis pythonien de David Larlet ?

Et just for fun, un petit coup d’électrode à un de mes futurs étudiants, Thierry Poinot.

Nous avions dressé un panorama des microformats dans un précédent article intitulé « microformats : republier et donner du sens aux contenus ». Nous avions notamment conclu que leur intégration était rapide, peu coûteuse et surtout bénéfique tant pour le visiteur que pour la visibilité du contenu.

Nous nous intéresserons cette fois-ci à une partie plus pratique des microformats : leur intégration. Toutefois ce rapide apprentissage sera didactique puisque nous apprendrons à identifier visuellement quels contenus d’une page peuvent être microformatés mais aussi comment microformater du code HTML déjà existant.

Des sites déjà microformatés

Intéressons-nous toutefois à des sites ayant déjà microformaté leurs contenus. Nous pourrons ainsi éveiller notre curiosité et préparer le travail de réflexion de la prochaine étape.

Exemple avec Google Maps :

Google Maps est un service de recherche cartographique accessible via un simple navigateur Web. Le moteur donne un accès à des recherches de lieux, de calculs d’itinéraires mais aussi d’emplacement d’entreprises.

Le support des microformats sur Google Maps est relativement léger mais suffisant pour être utile.
Contrairement à ce que l’on aurait pu penser, Google n’a pas intégré le microformat geo pour exporter les coordonnées GPS d’un point. La société s’est concentrée sur les données personnelles au moyen de deux microformats combinés :

• microformat hCard (correspond à la réunion des encadrés bleu et vert)
• microformat adr (correspond à l’encadré vert uniquement)

Cette combinaison facilite l’extraction des adresse postales et des entités (individus ou entreprises).

Exemple avec Yahoo ! Upcoming :

Yahoo ! Upcoming est un service gratuit cataloguant tous les évènements à venir par pays, ville, date et même par catégories (cinéma, concerts, expositions etc.).

Le microformat par excellence à adopter était bien évidemment le microformat hCalendar. Chaque occurence microformatée est représentée par un rectangle vert et peut contenir ces différents attributs, entre autre :

• date de début de l’évènement
• date de fin de l’évènement
• titre de l’évènement
• description de l’évènement
• le lieu de l’évènement (sous forme d’adresse complète ou pas)
• une URL menant à un descriptif plus approfondi de l’évènement

Ce microformatage permet d’aller au-delà d’une lecture classique puisque de manière simple, elle permet au visiteur de récupérer les évènements qui l’intéresse pour les ajouter à son gestionnaire de temps favoris, qu’il soit logiciel ou en ligne.

Identifier visuellement les microformats à intégrer

Identifier des microformats déjà implémenté est assez simple avec les outils adéquats. En revanche pour décider de microformater du contenu, deux outils sont indispensables :

• la documentation des microformats pour savoir quoi implémenter
• un peu de jugeotte pour savoir comment implémenter

Avec un peu de pratique et de connaissance des différents microformats, il ne faut pas plus de 5 à 10 minutes pour identifier les contenus microformatables. La difficulté d’intégration dépendra uniquement de la structure technique affichant les données : plus elle sera complexe, plus le microformatage pourra être long … au même titre que toute autre modification basique.

Exemple avec Wikia Search :

Wikia Search est un moteur de recherche lancé au tout début de l’année 2008 par un des fondateurs de l’encyclopédie en ligne Wikipédia. Ce moteur en reprend d’ailleurs le principe du wiki pour contribuer à l’élaboration et la notation de meilleurs résultats.

Il est d’ailleurs étonnant de voir qu’aucun microformat ne soit présent malgré de tels objectifs. La capture d’écran ci-dessus découpe la page en 3 zones microformatables distinctes :

1. le lien sur logo aurait pu se voir agrémenter d’un rel-home pour signifier un retour vers la page d’accueil ;
2. les résultats auraient pu quant à eux embarquer :
   • le microformat hAtom pour faciliter la syndication de contenu et l’extraction des résultats.
   • le microformat hReview ou VoteLinks sur les encadrés orangés identifiant les zones de votes.
3. enfin le microformat hCard aurait été le bienvenu sur la liste des résultats correspond à des personnes.

On peut constater que plus il y a d’emplacement représentant des contenus différents sur une page, plus on a de chances qu’un microformat corresponde.

Exemple avec Clever Age :

J’ai dénombré pas moins de 5 zones pouvant accueillir des microformats :

1. les dernières actualités pourraient utiliser le microformat hAtom. Un flux RSS est déjà disponible sur la page mais ce serait offrir un chemin de traverse pour les visiteurs et les moteurs d’indexation ;
2. le microformat hCalendar aiderait à la réutilisation des données dans les gestionnaires de temps. Imaginez un chef d’entreprise affairé désireux de transmettre à ses collaborateurs une ressource contenant toutes les informations de leur future formation : peu d’effort et un gain de communication ;
3. ajouter facilement Clever Age dans votre carnet de contacts et de prestataires serait également facilité si le microformat hCard redistribuait le nom et les moyens de contact de la société ;
4. en complément au moyen de contact, l’emplacement géographique des agences serait à portée de clic avec le microformat geo. Après tout, Google Maps proposera peut-être un jour d’importer des URL microformatée en plus des fichiers KMZ (Google Earth) ;
5. enfin, le microformatage de la dernière partie dépend de ce qu’on aimerait redistribuer :
   • le microformat hAtom pour offrir 3 flux de syndication mais le peu d’éléments (2 à chaque fois) tende à infirmer la pertinence de ce microformat dans le cas présent ;
   • le microformat XOXO est adapté à décrire des types de contenus embarqués dans une page ; ici des flux RSS. Il serait à placer sur chaque lien pointant vers les flux RSS ;
   • le microformat Xfolk est adapté aux collections d’URL plus communément appelés « favoris » ou « marque-pages »

Avec ce dernier exemple, nous venons de voir que le microformatage était facilement adaptable à un site Web de société. Dans ce cas précis, il y a énormément de contenu republiable mais pas systématiquement de manière pertinente.

Intégrer les microformats dans du (X)HTML

Les précédents exemples, sur de l’existant et ce qui pourrait exister, avaient pour but de former notre esprit à reconnaitre des zones susceptibles d’être microformatées.

La difficulté de l’exercice est d’ajouter du balisage sans altérer la présentation actuelle. Je traiterai du site de Clever Age dont nous avons parlé précédemment.

Microformater des données d’entités

Voici le code de départ, repris tel quel :

Clever Age - Siège social : 01.53.34.66.10

Comme nous avons pu le voir, la gestion d’identités passe par le microformat hCard :

<span class="vcard">
<span class="fn org">Clever Age</span> - Siège social : <span class="tel"><span class="value">01.53.34.66.10</span></span>
</span>

La balise span est une balise en-ligne neutre au sens où … n’en a pas justement. div est son pendant de type bloc.

Microformater des ressources syndiquées
Voici le code de départ (simplifié par rapport à l’exemple afin de réduire le code à lire) :

<dl>
<dt><a href="/rss/blog.xml">derniers billets du blog</a></dt>
<dd>...</dd>
<dt><a href="/rss/publications.xml">dernières publications</a></dt>
<dd>...</dd>
<dt><a href="/rss/cleverlink.xml">derniers Clever Links</a></dt>
<dd>...</dd>
</dl>

Le microformat XOXO nous permet de définir une liste d’éléments en fonction des modules XHTML :

<dl class="xoxo">
<dt><a href="/rss/blog.xml" rel="feed" type="text/xml">derniers billets du blog</a></dt>
<dd>...</dd>
<dt><a href="/rss/publications.xml" rel="feed" type="text/xml">dernières publications</a></dt>
<dd>...</dd>
<dt><a href="/rss/cleverlink.xml" rel="feed" type="text/xml">derniers Clever Links</a></dt>
<dd>...</dd>
</dl>

Le microformatage a été rendu possible uniquement en utilisant de manière standardisée des attributs définis par XHTML.
Malgré cet aspect de simplicité, il faut s’investir dans la compréhension des spécifications XHTML. Ce n’est un problème que pour les personnes produisant du code XHTML non-conforme.

Valider l’intégration des microformats

La question qui se pose toujours après avoir produit un code quelconque c’est comment le tester ? Il existe à l’heure actuelle trois outils gratuits :

• la relecture manuelle avec la documentation à côté
• l’extension Operator pour Firefox. Elle n’est toutefois pas complète et ne permettra pas de tester tous les microformats existants. Cette extension propose dans ses options un mode débogage très utile ;
• le service en ligne Optimus. Ce service polyvalent est capable de retourner sous forme de flux XML ou JSON les microformats présents dans une page Web. Il propose également un validateur, toujours pour une page Web, décrivant les erreurs de microformatage.

Conclusion

Il est difficile d’infuser en un article la manière de microformater du contenu. Fort heureusement la documentation des microformats abonde d’exemples en traitant des cas de figure concrets. Les spécifications restent là pour savoir quels sont les attributs, obligatoires ou pas.

De manière générale l’intégration des microformats est relativement aisée mais il existe 3 difficultés principales à l’intégration des microformats :

• difficultés liées à la plate-forme technique d’intégration ;
• difficultés liées à un manque de données. Certaines spécifications exigent la présence de données particulières que l’on n’a pas ou que l’on ne peut afficher, rendant invalide le contenu ;
• difficultés liées à un code HTML désorganisé. L’abus de div et le non-respect de hiérarchie est une source de problèmes et si elle rend pénible l’intégration des microformats, elle pose problème à la maintenance du code et des CSS.

Intégrer les microformats c’est finalement mener une réflexion sur la qualité du code produit. Un bon code, respectueux des standards et sémantique sera pérenne dans le temps, facilitera le microformatage et aura davantage de chances d’être accessible.

J’y songeais mais l’article «De l’ordre, que diable !» m’a incité à m’y atteler plus tôt que prévu.
Il n’y a en effet pas de méthode universelle pour programmer les CSS mais après plusieurs années d’expérience, j’ai affiné ma réflexion que je vous livre aujourd’hui.

Où l’on parlera de présentation en 1 ligne, de CSSDoc mais aussi de folding et d’indentation. En clair, tout plein de bonnes pratiques de développement en CSS qui vous feront gagner du temps, vous éviterons de la sueur et sentent bon le travail de qualité.

Halte là et retour à la ligne !

J’ai utilisé pendant un moment la technique dite du single line CSS ; à savoir 1 ligne par déclaration.
Je n’hésiterai pas une seconde à dire que je déconseille fortement cette écriture pour les raisons suivantes :

• si on souhaite gagner de la place, il y a des compresseurs (je recommande YUI Compressor): pas la peine de réaliser ce travail nous-même ;
• l’ajout de commentaires n’en est que plus compliqué : on a tous besoin de commenter certains passages cruciaux, notamment les hacks et autres fix ;
• c’est tout bonnement illisible dès qu’on s’y replonge quelques semaines plus tard : imaginez pour quelqu’un qui n’a pas écrit le code !

Les arguments avancés pour cette technique ne tiennent pas la route : on recherche avant tout la qualité et la facilité de relecture. Les quelques kilo-octets à perdre se feront par le biais de programmes. Ça ne doit certainement pas entraver le développement.

L’auto-documentation avec la syntaxe CSSDoc

Les habitués de Java connaissent JavaDoc.
Les habitués de PHP connaissent PHPDoc.
Les habitués de JavaScript connaissent JsDoc Toolkit (dérivé de JsDoc).

Il était donc tout naturel que cette syntaxe de commentaires et d’auto-documentation soit utilisable en CSS avec CSSDoc. Il n’y a pas d’inconvénient à l’utiliser, au contraire, que des avantages :

• la syntaxe permet d’harmoniser les commentaires sur les projets impliquant plusieurs développeurs ;
• sa syntaxe facilite la relecture puisqu’elle est connue et employée dans de nombreux langages, autres que les CSS ;
• l’auto-documentation du code c’est faciliter la génération d’une documentation externe en automatisant le processus ;
• documenter en même temps que l’on écrit c’est comprendre ce que l’on fait et gagner du temps en évitant une écriture a posteriori ;

La syntaxe CSSDoc est documentée, aisément reconnaissable et est supportée par les meilleurs éditeurs CSS, dont Aptana IDE :

/**
 * @author Oncle Tom
 * @lastmodified Fev, 26 2008
 * @media print, screen
 * @site http://www.oncle-tom.net/
 */
/**
 * Redéfinition des balises HTML
 *
 * @section html
 * @todo utiliser un reset.css conforme
 */
html,
*{
  margin: 0;
  padding: 0;
}

L’organisation hiérarchique

J’ai pour habitude de travailler avec une seule feuille de style par media. Comme je travaille sur des hiérarchies thématiques, leur découpage en plusieurs fichiers ne consiste qu’à du copier/coller. On peut ainsi facilement passer d’une mono-feuille à du multi-feuilles. Je ne suis pas un fervent utilisateur de ces dernières car un code bien lisible sur une seule page n’est pas problématique.
Je ne l’emploie que pour faciliter la réutilisation des CSS sur plusieurs projets partageant la même base graphique.

Concrètement, je vais d’abord organiser ma feuille pour redéfinir les éléments HTML génériques puis créer autant de sections qu’il n’y en a sur ma page (navigation, contenu, navigation de contenu, contenus annexes etc.).
Plus je m’avancerai dans la profondeur du balisage HTML et plus j’indenterai mon code. Cette indentation fait penser à celle utilisée par le langage Python.

On pourrait résumer cette convention à ceci :

• pas de tabulation, que des espaces pour avoir le même affichage peu importe les éditeurs
• 2 espaces par tabulation
• attributs classés par ordre alphabétique (même logique pour tout le monde)
• une ligne d’espace entre les définitions ; pas de ligne entre les définitions proches/liées

C’est simple et voici un exemple de résultat :

/**
 * Redéfinition du HTML
 */
a{
  text-decoration: underline;
}
  a img{
    border: none;
  }
p{
  line-height: 1.5em;
}
  p img{
    margin: 1.5em
  }
  p img.top{
    margin-top: 0;
  }
/**
 * Contenu
 */
#main-content{
  clear: both;
  width: 100%;
}
  /**
   * Articles
   */
  #articles{
    margin-bottom: 2em;
  }
    #articles h2{
      font-size: 1.5em;
      font-weight: bold;
    }

Les mieux organisés d’entre vous ajouteront un tri par fréquence d’utilisation afin d’optimiser les va-et-vient : on met en haut ce qu’on est susceptible de modifier le plus souvent, en bas ce à quoi on touchera rarement. Je ne vais pas jusque là mais ça reste envisageable, pertinent et surtout adapté aux plus chevronnés de l’optimisation.

Autres conseils et astuces

Utilisation de raccourcis

Les aficionados de l’optimisation et du gain de temps apprécieront cette méthode, s’ils ne l’utilisent pas déjà. J’ai pour habitude de placer des raccourcis dans mes sections pour faciliter l’utilisation d’une recherche via le raccourci clavier Control+F.
Je préfixe chaque raccourci d’un symbole = :

/**
 * Liens d'évitement
 * =evitement
 */

Je trouve cette méthode très pratique pour atteindre des portions de code. On évite ainsi un appel à la touche Alt Gr pour appuyer sur le # d’un ID (pour peu que l’on n’ait que des ID en tant que sections). On évite aussi les collisions de nom ou les recherches infructueuses pour cause de changement de nom de classes ou d’ID.

De la sémantique, que diable !

Je suis particulièrement attaché à cette bonne pratique d’autant plus qu’elle ne tombe pas forcément sous le sens de tout le monde : nommez vos ID et classes en fonction de leur signification, pas de leur représentation. C’est la suite logique de la séparation fond et forme du HTML et des CSS.

Mauvaise sémantique :

.rouge{
  color: red;
}
#sidebar{
  /* ... */
}
#top-links{
  /* ... */
}

Bonne/meilleure sémantique :

.important{
  color: red;
}
#alternate-navigation{
  /* ... */
}
#main-links{
  /* ... */
}

#sidebar pourra être renommé différemment selon son contenu, selon que l’encart contienne des éléments de navigation supplémentaires, des informations utilisateur (#user-content) ou encore des widgets (#widgets).
En conservant votre HTML intact et en jouant sur les CSS, la #sidebar peut en effet se retrouver tout en bas, à l’horizontale. Aurez-vous toujours envie de l’appeler pareil ? Pas forcément. Un bon nommage est un nommage qui se conserve peu importe l’aspect de la présentation.

Du choix de la langue

Cette bonne pratique s’applique aussi bien aux CSS qu’à d’autres langages. Il faut partir du principe qu’il ne faut pas mélanger les langues dans le code, tant dans les commentaires que dans le nommage des classes et ID. Choisissez-une langue et restez avec.
Certaines contraintes peuvent faciliter le choix de la langue : le travail avec une équipe internationale ou la redistribution du code. Dans ce cas l’anglais sera à 99% votre langue de prédilection.

Il n’y a pas de choix idéal : certains préféreront le tout français, d’autres le tout anglais. L’essentiel est que ce choix soit motivé par des arguments objectifs, pas une préférence personnelle.

Recours au folding

J’en parle succintement mais le folding consiste à utiliser votre éditeur CSS pour masquer une partie de code. Eclipse propose par exemple de masquer toutes les définitions et tous les commentaires : leur contenu n’est révélé qu’en le dépliant.

Je ne suis pas un fervent utilisateur de cette pratique bien que je respecte son utilisation. Je trouve qu’en utilisation les précédentes astuces (hiérarchie + recherche) on s’y retrouve très bien.

Conclusion

Ma méthodologie n’est pas parfaite, peut être perfectible et ne conviendra pas à tout le monde, par goûts ou par habitudes. Ces dernières sont cependant à combattre pour améliorer son travail. Quoi de mieux qu’un code propre, bien documenté et où l’on trouvera facilement ce que l’on cherche ?

C’est ce qui importe. Il y a autant de façons de coder qu’il n’y a de développeurs. Le tout est d’être ouvert aux améliorations possibles, aux méthodes existantes et à l’intérêt de leurs utilisations. Je trouverai peut-être cet article obsolète dans 1 an mais il aura été un point de passage.

J’espère qu’il le sera au moins en partie pour vous, développeur en herbe ou féru des pseudo-classes

Ca peut sembler inutile à première vue lorsqu’on utilise MySQL au travers d’API d’autres langages (PHP, Perl, C# etc.). Et pourtant ça peut vous être très utile pour économiser des requêtes, du temps à programmer ces boucles et puis surtout, par flemme.

Oui, la flemme est pour moi la qualité numéro un du développeur car le flemmard a pour but d’arriver à ses fins en un minimum d’efforts.

Déclaration de variables

On peut déclarer une variable de deux façons dans MySQL.
La première méthode consiste à utiliser l’opérateur SET.

SET @pierre = 3, @feuille = 3 + 2, @ciseau = @pierre % @feuille ;

On peut également consister une variable à partir d’une requête.

SELECT @nb_total := COUNT(*) FROM `ma_table` ;

Note : dans ce cas là, on préfixe l’opérateur = de : (deux points).

Utilisation simple des variables

L’utilisation première qui peut en être faite c’est d’assainir vos requêtes SQL en évitant au maximum l’apparition de variables issues d’autres langages.
Avant :

SELECT * FROM `ma_table` WHERE colonne1 = {$variable1}, colonne2 = '{$variable2}' LIMIT 1;

Après :

SET @variable1 = {$variable1}, @variable2 = '{$variable2}';
SELECT * FROM `ma_table` WHERE colonne1 = @variable1, colonne2 = @variable2 LIMIT 1;

Comme les variables sont effectives pour la connexion courante, une variable MySQL peut être réutilisée à tout moment. De quoi décomplexifier certains scripts pas forcément bien structurés.

Utilisation complexe des variables

Les variables peuvent également être modifiées à même la requête. C’est à dire qu’à chaque itération effectuée par MySQL, le moteur va réévaluer le contenu de la variable. J’ai notamment eu besoin de ça pour ajouter de nouveaux éléments à la suite d’autres tout en renumérotant leur ordre. Je souhaitais éviter une boucle récursive en PHP qui aurait occasionné de multiples requêtes.

Je dispose d’une table (item_liste) avec plusieurs éléments, une clé primaire sur deux champs (item_id et item_cat) ainsi qu’un autre champ indexé permettant de les trier dans un ordre donné (item_ordre). Le but : prendre des éléments de la catégorie 1 pour les mettre à la suite de la catégorie 2.

Voici en gros ce que ça donne au final :

SELECT @ordre := IFNULL(MAX(item_ordre), 0) FROM `item_liste` WHERE item_cat = 2 ;
UPDATE `item_liste` SET item_ordre = @ordre := @ordre+1, item_cat = 2 WHERE item_cat = 1 ;

1. On compte la borne supérieure de la catégorie 2. Pourquoi un IFNULL ? Parce MAX() retournera NULL si un des item_ordre en contient un. C’est une sécurité ;
2. On met à jour les éléments de la catégorie 1 avec leur nouvel ordonnancement et leur nouvelle catégorie.

Alors pourquoi ça fonctionne ? La commande UPDATE balaie les lignes une par une et du coup, met à jour la variable @ordre à chaque ligne. Nous retrouvons ainsi l’effet désiré : incrémenter chaque ligne déplacée dans la nouvelle catégorie.

Il existe des utilisations plus compliquées que celles-là mais je pense que c’est un bon départ pour se faire une idée de ce qui est faisable par ce biais là. L’imagination et les besoins feront le reste

Voici donc mon constat de départ :

• un client doit pouvoir saisir un seul article s’il le veut
• un client doit pouvoir saisir 10 articles s’il le veut
• un client doit pouvoir saisir 100 articles s’il le veut
• mais celui qui n’en saisit que 10 ne doit pas être gêné par 100 lignes de formulaire à remplir
• un débutant doit pouvoir saisir 100 lignes sans avoir de mode d’emploi sous la main

Donc ma solution a été très simple : je ne mettrai qu’une ligne.

L’idée

Comment faire pour satisfaire tout le monde, les gros donneurs d’ordre comme les petits ?
En faisant en sorte que le formulaire s’adapte à leur besoin. Je voulais donc qu’à chaque ligne complétée s’en ajoute une autre avant de passer à la validation finale. Place au combo JavaScript + DOM = Ajax.

La version dégradée

Une bonne pratique de l’Ajax est de partir du cas particulier : celui où les conditions ne sont pas requises. En clair, une personne qui n’a pas JavaScript d’activé ou pas de JavaScript tout court.
Conclusion, j’ai décidé de générer un tableau en HTML de 10 lignes. 10 est un choix arbitraire, modifiable à tout moment et qui ne doit donc pas gêner la version dynamique en cas de changement (ajout de colonne, ajout de lignes).

La version Ajax

On peut manipuler le document à loisir grâce à JavaScript. Avec un code propre et ordonné c’est d’autant plus simple. Alors voici la logique à mettre en oeuvre :

1. éliminer toutes les lignes dont on ne veut pas et n’en garder qu’une
2. assigner à chaque champ de formulaire de la ligne (input, select, textarea) une fonction de vérification : si tous les éléments de la ligne sont remplis / cochés et qu’il n’y a pas de ligne après, on clonera la ligne
3. cloner la ligne en la vidant de ses valeurs, en modifiant les noms de champ pour les rendre exploitable après coup

Ce qu’on l’on veut étant relativement simple, le code doit l’être également ! Le résultat aussi, la preuve en mouvement.

Au final, 50 lignes de JavaScript ont suffit à transformer un tableau complètement statique en tableau dynamique, s’adaptant à la demande de n’importe quel client. Client qui pourra également utiliser le clavier pour davantage d’efficacité de saisie.

C’est à dire exactement ce que l’on souhaitait au départ.

Le code

Le tableau HTML

<table cellspacing="0" id="ajout_multi_articles">
  <thead>
    <tr>
      <th>Code article</th>
      <th>Quantité</th>
    </tr>
  </thead>
  <tbody>
    <tr class="article">
      <th><input type="text" name="article[1][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[1][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[2][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[2][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[3][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[3][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[4][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[4][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[5][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[5][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[6][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[6][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[7][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[7][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[8][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[8][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[9][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[9][qte]" maxlength="5" size="5" /></td>
    </tr>
    <tr class="article">
      <th><input type="text" name="article[10][ref]" maxlength="10" /></th>
      <td><input type="text" name="article[10][qte]" maxlength="5" size="5" /></td>
    </tr>
  </tbody>
</table>

La fonction JavaScript

/**
 * Transforme un tableau multi-lignes en un tableau mono-ligne mais auto-extensible
 * Renomme également les noms de champ en suivant un masque paramétrable ; par défaut article[]
 *
 * @usage articlesMultiRows([{'css_id': ?, 'css_row_class': ?, 'check_inputs': ?}])
 * @param {Object} params Objet contenant (ou pas) les paramètres de contrôle de la classe
 */
function articlesMultiRows(params)
{
  this.row_number = 0;
  /*
   * Extension des paramètres par défaut
   */
  var params = params || {};
  params.css_id = params.css_id || 'ajout_multi_articles';
  params.css_row_class = params.css_row_class || 'article';
  params.check_inputs = params.check_inputs || 'input,select,textarea';
  /**
   * Initialise le tableau de données et accroche les méthodes dynamiques
   */
  this.init = function(){
    //aucun ID détecté, pas la peine de continuer plus loin
    if (!$(params.css_id))
    {
      return false;
    }
    //on récupère les lignes, on enlève la première du tableau et on supprime les autres
    var rows = $(params.css_id).getElements('tr.'+params.css_row_class);
    var row_first = rows.shift();
    rows.removeElements();
    rows = null;
    /*
     * On assigne l'évènement aux champs paramétrés de la ligne
     * On place le focus sur le premier champ
     */
    $ES(params.check_inputs, row_first).addEvent('blur', rowCheck);
    $(row_first).getElement('input').focus();
    row_number = 1;
    /*
     * On écrit un petit message sympathique indiquant le fonctionnement du bazar
     * On le fait via JavaScript car un utilisateur sans JS ne pourrait justement pas suivre les infos
     * Il est placé juste avant le tableau
     */
    new Element('p',{
          'class' : 'message'
          }).setHTML("Dès qu'un code article et une quantité sont saisis ci-dessous, <strong>une nouvelle ligne s'ajoute automatiquement</strong>.<br />Afin d'accélérer votre saisie, <em>utilisez la touche de tabulation de votre clavier</em> pour passer d'un champ à l'autre. Vous verrez, c'est facile et surtout efficace !").injectBefore(params.css_id);
  };
  /**
   * Vérifie si la ligne a entièrement été complétée et le cas échéant, déclenche l'ajout de ligne
   */
  this.rowCheck = function(){
    var row = { 'inputs' : 0, 'completed' : 0, 'dom' : $(this).getParent().getParent() };
    $ES(params.check_inputs, row.dom).each(function(input){
      //Un élément de plus ...
      ++row.inputs;
      //... dont on vérifie s'il est bien complété
      switch (input.getTag())
      {
        case 'input':
        case 'textarea':
          if (input.value.clean())
          {
            ++row.completed;
          }
        break;
        case 'select':
          if (input.selectedIndex >= 0 && input.selectedIndex < input.length)
          {
            ++row.completed;
          }
        break;
      }
    });
    /*
     * Pour insérer une nouvelle ligne, on doit avoir :
     * - autant de champs complétés que de champs existants
     * - aucun élément suivant
     */
    if (row.inputs === row.completed && !row.dom.getNext())
    {
      rowInsert(row.dom);
    }
  };
  /**
   * Insère une nouvelle ligne en clonant la dernière du tableau et la purgeant de ses valeurs
   *
   * @param {Object} row Noeud DOM correspondant à la ligne à cloner
   */
  this.rowInsert = function( row ){
    //On incrémente le nombre de lignes dispo
    //Ce numéro sert à changer les masques de nom de champ
    ++row_number;
    var row_clone = row.clone();
    //Clonage de la ligne
    $ES('input[type=text],input[type=password],input[type=hidden],textarea', row_clone).setProperty('value', '');
    $ES(params.check_inputs, row_clone).removeEvents('blur'); /* obligé car IE5+ clone aussi les évènements ... alors qu'il ne le devrait pas */
    $ES(params.check_inputs, row_clone).addEvent('blur', rowCheck); /* oui oui, IE5+ ne rassignait pas cet évènement comme il fallait malgré ça */
    //On remplace les noms des champs pour que permettre une utilisation des résultats $_POST
    $ES(params.check_inputs, row_clone).each(function(input){
      input.name = input.name.replace(new RegExp('^'+params.css_row_class+'\[[0-9]+\]'), params.css_row_class+'['+row_number+']');
    });
    //Injection de la ligne, une fois tout le travail terminé
    row_clone.injectAfter(row);
    //Nettoyage, le clonage, ça salit
    row_clone = null;
    row = null;
  };
  /*
   * Initialisation de la classe
   */
  this.init();
}
/*
 * Initialisation du tableau multi-lignes avec les options par défaut
 */
window.addEvent('domready', articlesMultiRows);

Et généralement on se confronte au problème du cache des navigateurs Web. Ces derniers conservent en mémoire les feuilles de style pendant un certain temps causant ainsi un décalage entre le fichier CSS du serveur (et la présentation souhaitée) et celui du navigateur (reposant sur une présentation obsolète).

Inclure une feuille de style

L’inclusion d’une feuille de style au sein même de la page n’est pas une opération qui devrait vous poser trop de problèmes. Elle peut se faire de deux façons, la première étant compatible avec tous les navigateurs, la seconde seulement avec les navigateurs modernes.

/* inclusion "old school" */
<link rel="stylesheet" type="text/css" href="url/style.css" media="screen" />
/* inclusion "moderne" */
<style type="text/css">@import url('url/style.css') screen;</style>

Inclure une feuille de style avec mise à jour automatique

Vous allez voir, c’est tout bête. On reprend l’exemple précédent ; on veut conserver le même nom de fichier mais il a été mis à jour et on souhaite que le navigateur le recharge sans que l’utilisateur ait à faire un petit F5 sur son clavier.

/* inclusion "old school" */
<link rel="stylesheet" type="text/css" href="url/style.css?v=1234" media="screen" />
/* inclusion "moderne" */
<style type="text/css">@import url('url/style.css?v=1234') screen;</style>

Vous voyez le v=1234 ? Le fait d’ajouter un paramètre au fichier appelé dupe le navigateur et lui fait croire qu’il s’agit d’un fichier différent de style.css. En réalité on peut mettre n’importe quoi en paramètre (le timestamp de mise à jour du fichier par exemple. Par exemple style.css?1180077252).

Pourquoi ça fonctionne ?

Dans une URI, le chemin physique du fichier s’arrête juste avant le ?. Tout ce qui est inscrit après est considéré comme étant des paramètres, compléments virtuels du-dit fichier. Ce qui importe au navigateur, c’est que le fichier en question renvoie bien des données dans le type MIME attendu, ici text/css.

Le navigateur gère le cache d’un fichier par rapport à son adresse complète, ceci incluant les paramètres fournis. Pour lui, style.css?v=1 et style.css?v=2 sont deux fichiers différents, peu importe s’il s’agit en réalité du fichier style.css.
En cas de changement de paramètre, le navigateur estime qu’il s’agit d’un nouveau fichier, récupère celui-ci et, magie, utilise la dernière version en date de celui-ci plutôt qu’une version en cache, obsolète.

Cette petite astuce permet de gagner en crédibilité face à des clients, évite aux internautes d’être perdus dans un affichage incohérent misant fortement sur les feuilles de style.
Exactement ce que l’on recherchait