La Case de l'Oncle Tom » bonne pratique

WordPress en tant que dépendance SVN

Oncle Tom — Tue, 23 Dec 2008 06:00:59 +0000

Mettre à jour WordPress était pénible jusqu’à l’arrivée de la version 2.7. On bénéficie désormais de la mise à jour automatique : un clic, ça télécharge et ça déploie.

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 :

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.


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]

# 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 :

$domain : l’espace de nom des traduction (inchangé)
$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)
$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.

Configuration d’Apache, MySQL et PHP à base de liens symboliques

Oncle Tom — Thu, 11 Dec 2008 06:00:50 +0000

J’ai récemment passé mon poste de développement de Debian Testing vers Ubuntu 8.10. Comme toute installation from scratch, il faut passer par la case configuration.

J’ai déjà expliqué comment modifier l’emplacement des données d’un serveur MySQL mais cette fois-ci on va aller encore plus loin :

on ne va pas toucher aux fichiers de configuration par défaut
on va pouvoir conserver toute notre configuration sur une partition séparée
on va être tranquille pour les éventuelles futures réinstallations

C’est pas très compliqué à mettre en œuvre et au final, tout le monde y gagne !

Organisation du répertoire /home

Le titre de l’article le suggère bien, cet article se consacre à la configuration des serveurs et programmes suivants :

Apache 2
PHP 5
MySQL 5
AppArmor (installé et activé par défaut depuis Ubuntu 8.04)

Pour des raisons évidentes de facilité, j’ai donc créé un répertoire qui rassemble toutes mes configurations spécifiques. En voici son arborescence :

~/config
- /apache2
  - sites-available
    - 000-default-custom
    - local.monprojet.com
    - etc.
- /apparmor
  - usr.sbin.mysqld-custom
- /mysql
  - my-custom.cnf
- /php5
  - php-custom.ini

Nous écrirons dans ces fichiers uniquement les points de configuration que l’on souhaite adapter. C’est plus simple à maintenir. Qui plus est, si les fichiers de configuration sont mis à jour par leur serveur respectif, nos fichiers resteront à l’abri.

Un des moto de Debian c’est la configuration à base de fichiers. Vous trouverez régulièrement des répertoires ayant un nom suivant le motif application.d. Donc plutôt que d’avoir 1 seul fichier de configuration, on a 1 fichier initial plus des configurations additionnelles dans ces fameux répertoires « .d ».

Configuration d’Apache

Pour Apache la démarche est la suivante :

créer les Virtual Host dans son répertoire personnel
lier les fichiers dans sites-available
activer les sites à l’aide de la commande a2ensite
recharger Apache

La seule étape par rapport à d’habitude c’est qu’on ne crée par les Virtual Host directement dans /etc/apache2/sites-available et qu’on les lie depuis notre répertoire personnel.
Admettons que je souhaite créer un Virtual Host pour une instance locale de mon blog. Je vais procéder ainsi :

gedit ~/conf/apache2/sites-available/local.case.oncle-tom.net
J’y ai placé une configuration somme toute minimaliste :


ServerName local.case.oncle-tom.net
DocumentRoot /home/oncletom/workspace/case.oncle-tom.net
ErrorLog /var/log/apache2/error.case.oncle-tom.net.log
LogLevel warn
CustomLog /var/log/apache2/access.case.oncle-tom.net.log combined
ServerSignature On

sudo ln -s ~/conf/apache2/sites-available/local.case.oncle-tom.net /etc/apache2/sites-available/local.case.oncle-tom.net
sudo a2ensite local.case.oncle-tom.net
sudo service apache2 reload

On se fendra de l’ajout d’un hôte local dans le fichiers hosts pour coller au plus près à l’instance de production. Toutefois je ne connais pas d’autre moyen que de modifier le fichier d’origine :-/ Si vous avez une solution je suis preneur.

Configuration de MySQL

Pour MySQL c’est un peu plus compliqué car on va également en profiter pour déplacer l’emplacement par défaut des données. Pourquoi ? Pour les placer sur une partition qui ne craindra pas les formattages et les réinstallation système.
Si vous aviez déjà suivi ma procédure de déplacement des données MySQL : oubliez là. Celle-ci est largement plus aboutie.

Avant de se jeter à corps perdu dans les manipulations, voici la démarche entreprise :

créer le fichier de configuration MySQL
créer le répertoire qui accueillera les données MySQL
lier la base mysql d’origine
modifier la configuration d’AppArmor
recharger la configuration des serveurs AppArmor et MySQL

