Author: fil@rezo.net
Date: 2009-02-12 13:01:43 +0100 (jeu, 12 fév 2009)
New Revision: 13720
Log:
report de [13719] nouvelle API d'URLs
Modified:
branches/spip-2.0/ecrire/inc/utils.php
branches/spip-2.0/ecrire/public/assembler.php
branches/spip-2.0/ecrire/urls/arbo.php
branches/spip-2.0/ecrire/urls/html.php
branches/spip-2.0/ecrire/urls/page.php
branches/spip-2.0/ecrire/urls/propres.php
S'lt
Ce commit semble casser les url arbo.
Soit http://monsite.tld/titrerub1/titrerub2
Pour cette url, #ID_RUBRIQUE obtenu est celle de rub1 et non rub2
Vu l'heure, je ne suis pas aller plus loin qu'une bisection dans les
commits pour trouver ce commit comme coupable.
Km
S'lt
Bon pour ma part j'arrive pas à m'en sortir dans le code.
A coup de spip log, je vois que ça remonte l'url et retourne la racine.
J'ai rub1 qui contient rub2 et rub3
si je souhaite accéder à rub1/rub2, ça passe par rub2 puis rub3 puis rub1
c'est rub1 qui est retourné à la fin dans assembler.php
Je ne sais pas si ça joue mais mes titre de rubrique sont inégralement
numérique.
Aucune idée si ça peut etre utile, voici une trac de que j'obtiens :
url assembler:/151/15169800805158/
Feb 20 11:31:23 89.96.108.169 (pid 16311) i : /151/15169800805158/
Feb 20 11:31:23 89.96.108.169 (pid 16311) entite : type_urls
Feb 20 11:31:23 89.96.108.169 (pid 16311) args :
Feb 20 11:31:23 89.96.108.169 (pid 16311) ancre :
Feb 20 11:31:23 89.96.108.169 (pid 16311) type : 0
Feb 20 11:31:23 89.96.108.169 (pid 16311) _id :
Feb 20 11:31:23 89.96.108.169 (pid 16311) id_objet : 0
Feb 20 11:31:23 89.96.108.169 (pid 16311) a : Array
(
[0] => Array
(
[page] => type_urls
[id_rubrique] => 1
)
[1] => rubrique
)
Feb 20 11:31:24 89.96.108.169 (pid 16311) i : 2
Feb 20 11:31:24 89.96.108.169 (pid 16311) entite : rubrique
Feb 20 11:31:24 89.96.108.169 (pid 16311) args :
Feb 20 11:31:24 89.96.108.169 (pid 16311) ancre :
Feb 20 11:31:24 89.96.108.169 (pid 16311) url : 151/15169800805158/
Feb 20 11:31:24 89.96.108.169 (pid 16311) i : 31
Feb 20 11:31:24 89.96.108.169 (pid 16311) entite : rubrique
Feb 20 11:31:24 89.96.108.169 (pid 16311) args :
Feb 20 11:31:24 89.96.108.169 (pid 16311) ancre :
Feb 20 11:31:24 89.96.108.169 (pid 16311) url : 151/15169210107735/
Feb 20 11:31:24 89.96.108.169 (pid 16311) i : 1
Feb 20 11:31:24 89.96.108.169 (pid 16311) entite : rubrique
Feb 20 11:31:24 89.96.108.169 (pid 16311) args :
Feb 20 11:31:24 89.96.108.169 (pid 16311) ancre :
Feb 20 11:31:24 89.96.108.169 (pid 16311) url : 151/
Km
Ca ne va pas résoudre ton problème (que je n'ai pas n'ayant qu'un niveau de rubriques) mais je pense vraiment que stocker l'URL complète serait bien mieux :
- pas ce soucis que tu signales
- possibilité d'avoir des éléments de même nom situés dans des arbos différentes sans avoir un id numérique dans l'URL résultante
Le 20 févr. 09 à 11:41, cam.lafit@azerttyu.net a écrit :
S'lt
Bon pour ma part j'arrive pas à m'en sortir dans le code.
A coup de spip log, je vois que ça remonte l'url et retourne la racine.J'ai rub1 qui contient rub2 et rub3
si je souhaite accéder à rub1/rub2, ça passe par rub2 puis rub3 puis rub1c'est rub1 qui est retourné à la fin dans assembler.php
Je ne sais pas si ça joue mais mes titre de rubrique sont inégralement
numérique.Aucune idée si ça peut etre utile, voici une trac de que j'obtiens :
url assembler:/151/15169800805158/
Feb 20 11:31:23 89.96.108.169 (pid 16311) i : /151/15169800805158/
Feb 20 11:31:23 89.96.108.169 (pid 16311) entite : type_urls
Feb 20 11:31:23 89.96.108.169 (pid 16311) args :
Feb 20 11:31:23 89.96.108.169 (pid 16311) ancre :
Feb 20 11:31:23 89.96.108.169 (pid 16311) type : 0
Feb 20 11:31:23 89.96.108.169 (pid 16311) _id :
Feb 20 11:31:23 89.96.108.169 (pid 16311) id_objet : 0
Feb 20 11:31:23 89.96.108.169 (pid 16311) a : Array
(
[0] => Array
(
[page] => type_urls
[id_rubrique] => 1
)[1] => rubrique
)Feb 20 11:31:24 89.96.108.169 (pid 16311) i : 2
Feb 20 11:31:24 89.96.108.169 (pid 16311) entite : rubrique
Feb 20 11:31:24 89.96.108.169 (pid 16311) args :
Feb 20 11:31:24 89.96.108.169 (pid 16311) ancre :
Feb 20 11:31:24 89.96.108.169 (pid 16311) url : 151/15169800805158/
Feb 20 11:31:24 89.96.108.169 (pid 16311) i : 31
Feb 20 11:31:24 89.96.108.169 (pid 16311) entite : rubrique
Feb 20 11:31:24 89.96.108.169 (pid 16311) args :
Feb 20 11:31:24 89.96.108.169 (pid 16311) ancre :
Feb 20 11:31:24 89.96.108.169 (pid 16311) url : 151/15169210107735/
Feb 20 11:31:24 89.96.108.169 (pid 16311) i : 1
Feb 20 11:31:24 89.96.108.169 (pid 16311) entite : rubrique
Feb 20 11:31:24 89.96.108.169 (pid 16311) args :
Feb 20 11:31:24 89.96.108.169 (pid 16311) ancre :
Feb 20 11:31:24 89.96.108.169 (pid 16311) url : 151/Km
_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/
-Nicolas
--
Nicolas HOIZEY
Le 20 févr. 09 à 11:56, Nicolas Hoizey a écrit :
Ca ne va pas résoudre ton problème (que je n'ai pas n'ayant qu'un niveau de rubriques) mais je pense vraiment que stocker l'URL complète serait bien mieux :
- pas ce soucis que tu signales
- possibilité d'avoir des éléments de même nom situés dans des arbos différentes sans avoir un id numérique dans l'URL résultante
On en a déja parlé, et c'est une mauvaise idée car :
- lorsque l'url d'une rubrique change, ca oblige à changer l'url de tous les objets qui sont dedans
-> grossissement possible de la base tres rapide sur un gros site
-> timeout possible au changement d'url
c'est par ailleurs une méthode figée et non extensible.
Alors qu'avec l'implémentation actuelle tu peux construire dans ton squelette une url du type
#URL_ARTICLE/#URL_MOT
qui te produira par exemple un
rubrique1/rubrique2/rubrique3/article/tag
et sera decodee en
?page=article&id_article=X&id_mot=Y
ta proposition ne permet plus cela en n'identifiant que les urls complètes et non les segment séparément.
Quand a éviter les postfixe -NN avec les id numériques, c'est certes plus facile avec ta proposition, mais tu sais bien que la politique de la maison n'est pas d'opter pour la facilité de codage, et qu'on privilégie toujours le fonctionnel même si c'est plus long à mûrir et à coder.
Cédric
Le 20 févr. 09 à 12:33, cedric.morin@yterium.com a écrit :
Le 20 févr. 09 à 11:56, Nicolas Hoizey a écrit :
Ca ne va pas résoudre ton problème (que je n'ai pas n'ayant qu'un niveau de rubriques) mais je pense vraiment que stocker l'URL complète serait bien mieux :
- pas ce soucis que tu signales
- possibilité d'avoir des éléments de même nom situés dans des arbos différentes sans avoir un id numérique dans l'URL résultanteOn en a déja parlé
Certes...
et c'est une mauvaise idée car :
- lorsque l'url d'une rubrique change, ca oblige à changer l'url de tous les objets qui sont dedans
-> grossissement possible de la base tres rapide sur un gros site
Oui.
-> timeout possible au changement d'url
Il n'est pas nécessaire de changer toutes les URL en même temps, ça peut être fait au fur et à mesure, puisqu'on a les redirections.
c'est par ailleurs une méthode figée et non extensible.
Alors qu'avec l'implémentation actuelle tu peux construire dans ton squelette une url du type#URL_ARTICLE/#URL_MOT
qui te produira par exemple un
rubrique1/rubrique2/rubrique3/article/taget sera decodee en
?page=article&id_article=X&id_mot=Y
Ca marche déjà ça ? Je ne l'avais jamais envisagé. Tu l'avais déjà signalé ?
ta proposition ne permet plus cela en n'identifiant que les urls complètes et non les segment séparément.
Effectivement.
Quand a éviter les postfixe -NN avec les id numériques, c'est certes plus facile avec ta proposition
Euh... il me semble que c'est « possible », plutôt que « facile », puisque tu n'avais pas trouvé comment faire avec ta méthode actuelle.
mais tu sais bien que la politique de la maison n'est pas d'opter pour la facilité de codage, et qu'on privilégie toujours le fonctionnel même si c'est plus long à mûrir et à coder.
Bin justement, ne pas avoir d'id dans les URL, c'est pour moi un meilleur fonctionnel, pas une facilité de codage.
Je ne dis pas que la méthode actuelle n'a pas d'avantage par rapport à ce que j'avais avant, mais ce point sur les id est vraiment une grosse régression.
-Nicolas
--
Nicolas HOIZEY
Le 20 févr. 09 à 13:01, Nicolas Hoizey a écrit :
Le 20 févr. 09 à 12:33, cedric.morin@yterium.com a écrit :
Le 20 févr. 09 à 11:56, Nicolas Hoizey a écrit :
...
c'est par ailleurs une méthode figée et non extensible.
Alors qu'avec l'implémentation actuelle tu peux construire dans ton squelette une url du type#URL_ARTICLE/#URL_MOT
qui te produira par exemple un
rubrique1/rubrique2/rubrique3/article/taget sera decodee en
?page=article&id_article=X&id_mot=YCa marche déjà ça ? Je ne l'avais jamais envisagé. Tu l'avais déjà signalé ?
oui, cela marche, et c'est dans un site pour lequel j'ai développée les url arbos 
ta proposition ne permet plus cela en n'identifiant que les urls complètes et non les segment séparément.
Effectivement.
Quand a éviter les postfixe -NN avec les id numériques, c'est certes plus facile avec ta proposition
Euh... il me semble que c'est « possible », plutôt que « facile », puisque tu n'avais pas trouvé comment faire avec ta méthode actuelle.
oh, il est certain que la méthode actuelle le rend possible car on a toute l'information nécessaire pour le faire à savoir la hierarchie complète de l'objet.
la question et juste de trouver la meilleure implémentation.
mais tu sais bien que la politique de la maison n'est pas d'opter pour la facilité de codage, et qu'on privilégie toujours le fonctionnel même si c'est plus long à mûrir et à coder.
Bin justement, ne pas avoir d'id dans les URL, c'est pour moi un meilleur fonctionnel, pas une facilité de codage.
Ca n'était pas la priorité dans mes specs ...
Je ne dis pas que la méthode actuelle n'a pas d'avantage par rapport à ce que j'avais avant, mais ce point sur les id est vraiment une grosse régression.
il n'y avait pas d'implémentation utilisable par tout le monde avant, donc on ne peut pas parler de régression.
Pour parler de régression, il aurait fallu que tu propose une version packagée, fonctionnelle, complète et utilisable simplement de ton implémentation.
Cédric
Le 20 févr. 09 à 13:10, cedric.morin@yterium.com a écrit :
Le 20 févr. 09 à 13:01, Nicolas Hoizey a écrit :
Le 20 févr. 09 à 12:33, cedric.morin@yterium.com a écrit :
Le 20 févr. 09 à 11:56, Nicolas Hoizey a écrit :
...
c'est par ailleurs une méthode figée et non extensible.
Alors qu'avec l'implémentation actuelle tu peux construire dans ton squelette une url du type#URL_ARTICLE/#URL_MOT
qui te produira par exemple un
rubrique1/rubrique2/rubrique3/article/taget sera decodee en
?page=article&id_article=X&id_mot=YCa marche déjà ça ? Je ne l'avais jamais envisagé. Tu l'avais déjà signalé ?
oui, cela marche, et c'est dans un site pour lequel j'ai développée les url arbos
OK, intéressant ! Comment il reconnaît que "tag" est un mot clef dans ton exemple ?
ta proposition ne permet plus cela en n'identifiant que les urls complètes et non les segment séparément.
Effectivement.
Quand a éviter les postfixe -NN avec les id numériques, c'est certes plus facile avec ta proposition
Euh... il me semble que c'est « possible », plutôt que « facile », puisque tu n'avais pas trouvé comment faire avec ta méthode actuelle.
oh, il est certain que la méthode actuelle le rend possible car on a toute l'information nécessaire pour le faire à savoir la hierarchie complète de l'objet.
la question et juste de trouver la meilleure implémentation.
OK, je vais me repencher dessus alors, dès que j'aurais régler mes problèmes de forums...
mais tu sais bien que la politique de la maison n'est pas d'opter pour la facilité de codage, et qu'on privilégie toujours le fonctionnel même si c'est plus long à mûrir et à coder.
Bin justement, ne pas avoir d'id dans les URL, c'est pour moi un meilleur fonctionnel, pas une facilité de codage.
Ca n'était pas la priorité dans mes specs ...
Euh... c'est pas un truc perso, là, c'est dans le core de SPIP, donc l'intérêt général prime, non ? 
Je ne dis pas que la méthode actuelle n'a pas d'avantage par rapport à ce que j'avais avant, mais ce point sur les id est vraiment une grosse régression.
il n'y avait pas d'implémentation utilisable par tout le monde avant, donc on ne peut pas parler de régression.
Pour parler de régression, il aurait fallu que tu propose une version packagée, fonctionnelle, complète et utilisable simplement de ton implémentation.
Je l'ai viré quand tu as mis ta propre version dans le core, j'ai découvert trop tard ce qui est dans mon cas une régression, mais je me suis dit qu'être sur le core plutôt qu'un plugin méritait un compromis.
-Nicolas
--
Nicolas HOIZEY