de supprimer recuperer_fond(), ça a tout pêté ; par exemple sur la
page d'admin des plugins, je ne peux plus rien faire puisque j'ai
Fatal error: Call to undefined function recuperer_fond() in
/Users/fil/Sites/spip-zone/_plugins_/_stable_/cfg/inc/cfg_formulaire.php
on line 475
La fonction est utililsée dans une centaine de plugins...
-- Fil
Ah la la, cette multiplication de fonctions quasi semblables envoyéés dans la nature, c'est pas possible.
Bon dans l'immédiat le plus simple est de la coller dans inc/utils puisqu'elle est si utile.
Mais si "evaluer_fond" est elle aussi employée des centaines de fois, il faudra bien choisir: je ne vois pas pourquoi SPIP devrait peser 2 fois plus lourd qu'il n'en a besoin.
Committo,Ergo:Sum
Bon dans l'immédiat le plus simple est de la coller dans inc/utils
puisqu'elle est si utile.
Mais pourquoi ne pas la laisser où elle se trouvait ?
Mais si "evaluer_fond" est elle aussi employée des centaines de fois, il
faudra bien choisir: je ne vois pas pourquoi SPIP devrait peser 2 fois plus
lourd qu'il n'en a besoin.
Tu exagèrs un tout petit peu. Je ne propose pas de dupliquer chacune
des fonctions de SPIP, juste de permettre à ceux qui l'utilisent de
continuer à l'utiliser. Mais si on veut faire SPOP c'est possible
aussi, c'est juste un autre projet.
-- Fil
oui enfin là c'est dans la branche de dev ... tout va bien non ?
Bon dans l'immédiat le plus simple est de la coller dans inc/utils
puisqu'elle est si utile.
[12446] vient de le faire, mais en mettant evaluer_fond dans public/assembler, il semble moins utile et manipule des globales tres techniques.
Mais pourquoi ne pas la laisser où elle se trouvait ?
Parce que le compilateur est un code difficile qu'il ne faut pas obscurcir encore plus en multipliant des fonctions quasi-identiques.
Le code PHP de SPIP fait 10 Mo, il faut faire un effort pour qu'il reste lisible et rapide à charger.
Committo,Ergo:Sum
Committo,Ergo:sum a écrit :
Bon dans l'immédiat le plus simple est de la coller dans inc/utils
puisqu'elle est si utile.[12446] vient de le faire, mais en mettant evaluer_fond dans public/assembler, il semble moins utile et manipule des globales tres techniques.
Mais pourquoi ne pas la laisser où elle se trouvait ?
Parce que le compilateur est un code difficile qu'il ne faut pas obscurcir encore plus en multipliant des fonctions quasi-identiques.
Le code PHP de SPIP fait 10 Mo, il faut faire un effort pour qu'il reste lisible et rapide à charger.Committo,Ergo:Sum
Bonjour,
J’ai tendance à utiliser également recuperer_fond dans les mes plugins, mais c'est la première fois que j'entends parler de evaluer_fond, en fait c'est à travers votre discution que je découvre cette fonction. Mais c'est quoi la différence fondamentale entre evaluer_fond et evaluer_fond ? En regardant sur doc.spip.org je constate que ces deux fonctions prennent les même paramètres et fond quasiment (pour ne pas dire strictement) la même chose ? En fait je ne comprends pas, qu'est ce qui a pousser a avoir ces 2 fonctions à part qu'il sont à 2 emplacement différents ... En ce sens je rejoins la pensée de Committo,Ergo:Sum. Enfin, c'est juste un avis.
Cordialement
GUIOUBLY William
- recuperer_fond est la fonction initiale introduite dans Spip 1.9.1, elle renvoie le texte uniquement produit par le squelette
- evaluer_fond est une version plus générique, introduite dans la branche dev, qui avait vocation à remplacer recuperer_fond car elle permettait de recuperer le texte mais aussi les autres éléments calculés par Spip (les entetes notamment).
Elle avait vocation à remplacer recuperer_fond et constituer l'api.
Là, je ne sais plus très bien ce qu'on doit dire :
- n'utiliser que recuperer_fond qui constitue l'api officielle (mais du coup limitée), et le support d'evaluer_fond n'est pas garanti ? -> on retourne à la situation de la 1.9.1 
- evaluer_fond fait aussi partie de l'api ? -> on a deux fonctions très semblables qui font presque la meme chose ...
bref, tout cela n'a pas vraiment éclairci la situation.
Je préférais nettement la situation anterieure :
- evaluer_fond etait l'api officielle, dans inc/utils
- recuperer_fond existait mais son usage devenait déconseillé avec Spip 2.0, et la possibilité de la déménager à terme...
Cédric
cedric.morin@yterium.com a écrit :
- recuperer_fond est la fonction initiale introduite dans Spip 1.9.1, elle renvoie le texte uniquement produit par le squelette
- evaluer_fond est une version plus générique, introduite dans la branche dev, qui avait vocation à remplacer recuperer_fond car elle permettait de recuperer le texte mais aussi les autres éléments calculés par Spip (les entetes notamment).
Elle avait vocation à remplacer recuperer_fond et constituer l'api.Là, je ne sais plus très bien ce qu'on doit dire :
- n'utiliser que recuperer_fond qui constitue l'api officielle (mais du coup limitée), et le support d'evaluer_fond n'est pas garanti ? -> on retourne à la situation de la 1.9.1
- evaluer_fond fait aussi partie de l'api ? -> on a deux fonctions très semblables qui font presque la meme chose ...bref, tout cela n'a pas vraiment éclairci la situation.
Je préférais nettement la situation anterieure :
- evaluer_fond etait l'api officielle, dans inc/utils
- recuperer_fond existait mais son usage devenait déconseillé avec Spip 2.0, et la possibilité de la déménager à terme...Cédric
Committo,Ergo:sum a écrit :
Bon dans l'immédiat le plus simple est de la coller dans inc/utils
puisqu'elle est si utile.[12446] vient de le faire, mais en mettant evaluer_fond dans public/assembler, il semble moins utile et manipule des globales tres techniques.
Mais pourquoi ne pas la laisser où elle se trouvait ?
Parce que le compilateur est un code difficile qu'il ne faut pas obscurcir encore plus en multipliant des fonctions quasi-identiques.
Le code PHP de SPIP fait 10 Mo, il faut faire un effort pour qu'il reste lisible et rapide à charger.
Committo,Ergo:SumBonjour,
J’ai tendance à utiliser également recuperer_fond dans les mes plugins, mais c'est la première fois que j'entends parler de evaluer_fond, en fait c'est à travers votre discution que je découvre cette fonction. Mais c'est quoi la différence fondamentale entre evaluer_fond et evaluer_fond ? En regardant sur doc.spip.org je constate que ces deux fonctions prennent les même paramètres et fond quasiment (pour ne pas dire strictement) la même chose ? En fait je ne comprends pas, qu'est ce qui a pousser a avoir ces 2 fonctions à part qu'il sont à 2 emplacement différents ... En ce sens je rejoins la pensée de Committo,Ergo:Sum. Enfin, c'est juste un avis.
Cordialement
GUIOUBLY William
_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip
Ben oui, ça serait le plus logique, il suffit d'indiquer dans la doc (de spip.doc.org par exemple) que la fonction recuperer_fond est devenu "obsolète" (ou deprecated pour ceux qui préfère ce terme :D) et d'utiliser de préférence evaluer_fond pour SPIP 2.0.
Puis vous retirerez la fonction recuperer_fond, une fois qu'on jugera qu'il n'est plus utiliser dans les version futur de SPIP. Bien sur, si les développeurs de plugin comme moi ne sont pas au courant qu'il y a fonction plus évoluer de tel fonction et qu'il faudrait plutôt l'utiliser que l’ancienne, ben on continuera à utiliser recuperer_fond comme si de rien n'était.
Il suffit de prendre moi comme exemple, si vous n’aviez pas eu cette discution sur recuperer, je ne connaîtrais même pas l'existence de evaluer_fond. Je l'aurais peut-être rencontré par hasard, mais jamais je ne saurais qu'il vaut mieux l'utiliser que recuperer_fond. Surtout si aucun doc ne l’indique...
Bon de toute façon, dans la mesure que SPIP 2.0 apporte déjà beaucoup de changement fondamental qui s'applique également au plugin. Je pense qu'on peut se permettre de forcer la main des développeurs à utiliser de préférence tel ou tel fonction qui serait plus adapté pour SPIP 2.0. Mais il faut le dire et l'indiquer, on n’a pas la science infuse non plus 
.
En tout si ça continue comme ça, à conserver des fonctions ad vitam eternam par soucis de compatibilité descente, d'ici SPIP 10.0, le code PHP de SPIP ne fera pas 10 Mo mais 100 Mo :D. Il y a des moments comme celui-ci, qu'il faut faire table raz du passé, pour mieux préparer l'avenir. Comme le fameux passage des fichiers .php3 à .php. Enfin, encore une fois c'est qu'un avis.
Cordialement,
Sauf que la 2.0 est en beta et qu’un tel changement obligerait à revoir une grande majorité de plugins, déjà que c’est pas toujours simple de les rendre compatible là dans 6 mois ce ne sera tjs pas fait.
Je trouve très positifs l’harmonisation du code qui est en route , concernant l’api celle de la 2.0 ne oit plus changer, les focntions posant problème sont à noter comme obsolète pour pouvoir etre migré dans la version 2.1 ce qui laissera le temps d’adapter les plugins. Les modifs de la beta ne doivent porter que sur les corrections de bugs et non les évolutions.
Mes 2 cents,
A+