C’est déjà un peu plus long mais là encore, il n’y a pas grand chose à faire en fin de compte :

gedit ~/conf/mysql/my-custom.cnf
On y indique le nouvel emplacement de ses données MySQL :
```
[mysqld]
datadir            = /home/oncletom/Apps/mysql
```
mkdir /home/oncletom/Apps/mysql sudo chown mysql:mysql /home/oncletom/Apps/mysql
ln -s /var/lib/mysql/mysql /home/oncletom/Apps/mysql/mysql

sudo gedit /etc/apparmor.d/usr.bin.mysql
J’y ai remplacé

/var/lib/mysql/ r,
/var/lib/mysql/** rwk,

par l’ancien chemin + le nouvel emplacement des données MySQL

/var/lib/mysql/ r,
/var/lib/mysql/** rwk,
/home/oncletom/Apps/mysql/ r,
/home/oncletom/Apps/mysql/** rwk,

sudo service apparmor reload && sudo service mysql reload

Si vous avez bien suivi toutes mes explications, vous vous demanderez pourquoi j’ai modifié le profil existant de MySQL dans AppArmor au lieu de lier un nouveau profil ?
Je me suis rendu compte qu’au démarrage de l’OS, AppArmor ne chargeait pas le profil personnalisé et bloquait le démarrage de MySQL. J’ai créé un sujet sur Ubuntu Forums après une lecture de la documentation AppArmor mais pas de nouvelles. Là aussi je suis preneur car en relançant les serveurs à la main, tout fonctionne.

Ensuite à vous de repeupler vos bases de données à partir d’un dump. Si vous procédez à un déplacement des répertoires, n’oubliez pas de tout préserver : propriétaire et permissions ! Ça se passe avec l’option -a de cp par exemple.

Configuration de PHP

Fort heureusement pour PHP c’est plus simple puisqu’il n’y a qu’un seul petit lien symbolique à faire.
À noter que la configuration modifiée sera répercutée sur toutes les configurations de PHP, que ça soit pour Apache, en CLI ou CGI.

gedit ~/conf/php/my-custom.ini
J’ai ai mis par exemple :
```
memory_limit = 64M
```
sudo ln -s ~/conf/php/my-custom.ini /etc/php5/conf.d/my-custom.ini

Et voilà c’est tout pour PHP. Il faut bien entendu recharger votre serveur Web (Apache ou Lighttpd par exemple) pour qu’ils prennent en compte la modification.

Conclusion

J’ai déjà appliqué cette méthode par 2 fois et que dire si ce n’est que tout va plus vite ainsi !
Vos fichiers de configuration restent accessibles depuis votre gestionnaire de fichiers (pas besoin de passer en sudo pour sauvegarder les changements). Ils sont préservés de toute réinstallation impromptue.

Vous ne touchez que de manière minimaliste aux fichiers de configuration d’origine :

/etc/hosts pour ajouter un nom d’hôte (utile seulement si vous ne souhaitez pas utiliser localhost)
/etc/apparmor.d/usr.bin.mysql pour la raison évoquée plus haut … sinon on s’en serait passé

J’ai cherché à faire pareil avec phpmyadmin mais il ne semble pas y avoir de mécanisme de ce type. Dommage.

J’imagine qu’il doit y avoir des moyens similaires avec d’autres serveurs et d’autres langages. Vous procédez à un reparamétrage systématique ou bien vous utilisez une technique de ce genre ?

Livre blanc sur les frameworks PHP : présentation et explications

Oncle Tom — Wed, 18 Jun 2008 05:00:55 +0000

Il existe 4 phases dans la vie d’un développeur :

celle où il aime tout créer lui-même
celle où il aime utiliser un outil déjà tout prêt
celle où il aime concevoir son outil avec d’autres outils tout prêt
celle où il aime que les autres conçoivent pour lui (mais là il est patron ou armé d’une horde de stagiaires )

Les frameworks font partie de cette troisième catégorie. Ils existent dans à peu près tous les langages : CSS, PHP, JavaScript, Java, C#, Python, Ruby etc.
Mon discours portera sur les frameworks PHP, parce que c’est mon langage de prédilection mais aussi parce qu’un livre blanc sur les frameworks PHP pour l’entreprise est récemment sorti. Il parlera aussi bien aussi bien aux décisionnels qu’aux développeurs, à leur compte ou pour celui d’une entreprise.

De l’intérêt d’utiliser un framework

Un framework est littéralement ce que l’on peut appeler un socle logiciel : il propose des fonctionnalités de base et vous les utilisez pour concevoir votre propre application.

J’essaierai de faire court en énumérant une liste de quelques points à faire valoir dans l’utilisation d’un framework pour concevoir une application Web :

développement accéléré
convention over configuration : suivez les rails des conventions plutôt que de tout paramétrer
DRY : écrivez le code une fois et réutilisez-le pour éviter le copier-coller (sans parler des gains de maintenabilité)
mutualisation du code : un même socle pour plusieurs applications
concentration du développement sur le code métier
le framework vous décharge des tâches pénibles : sécurité, gestion des URL, gestion des permissions utilisateur, manipulation des bases de données, gestion du cache, accès aux fichiers etc.
génération automatique d’interfaces (admin generator), de base de données (ORM), de modules/applications (scaffolding) etc.
vecteur d’apprentissage individuel et collectif
bénéfices de tout le travail d’une communauté … et de celui que vous réinjecterez

A contrario, on pourra critiquer les frameworks pour leur plus forte consommation en ressources qu’un développement maison.
Ce n’est évidemment pas une raison valable pour passer à côté d’autant plus qu’il existe de nombreuses solutions pour palier/réduire ce problème avec les gestionnaires de cache et les accélérateurs de code.

Framework PHP ou CMS ?

Maintenant vous me direz : pourquoi développer un logiciel avec un framework au lieu d’utiliser un bon CMS des familles ou tout autre logiciel faisant son office ?
Ce n’est à mon sens pas la bonne question à se poser : un framework n’est pas une fin en soi. Le choix du logiciel dépendra essentiellement du besoin, immédiat et futur. Vous aurez beau avoir le meilleur développeur d’un CMS de votre pays, si le choix de la solution technique est déjà erroné, il ne suffira pas à éviter la catastrophe.

J’ai beaucoup accroché à cette formule le jour où je l’ai entendu : si vous estimez à au moins 50% l’utilisation de spécifiques dans une solution logicielle existante de type CMS, vous faites fausse route. Le spécifique EST votre solution, le CMS devient une simple fonctionnalité.
Dans le cas d’un développement spécifique, le choix d’un framework est dans ce cas naturellement prescrit.

Dans tous les cas, ce sont vos besoins qui doivent vous guider vers le choix d’une solution et non l’inverse. Ne partez pas surtout d’une solution pour tenter d’y combler vos besoins.

Les principaux frameworks PHP

Le livre blanc sur les frameworks PHP expose en détail les frameworks majeurs en PHP avec leurs avantages, inconvénients et surtout une grille comparative permettant de mettre à bout à bout leurs différentes fonctionnalités.

Toutefois on peut retenir ces noms de frameworks PHP :

On pourrait classer ces frameworks en 2 catégories :

les briques logicielles : ils se présentent comme des briques indépendantes qu’on peut utiliser à souhait dans n’importe quel projet, y compris d’autres frameworks. C’est notamment le cas de PEAR, EZ Components et Zend Framework ;
les frameworks à proprement parler : ils imposent une structure particulière et des lignes directrices de développement pour être plus efficace. On citera dans ce cas symfony, CodeIgniter et CakePHP

symfony : champion toutes catégories

Lors de la lecture du livre blanc sur les frameworks PHP, vous remarquerez très probablement que le framework symfony a tout pour plaire. C’est en effet à l’heure où j’écris ces lignes le framework PHP le plus abouti et le plus intéressant à analyser.
Il jouit d’une excellente réputation, d’une incroyable stabilité et d’une communauté très active, quantitativement et qualitativement parlant. Si on ne devait en garder qu’un, ça serait lui.

Pourquoi j’apprécie énormément symfony :

une documentation fonctionnelle et une documentation de l’API complètes
utilisation intensive de fichiers YAML pour le paramétrage
les fonctionnalités d’amin generator, de gestion de base de données avec l’ORM Propel et les outils d’automatisation qui en découlent
facilité d’intégration d’Ajax sans pondre une seule ligne de JavaScript
grand confort de développement
des conventions inspirées des plus grands (Ruby on Rails, Django etc.)

Conclusion

Développeurs : renseignez-vous et intéressez-vous à au moins un framework. C’est bien pour le CV et vous gagnerez du temps.
Décideurs : exigez de savoir quelle solution on vous préconise et surtout, pourquoi celle-là. À plus forte raison si votre projet comporte beaucoup de besoins spécifiques, demandez s’il s’agit d’un framework et si ce n’est pas le cas, pourquoi ça n’a pas été envisagé. Vous gagnerez aussi du temps et j’espère de l’argent.

Les frameworks sont aujourd’hui partout et ont acquis une certaine maturité. Ces lettres de noblesse les rendent utilisables aussi bien pour des petits besoins que ceux d’entreprises, peu importe leur taille. Les gains de temps et l’incitation à la production de qualité sont des facteurs non-négligeables pour la pérennité de vos applications.

Attention toutefois : un mauvais développeur et/ou une mauvaise conception prédomineront toujours. Votre fromage industriel aura toujours le même goût, peu importe la qualité du pain

Je radote mais j’espère que vous trouverez suffisamment d’informations pour vous convaincre dans le livre blanc des frameworks PHP pour l’entreprise. C’est ce genre de publications qui me font aimer la société dans laquelle je travaille

Menu déroulant en rollover semi-accessible avec jQuery

Oncle Tom — Tue, 10 Jun 2008 05:00:50 +0000

Joie : je fais maintenant partie de Planète Accessibilité en plus de Planet Libre. C’est l’occasion pour ce premier article dédié d’allier à la fois logiciels libres et accessibilité pour le plus grand bien du Web

Le but de cette explication sera de développer la méthode et le raisonnement pour mettre en place un menu en rollover accessible. La difficulté tient essentiellement au fait que tout élément masqué par le biais des CSS est masqué pour de nombreux clients Web.

Nous verrons aussi pourquoi il est important de dissocier la présentation et les artifices graphiques grâce à une dégradation propre du JavaScript. Nous utiliserons pour cela jQuery, ma librairie JavaScript favorite.

Buts et objectifs de l’exercice

J’ai eu besoin d’appliquer cette technique sur le site Emu Nova. Je souhaitais plusieurs choses :

disposer d’un menu en rollover en haut de page (facilite la navigation sur toutes les pages)
placer le contenu avant les menus dans le flux HTML de la page (améliore le référencement)
une navigation possible sans JavaScript (pour cause de bug ou autre)

Autrement dis, j’ai besoin d’un contenu en fin de flux mais visible avant tout le reste. J’ai opté pour la solution JavaScript pour éviter un positionnement absolu pénible à gérer (pour cause de conteneur centré) mais aussi pour respecter le colonnage de Blueprint (puis toutes façons j’ai raison )

En une image, cela se résume ainsi :

Nous allons aborder les 3 phases de ce tracé de flèche :

la construction du menu (la zone verte)
le déplacement du contenu (la flèche)
la construction de notre nouveau menu (la zone bleue)

Étape 1 : construire le menu en HTML

C’est l’étape essentielle. De sa structure dépend le reste de l’application. On doit d’abord penser à présenter le contenu de manière dégradée. C’est ainsi que le verront les utilisateur et c’est important de penser d’abord au pire des cas avant de mettre en place les paillettes et les artifices.

Cette structure est représentée ainsi en HTML :


  
    
      Actualités
      
        Actualités
        Newsletter
        Flux RSS
        Twitter
        Réactions à chaud
      
    
    
      Émulation
      
        Émulation
        Tutoriaux
        Foire aux Questions

Cette version est volontairement tronquée pour faciliter sa lecture.
L’idée générale de tout ça c’est de transporter directement la liste #navigation en dehors de son conteneur, #extra-content. C’est en effet plus rapide et plus performant de transporter une partie du DOM dans un autre endroit que de la recréer séquentiellement.

Ça aura également l’avantage de limiter au maximum le travail à effectuer en JavaScript par derrière. On notera que jusqu’à présent, on n’a pas encore touché à jQuery.

Avec cette structure, on peut dores et déjà deviner que les

Étape 2 : préparer le menu HTML

La deuxième reste assez simple : on transporte #navigation dans son nouveau conteneur (déjà existant) : #welcome-bar.

Pour éviter tout aléas graphique, l’idéal est de masquer tout ce qu’on ne veut pas voir maintenant. Nous rentrons maintenant dans la partie pure JavaScript.

Pour atteindre ce résultat, on pourrait envisager le code suivant :

(function($){
  $(function(){
    /*
     * Étape 2 : préparation du menu
     */
    $('#navigation > li > ul').hide();
    $('#navigation').appendTo('#welcome-bar');
  });
})(jQuery);

