Au moment de coder, nous avons tous nos défauts. Plus ou moins nombreux, plus ou moins importants, plus ou moins évitables.

Il y a en certains qu'on peut corriger ou atténuer avec un peu de pratique, de discipline, de rigueur et quelques bonnes pratiques. Mais il y en a certains qui vous collent à la peau, et qui - malgré vos efforts - viennent pourrir vos séances d'écriture. Je pense que personne n'y échappe vraiment totalement.

Pour ma part, c'est mon naturel tête en l'air et mes doigts crochus qui me tendent régulièrement des pièges. Deux bons gros défauts, bien vicieux, qui n'attendent que les moments un peu plus détendus pour venir frapper en dessous de la ceinture : c'est-à-dire dans les parties de code les plus routinières.

Ils prennent la forme d'oublis idiots de choses pourtant évidentes, ou de fautes de frappe, les uns comme les autres m'étant gentiment signifiés par de doux messages d'insultes au moment des tests[1].

Ah, évidemment, bien souvent, ce n'est rien de grave. Du pas bien méchant pas trop embêtant. Mais systématiquement, c'est une perte de temps d'autant plus frustrante que l'erreur l'ayant engendrée est stupide.

Figurez-vous que lorsque je développe un bout de quelque chose pour Dotclear, c'est souvent dans les zones banales que sont l'enregistrement de behaviors ou de balises de templates que ça se produit. Une typo dans le nom du callback par ci, l'oubli de la déclaration d'une nouvelle balise par là, etc. Rageant.

Il y a donc quelques temps déjà; j'ai décidé de m'éviter ces peines lors de la mise au point des plugins ou thèmes. J'ai donc opté pour l'approche feignasse.

Comme pour le cas des templates, par exemple[2], je nomme mes méthodes de classe du même nom que la balise résultante (au préfixe tpl près, bien entendu), je me suis dit que la réflexion disponible en PHP5 allait être mon amie.

Je me suis donc bâti une petite trousse à outils que j'utilise dans les premières étapes d'un développement. Dans cette trousse, j'ai de quoi m'épargner les séances de $core->tpl->addBlock/addValue(...), $core->addBehavior(...), et autres sections répétitives de code sans réelle valeur.

J'en livre ici un petit exemple[3] :

class datk
{
	public static function registerTemplates($classname)
	{
		global $core;
		
		if (trim($classname) == '') {
			throw new Exception('Aucun nom de classe.');
		}
		
		$class = new ReflectionClass($classname);
				
		if ($class->isAbstract()) {
			throw new Exception('Classe abstraite : '.$classname);
		}

		$methods = $class->getMethods();
		foreach ($methods as $method)	{
			if ($method->isPublic() && $method->isStatic()) {
				$parameters = $method->getParameters();
				if ($nb_parameters = count($parameters)) {
					$name = $method->getName();
					if ($nb_parameters == 1) {
						$core->tpl->addValue($name,array($classname,$name));
					}
					elseif ($nb_parameters == 2) {
						$core->tpl->addBlock($name,array($classname,$name));
					} 
				}
			}
		}
	}
}

Je me retrouve alors à faire un simple appel[4] :

datk::registerTemplates('maClasseTemplate');

en lieu et place d'un litanie exténuante, et terreau fertile pour mes défauts, de $core->tpl->addMachin().

C'est bête et sans aucun doute inutile pour bon nombre d'entre vous. Mais vous n'avez pas idée du nombre de poignées de minutes que ça m'épargne !

Notes

[1] Dans le meilleur des cas...

[2] Puisque je fais de plus en plus souvent la même chose avec les behaviors.

[3] Frelaté, tout de même : j'ai regroupé dans cet exemple plusieurs méthodes que j'utilise véritablement. Ah ben, oui, par endroit, chez moi, ça génère vraiment le code... :-)

[4] Quel menteur, ce type ! Il faut bien gérer l'inclusion du machin quelque part, hein...