Salut,
Le problème ne se posait pas vraiment avant car les fonctions génériques http_calendrier_* retournaient seulement le contenu du tableau et non le tableau
mais non !
Regarde l’état avant mes modifs:
http://core.spip.org/projects/spip/repository/revisions/16764/entry/branches/spip-2.1/ecrire/inc/agenda.php
tu peux aussi regarder la 2.0 les 1.9 et la 1.8 c’est comme ça aussi.
peut-être les fonctions du core, mais on était en aucun cas obligé dans nos fonctions de retourner tout le tableau, on pouvait très bien retourner une partie seulement du tableau et faire le reste en html, là non, tu nous obliges à tout faire en php…
Il faudrait vraiment mettre tes deux div dans la fonction spécifique des agendas qui sont fait pour.
je ne vois pas de quoi tu parles.
les mettre dans les fonctions du core (du genre http_calendrier_mois). On a déjà http://core.spip.org/projects/spip/repository/revisions/16764/entry/branches/spip-2.1/ecrire/inc/agenda.php#L226 avec le table en dur, pourquoi ne pas mettre le div ici et tout est arrangé ? la compatibilité sera rétablie ainsi…
Ça évitera de tout devoir recoder en php ce qui est déjà fait en spip pour juste ça… faire juste un return « $res »; avec le $res qui contient lui même les div…
Ici : http://zone.spip.org/trac/spip-zone/browser/squelettes/soyezcreateurs_net/plugins_2.1/plugins/soyezcreateurs/noisettes/agenda/miniagenda.html j’ai codé de telle manière le header pour prendre en charge les changements de date différement de SPIP aujourd’hui. J’ai fait ça en SPIP. Si je devais mettre à jour tout pour générer caption et thead en php, je pense que tu vois un peu le boulot et aussi l’usine à gaz que ça générerait en php (utilisation de l’api sql par rapport aux boucles, calculs sur les variables avec les dates, …)
Bien sûr, il s’agit seulement de réaliser enfin que http_calendrier_init ne retourne pas une suite de TR comme tu le dis,
mais quelque chose qui encpasule cette suite. Avant la capsule était un table, maintenant c’est div+table, mais ton code aurait dû faire ce boulot depuis le début. Et il n’a pas été fait parce qu’en fait cette invalidité XML n’est pas vraiment gênante: ça s’affiche quand même.
ça, c’est toi qui le décide que dorénavant on doit retourner tout un tableau entier avec cette fonction… avant on pouvait retourner ce que l’on voulait, dont une suite de tr ce qui était le plus logique… pourquoi retourner un entête dans du php ?
bref, je ne sais pas si je suis le seul à avoir créé mon propre agenda en utilisant l’api de l’agenda qui utilisait à l’époque (c’est à dire le tbody seulement en php) mais je crois déjà que ça casserait le miniagenda officiel : http://zone.spip.org/trac/spip-zone/browser/plugins/agenda/2_0_0/formulaires/calendrier_mini.html (celui de SC fonctionne un peu pareil, mais je n’ai pas testé pour savoir si ça le casse vraiment, ça reste une supposition).
Enlever ces div (ou les mettre dans un test) ne serait pas plus simple pour ne pas faire une trop grosse rupture de compatibilité ?
Aujourd’hui comme hier ce code est valide XHTML, pourquoi faudrait-il le changer alors que c’est le tien qui ne l’a jamais été ?
Plus généralement, avant de prétendre qu’un Commit casse quelque chose, ce serait bien de vérifier qu’on a pas découvert un vieug bug chez soi.
Non, il n’est plus valide avec ce commit, tu viens de le dire juste avant.
Et j’ai été vérifier, retourner le div dans http_calendrier_init casse AUSSI la validité xhtml de l’agenda du plugin original. Là, je pense que vraiment ça va poser un problème à beaucoup de monde…
Commiter quelque chose qui a l’air de plus sémantique dans du php, c’est cool, mais faut penser aussi aux codes des autres qui pensent la sémantique d’une autre manière.
