En vue de répertorier toutes les constantes et les filtres (etc. pour la doc), j’ai regardé un peu le “code” dans le core de SPIP. Et j’ai remarqué que parfois on écrit “define” de 2 façons :
define(’
define (’
Est-ce qu’il y a une raison “technique” à cela ? (un avec espace, l’autre sans)
Cela me faciliterait la tache que tout soit sous la même écriture, si je change en local cela, ça ne posera pas de soucis au fonctionnement de SPIP ?
Autres questions :
Comment est identifié une constante ? J’ai vu _XX_XX_XX ceci… Est-ce le seul format d’écriture des constantes ?
Est-ce que tous les filtres ont été rassemblé dans les fichiers inc/filtresXXX.php ?
Ca ne me parait pas une bonne approche pour les filtres.
Il faut avant tout définir une API publique de SPIP qui doit être la seule connue et accessible de l’extérieur.
Aujourd’hui, il y a des plugins parfois trop intrusifs et il serait néfaste de perpétuer l’utilisation de telles fonctions internes pour les versions futures.
Donc la problématique des filtres est a prendre avec délicatess…
Pour les constantes, je pense que le problème est presque identique.
Toutes les constantes ne sont pas publiques, c’est à dire ne participent pas toutes à de la configuration de spip.
Là, il faudrait peut-être se demander si la solution ne serait pas de faire évoluer le couteau kiss pour combler les manques.
Cool.
Mais je vois qu’il y a certaines constantes qui n’ont pas d’underscore devant leur nom. Exemple : CONFIRMER_MODIFIER_URL
Est-ce normal dans ton tableau ?
Ca ne me parait pas une bonne approche pour les filtres.
Il faut avant tout définir une API publique de SPIP qui doit être la seule connue et accessible de l’extérieur.
Aujourd’hui, il y a des plugins parfois trop intrusifs et il serait néfaste de perpétuer l’utilisation de telles fonctions internes pour les versions futures.
Donc la problématique des filtres est a prendre avec délicatess…
Pour les constantes, je pense que le problème est presque identique.
Toutes les constantes ne sont pas publiques, c’est à dire ne participent pas toutes à de la configuration de spip.
Alors dans ce cas là, si on « arrive » à documenter toutes les constantes, on pourra migrer les constantes privées dans une doc plus technique (genre : programmer.spip.org ou doc.spip.org).
Je ne publierai pas les articles quoiqu’il advienne mais les soumettrai à la publication.
Là, il faudrait peut-être se demander si la solution ne serait pas de faire évoluer le couteau kiss pour combler les manques.
A partir du listing qui en résultera, on pourra étoffer effectivement le couteau KISS… Mais, ça ne risque pas de devenir une usine à gaz ?
Sinon, voir pour « catégoriser » chaque constante et ainsi créer des onglets par catégorie… C’est faisable maintenant en SPIP 3? (sans cfg)
Alors dans ce cas là, si on « arrive » à documenter toutes les constantes, on pourra migrer les constantes privées dans une doc plus technique (genre : programmer.spip.org ou doc.spip.org).
Je ne publierai pas les articles quoiqu’il advienne mais les soumettrai à la publication.
Euh non on s’est pas compris.
Si les filtres/fonctions ne sont pas publiques elles n’ont pas vocation à être documentées du tout !
C’est du tripatouillage spip-core uniquement.
Là, il faudrait peut-être se demander si la solution ne serait pas de faire évoluer le couteau kiss pour combler les manques.
A partir du listing qui en résultera, on pourra étoffer effectivement le couteau KISS… Mais, ça ne risque pas de devenir une usine à gaz ?
Si ça le devient c’est qu’on externalise trop de constantes à mon avis.
C'est pas parce que c'est privé que ça doit pas être documenté !
Par contre, c'est peut être à juste documenter *dans le code* ou ailleurs, mais oui, pas sur un site d'API c'est sûr...
Si ce n’est pas documenté, ça va complexifier la maintenance par le core, et surtout bloquer fortement toutes volonté d’un extérieur au core à s’impliquer au point de le rejoindre potentiellement un jour.
C’est ce que j’ai dit ?
Je crois avoir répondu, est ce qu’on est d’accord là dessus ?
Bin tu as dis « de la doc d’API publique non », et je ne suis pas d’accord, tout doit être documenté, et il suffit d’avertir les développeurs de plugins si une méthode n’est utilisable que par le core, pas par les plugins.
Ce qui me paraît tout de même étrange, au passage. Il faut mieux dire qu’aucune pérennité n’est assurée (je ne vois pas d’autre raison), plutôt que décider arbitrairement qu’il est interdit de l’utiliser, ce sera plus juste.
Bin tu as dis « de la doc d’API publique non », et je ne suis pas d’accord, tout doit être documenté, et il suffit d’avertir les développeurs de plugins si une méthode n’est utilisable que par le core, pas par les plugins.
Ben c’est à dire que je répond à la problématique levée par Teddy et toi tu extrapoles ce que je dis à une problématique qui n’est pas celle de départ. Donc c’est sur que tu peux me faire dire ce que tu veux ainsi.
Donc si on se contente de répondre à Teddy mon avis est :
doit être documenté publiquement que l’API publique.
l’API non publique est susceptible de changer et n’est donc pas publiée autrement que dans le code, qui lui doit être commenté en standard.
Ce qui me paraît tout de même étrange, au passage. Il faut mieux dire qu’aucune pérennité n’est assurée (je ne vois pas d’autre raison), plutôt que décider arbitrairement qu’il est interdit de l’utiliser, ce sera plus juste.
Si ça te fais plaisir, mais de toute façon rien n’est interdit.
Maintenant quand tu utilises l’interface PHP décrite dans php.net ou d’autre type d’interface tu demandes à connaitre les fonctions qui la sous-tendent ?
Tu crois pas que ça serait déjà intéressant d’avoir une interface publique documentée et pérennisée avant de se demander si les fonctions internes sont ou pas à interdire.
A chaque fois qu’on veut simplifier un truc il faut rajouter une couche de complexité…
N'empêche que...
Une de mes questions est resté sans réponse: y a-t-il une raison particulière pour que les define soient écrit de 2 façons différentes? Avec espace et sans espace.
avant de partir dans un nouveau troll (du vendredi ?) sur la façon
de coder ses scripts php : doubles quotes ou simples quotes ? syntaxe
heredoc ou pas ? conventions pear ou non ? ...
il existe une page : http://www.spip.net/fr_article825.html
qui donne quelques pistes de cadrage...
cela dit, chacun fait bien comme il veut (à condition d'assumer
ses choix et leurs éventuelles répercussions).
