Bonjour,
avant pour creer/modifier un article avec un script, on faisait :
include_spip('action/editer_article');
articles_set($id_article,array('statut'=>'publie','titre'=>$titre,'descriptif'=>$descriptif));
et le tour etait joue.
maintenant, articles_set ne fait plus le boulot qu'avec les _request().
Résultat : il faut recopier/recoder son contenu à la place du simple appel :
cela ne gagne ni en lisibilité, ni en efficacité.
Quel est le débat sur cette liste qui a prévalu à ce changement ?
Pour une fois qu'on avait un commencement d'api claire et compéhensible, j'y perds mon latin (que je n'ai jamais eu au demeurant).
Cédric
Ce probleme mets en lumiere un point critique actuel :
l'api n'est pas clairement définie.
Alors que je croyais que les fonctions insert_article et articles_set étaient une bonne api, et que je les ai utilise dans un plugin pour manipuler les articles, elles s'averaient en fait de simples fonctions a usage interne de spip.
D'ou la necessite de declarer clairement les fonctions d'interfaces publiques de SPIP :
je vois 3 solutions :
- commenter par un simple
// @public devant la fonction
- prefixer simplement les fonctions :
function api_xxx
- regrouper les fonctions/fichiers dans un sous dossier
api/
en les prefixant le plus souvent possible pour utiliser avec un $fonction = charger_fonction('xxxx','api');
Cette derniere solution aurait aussi un avantage certain qui serait de permettre de detecter les appels hors api des plugins via un grep sur les include_spip hors 'api/', et d'automatiser ainsi certains contrôles sur la qualité de code des plugins et leur perennité qui pourraient être :
- utiliser l'api sql (pas de spip_query ni de mysql_query)
- pas de surcharges du core (controle des noms de fichier et noms fonctions)
- pas d'inclusion ni de charger_fonction hors api
Cédric
cedric.morin@yterium.com a écrit :