En soi, ce n’est pas excessif du tout :

on masque tous les sous-menus
on transporte le contenu de #navigation dans #welcome-bar

Tout le travail se situait dans la réflexion il faut croire

Étape 3 : assigner les évènements

Maintenant le plus dur c’est de donner vie à tout ça. C’est bien beau d’avoir des menus mais encore faut-il les animer. Là encore nous avons plusieurs contraintes à subir :

les titres doivent être cliquables. Certaines personnes cliqueront en effet avant de réaliser qu’il y a un menu déroulant. Par principe, on prendre le premier lien de la liste et on l’assignera au titre correspondant ;
le menu doit se dérouler lors du survol du titre …
mais il ne doit pas se masquer tant qu’on n’a pas quitté le titre NI la liste déroulante

La difficulté tient à ces 2 dernières contraintes. On pourrait tout d’abord penser à l’utilisation des évènements mouseover et mouseout MAIS, parce qu’il y a bien un mais, mouseout est un peu capricieux.

Si on imagine un mouseover directement sur li.column, le problème c’est que survoler un élément comme Actualités ou Newsletter activera le mouseover de ces derniers … et désactivera, un temps minime certes, le survol de li.column. Autrement dit le menu se repliera alors qu’on tentera de l’utiliser.

Heureusement pour nous, jQuery a introduit les évènements mouseenter et mouseleave (présents dans Internet Explorer depuis des lustres, c’est bien le seul avantage de cette atrocité) depuis la version 1.2.2. Ces évènements correspondent exactement à ce que l’on souhaite : maintenir une zone survolée malgré le survol de ses enfants.
Tout est histoire de couches

