Le système de la fonction urls_generer_url_xxx() est pratique, et plus
encore s'il autorise un traitement partiel des cas (cf. ce commit).
Cependant, est-ce qu'il ne serait pas plus élégant et pratique
d'introduire un pipeline, pour permettre aux plugins de mettre leur nez
de manière plus fine dans la génération d'URLs propres ?
Par contre je ne connais pas bien le système de pipelines, ni les
subtilités du système de gestion d'URLs. Si quelqu'un a un avis
éclairé...
Il y a un autre point qui est apparu l'autre jour : une personne sur IRC voulait vérifier l'exactitude d'une URL *demandée*. J'ai donc l'impression qu'il manque un pipeline pour l'action inverse, c'est-à-dire quand on appelle une URL (propre ou pas) et que SPIP va chercher dans la table des URLS (ou pas) à quel objet ou page cela fait référence, et renvoie alors vers le bon squelette, etc.
En résumé il y a quelques pipelines pour Objet=>URL.
Mais apparemment pas pour URL=>Objet.
Et sinon pour le problème de davux, les deux pipelines dont tu parles sont pour des types d'URLs précis, et reçoivent d'ailleurs des arguments propres à leur fonctionnement. Mais j'ai l'impression que davux parlait d'un pipeline en amont ou en aval de ces deux-là, et qui lui concernerait TOUTES les URLs, y compris les "pas propres" donc. D'ailleurs même s'il ne parlait pas de ça, c'est pertinent quand même.
Cela dit, compte tenu de la gymnastique qu'il faut faire pour traiter les anciens cas d'urls, il serait pertinent de deplacer ce code dans une fonction simple decoder_url($url);
Je ne comprends pas ce que tu entends par "elle est disponible".
Si on veut modifier le comportement par défaut, vu qu'il n'y a pas de pipeline avant la production finale de la page, on fait comment ?
Même sans déplacer le code on peut imaginer un pipeline à la fin du processus non ? Mais oui tant qu'à faire autant découper en fonctions plus simples à comprendre. Et du coup le pipeline se nommerait pareil "decoder_url".
