Author: cedric@yterium.com
Date: 2008-09-24 13:32:58 +0200 (mer, 24 sep 2008)
New Revision: 12767
Log:
?var_mode=blocs pour encadrer et legender du nom du squellette utilise toutes les inclusions
la centralisation des inclusion par recuperer_fond permet facilement la mise en place de cette fonction de debug supplementaire
Modified:
branches/spip-2.0/ecrire/inc/utils.php
branches/spip-2.0/ecrire/public/cacher.php
branches/spip-2.0/ecrire/public/parametrer.php
Le 24 sept. 08 à 13:33, cedric@yterium.com a écrit :
Author: cedric@yterium.com
Date: 2008-09-24 13:32:58 +0200 (mer, 24 sep 2008)
New Revision: 12767Log:
?var_mode=blocs pour encadrer et legender du nom du squellette utilise toutes les inclusions
la centralisation des inclusion par recuperer_fond permet facilement la mise en place de cette fonction de debug supplementaireModified:
branches/spip-2.0/ecrire/inc/utils.php ....
Euh bon, là de nouveau j'ai l'impression qu'on part sur du dev je ne comprends pas ce que ça fait dans la branche 2.0 plutot que dans l'autre.
Je sais bien que ce que j'ai fait récemment ressemblait aussi à du dev, mais c'était toujours sous-tendu par une mise au propre du code (calculer_url_* ça faisait tout et son contraire, fallait y mettre le hola).
Donc, en ce qui me concerne, je pense qu'il faut identifier les 2 branches et passer à la RC1.
Emmanuel
Le 24 sept. 08 à 13:56, Committo,Ergo:sum a écrit :
Le 24 sept. 08 à 13:33, cedric@yterium.com a écrit :
Author: cedric@yterium.com
Date: 2008-09-24 13:32:58 +0200 (mer, 24 sep 2008)
New Revision: 12767Log:
?var_mode=blocs pour encadrer et legender du nom du squellette utilise toutes les inclusions
la centralisation des inclusion par recuperer_fond permet facilement la mise en place de cette fonction de debug supplementaireModified:
branches/spip-2.0/ecrire/inc/utils.php ....Euh bon, là de nouveau j'ai l'impression qu'on part sur du dev je ne comprends pas ce que ça fait dans la branche 2.0 plutot que dans l'autre.
Je sais bien que ce que j'ai fait récemment ressemblait aussi à du dev, mais c'était toujours sous-tendu par une mise au propre du code (calculer_url_* ça faisait tout et son contraire, fallait y mettre le hola).Donc, en ce qui me concerne, je pense qu'il faut identifier les 2 branches et passer à la RC1.
C'est juste du fignolage, bon pour les deux branches (il faut que je reporte), rendu possible par la rationalisation recente du code, et qui manquait beaucoup.
Je finis juste l'optimisation des requete hors compilation lors du calcul (il y a de nombreux "select id_rubrique from spip_rubriques" redondant) et c'est bon pour moi aussi.
Cédric
Le 24 sept. 08 à 14:20, cedric.morin@yterium.com a écrit :
C'est juste du fignolage, bon pour les deux branches (il faut que je reporte),
Tant mieux, mais c'est pas un bon plan de faire ça en 2 temps, a fortiori envoyant d'abord sur ls branche dite stable.
Pour une fois je ne donne pas tort à Hoizey.
Emmanuel
Je ne suis pas contre une rc1 ... Il faudra qu'on insiste vraiment
pour que les gens testent la procedure de migration ( le danger etant
que seuls les habitues migrent, ceux qui savent migrer ou faire un svn
update )
On 9/24/08, Committo,Ergo:sum <esj@rezo.net> wrote:
Le 24 sept. 08 à 14:20, cedric.morin@yterium.com a écrit :
C'est juste du fignolage, bon pour les deux branches (il faut que je
reporte),Tant mieux, mais c'est pas un bon plan de faire ça en 2 temps, a
fortiori envoyant d'abord sur ls branche dite stable.
Pour une fois je ne donne pas tort à Hoizey.Emmanuel
_______________________________________________
spip-team@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-team
Bon, en cherchant pourquoi on avait autant de requetes hors compilation avec
?var_mode=calcul
je m'aperçois que toutes les urls propres contenues dans une page sont mises à jour à ce moment.
Il me semble que c'est un peu excessif par rapport à l'intention initiale qui est de mettre a jour l'url de l'objet sur lequel on fait 'voir en ligne', non ?
En particulier, on ne maîtrise pas du tout la portée des mises à jour d'url (si l'on veut mettre a jour l'url de A mais pas celle de B mais que A contient l'url de B dans sa page, c'est impossible)
limite le nombre de requêtes en découlant en ne vérifiant les autorisations que lorsque cela est nécessaire, mais je pense qu'il faudrait éviter ce recalcul massif d'urls.
Je ne sais pas si il faut repasser par un redirect comme auparavant ou si on peut vérifier qu'on ne met a jour que l'url de la page en cours ?
Cédric
Le 24 sept. 08 à 14:26, Committo,Ergo:sum a écrit :
Le 24 sept. 08 à 14:20, cedric.morin@yterium.com a écrit :
C'est juste du fignolage, bon pour les deux branches (il faut que je reporte),
Tant mieux, mais c'est pas un bon plan de faire ça en 2 temps, a fortiori envoyant d'abord sur ls branche dite stable.
Pour une fois je ne donne pas tort à Hoizey.Emmanuel
Le 24 sept. 08 à 16:01, cedric.morin@yterium.com a écrit :
Bon, en cherchant pourquoi on avait autant de requetes hors compilation avec
?var_mode=calcul
je m'aperçois que toutes les urls propres contenues dans une page sont mises à jour à ce moment.Il me semble que c'est un peu excessif par rapport à l'intention initiale qui est de mettre a jour l'url de l'objet sur lequel on fait 'voir en ligne', non ?
En particulier, on ne maîtrise pas du tout la portée des mises à jour d'url (si l'on veut mettre a jour l'url de A mais pas celle de B mais que A contient l'url de B dans sa page, c'est impossible)
Connexion · GitLab
limite le nombre de requêtes en découlant en ne vérifiant les autorisations que lorsque cela est nécessaire, mais je pense qu'il faudrait éviter ce recalcul massif d'urls.Je ne sais pas si il faut repasser par un redirect comme auparavant ou si on peut vérifier qu'on ne met a jour que l'url de la page en cours ?
??? Ca n'a rien à voir avec le redirect d'avant, ça a toujours été comme ça.
Emmanuel
Le 24 sept. 08 à 16:06, Committo,Ergo:sum a écrit :
Le 24 sept. 08 à 16:01, cedric.morin@yterium.com a écrit :
Bon, en cherchant pourquoi on avait autant de requetes hors compilation avec
?var_mode=calcul
je m'aperçois que toutes les urls propres contenues dans une page sont mises à jour à ce moment.Il me semble que c'est un peu excessif par rapport à l'intention initiale qui est de mettre a jour l'url de l'objet sur lequel on fait 'voir en ligne', non ?
En particulier, on ne maîtrise pas du tout la portée des mises à jour d'url (si l'on veut mettre a jour l'url de A mais pas celle de B mais que A contient l'url de B dans sa page, c'est impossible)
Connexion · GitLab
limite le nombre de requêtes en découlant en ne vérifiant les autorisations que lorsque cela est nécessaire, mais je pense qu'il faudrait éviter ce recalcul massif d'urls.Je ne sais pas si il faut repasser par un redirect comme auparavant ou si on peut vérifier qu'on ne met a jour que l'url de la page en cours ?
??? Ca n'a rien à voir avec le redirect d'avant, ça a toujours été comme ça.
Non nullement, le bouton 'voir en ligne' ne provoquait que la mise a jour de l'url de l'objet concerné qui ne pouvait se faire que lors de l'appel depuis l'action redirect :
et un simple ?var_mode=calcul utilisé pour mettre a jour une page ne modifiait aucune url.
La on est dans un mode où l'on ne contrôle plus la mise a jour des urls objet par objet.
Cédric
Le 24 sept. 08 à 16:13, cedric.morin@yterium.com a écrit :
Je ne sais pas si il faut repasser par un redirect comme auparavant ou si on peut vérifier qu'on ne met a jour que l'url de la page en cours ?
??? Ca n'a rien à voir avec le redirect d'avant, ça a toujours été comme ça.
Non nullement, le bouton 'voir en ligne' ne provoquait que la mise a jour de l'url de l'objet concerné qui ne pouvait se faire que lors de l'appel depuis l'action redirect :
Connexion · GitLab
et un simple ?var_mode=calcul utilisé pour mettre a jour une page ne modifiait aucune url.
Le test dont tu parles ligne 67 et suivantes a été remplacé par
(_request('var_mode') == 'calcul')
je ne vois pas en quoi il ne serait pas équivalent à ce qu'il y avait avant.
Emmanuel
(Note: pourquoi sur spip-team et pas spip-dev ?)
Le 24 sept. 08 à 15:44, ben.spip@gmail.com a écrit :
Je ne suis pas contre une rc1 ... Il faudra qu'on insiste vraiment
pour que les gens testent la procedure de migration ( le danger etant
que seuls les habitues migrent, ceux qui savent migrer ou faire un svn
update )
Bon je vois que sur spip-blog tu as déjà balisé le terrain.
En ce qui concerne ce fil là:
http://www.spip-blog.net/SPIP-dans-le-LHC.html#co
tu pourrais pas enlever le spam ?
Et qui a eu la curiosité d'aller le CMS pas comme les autres dont je parle ?
Emmanuel