Côté code, ça se complique :

(function($){
  $(function(){
    /*
     * Étape 3 : assignation des évènements et transformation
     */
    $('#navigation > li')
      .each(function(){
        var title = $('h2:first', this);
        var href = $('a:first', this).clone();
        href.text(title.text()).wrapInner('');
        title.html(href);
       })
      .find('h2 > a').bind('mouseenter', function(){
        $(this).parents('li.column').find('> ul').slideDown('fast');
      }).end()
      .bind('mouseleave', function(){
        $('> ul', this).slideUp();
      });
  });
})(jQuery);

Plusieurs remarques sur ce code :

j’utilise les chaînes de jQuery pour gagner du temps et reparcourir des tableaux déjà connus (le sélecteur n’est pas réexécuté)
j’utilise également la méthode end() pour revenir au précédent état du sélecteur. Très pratique pour naviguer dans un jeu d’éléments et gagner en performances

Et pour les explications :

Pour chaque élément de liste
1. on met de côté le titre de la liste
2. on clone le premier élément du sous-menu
3. on modifie le libellé du lien du clone
4. on remplace le titre par le code HTML du clone
Pour ces liens hypertextes nouvellement créés (plus faciles à styler sans JS au rollover), on leur demande de déplier le sous-menu voisin
Ce sous-menu ne sera replié que lorsqu’on quittera le li.column

