var Phenix = function () {

Troll du Web depuis 1996

Ajouter l’icône des blocs AJAX dans l’espace publics d’un site #SPIP

Parce que c’est mieux !

Petite astuce que j’ai trouvée il y a peu.

Lorsque l’ont AJAX des blocs SPIP, le comportement par défaut est de passer le bloc en opacité 50%.
Ce n’est pas forcément le plus explicite pour les visiteurs, plus habitués à avoir un signe de « pseudo-progression ».

Ce n’est le comportement de la partie admin, qui affiche une icône « Loading » dans le coin supérieur droit.

On peut facilement reproduire ce comportement dans l’espace publique avec une petite ligne de css :

  1. .loading {
  2. background: url(../../prive/themes/spip/images/searching.gif) no-repeat top right;
  3. }

Ici je suppose que le fichier css se trouve dans un sous-dossier du dossier squelettes de SPIP. Si ce n’est pas le cas, il faut adapter le chemin.

Bien entendu on peut mettre ce que l’on veut sur la class loading, ici je n’ai fais que reproduire le comportement de SPIP.


Pense bête pour l’utilisation de git submodule

Petit pense-bête pour mon moi future, qui aimera certainement se servir des sous-modules de Git (aka git submodule).

Il faut dans la mesure du possible, il faut utiliser des dépôts git en ligne pour héberger les sous-modules. L’intérêt étant de faciliter les échanges. Les sous-modules d’un projet seront accessibles par tous.

Ajouter un sous-module à un dépôt git :

  1. git submodule add URL_DEPOT

Rien de plus simple, le code est ajouté. On peut aussi passer un paramètre a après l’URL pour spécifier un répertoire d’installation.

C’était l’étape facile, et probablement la seule commande que l’on peut refaire sans avoir à chercher sur Stack Overflow.

Supprimer

Imaginons maintenant que l’ajout de ce module a été une erreur et qu’on en veille plus. On pourrait espérer n’avoir qu’à supprimer le code et faire un commit.
Trop simple ! D’abord il faut dé-initialiser le sous-module pour ensuite l’effacer :

  1. git submodule deinit PATH/SOUS_MODULE
  2. git rm --cached PATH/SOUS_MODULE

Alors qu’un :

  1. git submodule rm PATH/SOUS_MODULE

Serait plus logique.

Déplacer un sous-module

Cela demande git 1.9.3 au moins.

  1. git mv old/submod new/submod

Cela va déplacer un sous-module. A noté que l’on peu mv un répertoire complet qui contient des submodule, git s’y retrouve.
Un commande logique, cela fait plaisir !

Mettre à jour

Bon, imaginons maintenant qu’on est l’idée saugrenue de vouloir mettre à jour les sous-modules.
La commande logique serait :

  1. git submodule pull

Perdu ! Les sous-modules utilisent pour des raisons que j’ignore une commande update :

  1. git submodule update --remote

Si on ne met pas le remote, la commande ne fait rien. Et non dit pas qu’elle ne fait rien.

Cloner

Si un collègue veut récupérer le code avec des sous-modules, il va vouloir cloner le dépôt. Qui sera cloné SANS les sous-modules ! Il viendra vous voir, vert de rage, parce que ça ne marche pas cette merde !

Ou alors c’est un malin et il a fait :

  1. git clone --recursive URL

Ou alors il peut essayer d’activer les sous-modules :

  1. git submodule init
  2. git submodule update --remote

Je ne comprends pas pourquoi ces commandes manquent de logique ni pourquoi c’est si compliqué de gérer des sous-modules Git.
Une alternative serait d’utiliser Git subtree. Mais du coup on a d’autres problèmes.

Je pense que la bonne solution se situerait entre les deux : le code des sous-modules serait indexé dans le module parent, mais on conserverait la possibilité de modifier le code des enfants sans contrainte.