Conclusion

La mise en œuvre de ce menu est relativement aisée et surtout, suffisamment souple pour que vous puissiez l’adapter à vos besoins.
Dans tous les cas on remarquera que les clés de la réussite sont :

un code HTML propre (facile les sélections JS et le stylage CSS)
une évolution d’une base sans artifices vers une interface améliorée en JavaScript
un code simple, facilement maintenable et adaptable

Ceci n’est qu’un exemple où le JavaScript peut servir à conserver des interfaces accessibles tout en augmentant leur utilisabilité. Qui a dit que le JavaScript c’était nul ?

Le seul reproche que l’on peut faire à ce menu accessible c’est le manque de navigation au clavier. L’idéal serait de pouvoir naviguer dans le choix des menus entièrement avec les flèches de son clavier.
Rendez-vous dans un autre billet pour ce point ?

Tableau auto-extensible en JavaScript

Oncle Tom — Tue, 26 Jun 2007 11:59:32 +0000

Bon nombre de clients utilisant les sites Internet de mon employeur passent des commandes en saisissant directement les codes articles de leur choix. Ce n’est pas anodin : pour du réassort de magasin, ils savent exactement ce qu’ils veulent. Et un beau jour on vient me voir en me disant qu’ils ne peuvent saisir qu’un code et une seule quantité à la fois, qu’il faudrait changer ça.

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 :

éliminer toutes les lignes dont on ne veut pas et n’en garder qu’une
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
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


  
    
      Code article
      Quantité

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, une nouvelle ligne s'ajoute automatiquement.
Afin d'accélérer votre saisie, utilisez la touche de tabulation de votre clavier 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);