Author: fil@rezo.net
Date: 2007-10-01 16:32:02 +0200 (lun, 01 oct 2007)
New Revision: 10469
Log:
la hierarchie etait bien mis en cache, mais le premier passage etait flingue
Modified:
spip/ecrire/public/composer.php
Le 1 oct. 07 à 16:32, fil@rezo.net a écrit :
Author: fil@rezo.net
Date: 2007-10-01 16:32:02 +0200 (lun, 01 oct 2007)
New Revision: 10469Log:
la hierarchie etait bien mis en cache, mais le premier passage etait flingueModified:
spip/ecrire/public/composer.php
Cette balise me pose décidément problème. Son 3e argument est carrément tout le tableau des variables d'URL, et on y recherche celles commençant par "id_" et de valeur non nulle. La méconnaissance de ce qu'on aura à l'execution oblige à faire un bout de compil à l'exécution, ce qui est anormal. Par ailleurs il semble qu'il y ait l'hypothèse implicite qu'il n'y aura qu'une seule variable d'URL ayant cette double propriété, mais on parcourt quand même tout le tableau après en avoir trouvé une.
Dans tous les exemples que je connais de EXPOSE, dans chacune de ses utilisations cette variable commençant par "id_" est toujours la même: l'URL du squelette utilisé n'aura pas un jour id_article, un autre jour id_rubrique etc.
De plus cette variable est toujours la clé primaire d'une boucle englobant la balise (souvent c'est même la première boucle englobante, dans la dist la seule exception est le squelette article avec BOUCLE_documents_portfolio(DOCUMENTS) dont l'EXPOSE référence implicitement id_article).
Je ferai remarquer qu'il n'existe pas de balise #LOGO tout court dont le compilateur inférerait de quel logo il peut s'agir, on a préféré introduire une famille de balises #LOGO_ARTICLE, #LOGO_RUBRIQUE etc. Je suis donc favorable à ce qu'on exige des auteurs de squelettes qu'ils précisent leur pensée en écrivant #EXPOSE_ARTICLE, #EXPOSE_RUBRIQUE etc, ce qui rendrait le calcul des pages plus rapide, et augmenterait la lisibilité des squelettes et celle de la sémantique de SPIP.
Committo,Ergo:Sum
Cette balise me pose décidément problème. Son 3e argument est
carrément tout le tableau des variables d'URL, et on y recherche
celles commençant par "id_" et de valeur non nulle. La méconnaissance
Donc en gros il y avait un assassinat, mais c'était de la faute de la
victime, et au fond pour son bien 
D'accord avec ton analyse mais il faut aussi vivre avec l'héritage, et
donc conserver #EXPOSE, qui marche bien si on évite de l'assassiner de
temps en temps. Introduire #EXPOSE_ARTICLE, c'est peut-être bon pour
le compilo, mais ça me paraît peu clair pour l'auteur des squelettes,
car (cas de la page d'un article) on veut aussi exposer les rubriques
qui mènent à un article.
-- Fil
Le 1 oct. 07 à 20:56, Fil a écrit :
Cette balise me pose décidément problème. Son 3e argument est
carrément tout le tableau des variables d'URL, et on y recherche
celles commençant par "id_" et de valeur non nulle. La méconnaissanceDonc en gros il y avait un assassinat,
juste un bali-cide involontaire
mais c'était de la faute de la
victime, et au fond pour son bienD'accord avec ton analyse mais il faut aussi vivre avec l'héritage, et
donc conserver #EXPOSE, qui marche bien si on évite de l'assassiner de
temps en temps.
On peut la conserver en disant que ça se rapporte à clé primaire de la boucle immédiatement englobante, ce qui représente 90% des cas dans la dist, et on peut penser 99% de l'usage général.
Introduire #EXPOSE_ARTICLE, c'est peut-être bon pour
le compilo,
et pour ses utilisateurs...
mais ça me paraît peu clair pour l'auteur des squelettes,
car (cas de la page d'un article) on veut aussi exposer les rubriques
qui mènent à un article.
Moi ça me parait déjà plus clair que "EXPOSE" tout court, et c'est ce manque de clarté qui m'a fait commettre autant de bugs là-dessus. Avec la précision ci-dessus, je crois que #EXPOSE_qqch est vraiment pas mal: on EXPOSE la clé primaire de la boucle courante et sa hiérarchie, ou la clé primaire d'une autre boucle et sa hiérarchie quand on précise EXPOSE_qqch. Une autre solution est de nommer la boucle, avec la syntaxe qu'on a déjà: #_article:EXPOSE si _article est le nom d'une boucle englobante.
Committo,Ergo:Sum
> Introduire #EXPOSE_ARTICLE, c'est peut-être bon pour
> le compilo,
et pour ses utilisateurs...
ben non, en tous cas pas tous ; pour moi, insister sur _ARTICLE
(#EXPOSE_ARTICLE) évoquerait plutôt "l'exposition de l'article mais
pas de sa hiérarchie"
> mais ça me paraît peu clair pour l'auteur des squelettes,
> car (cas de la page d'un article) on veut aussi exposer les rubriques
> qui mènent à un article.Moi ça me parait déjà plus clair que "EXPOSE" tout court, et c'est ce
#EXPOSE part du principe qu'il n'y a qu'un seul "objet principal" dans
la page. A partir de là on calcule cet objet et sa hiérarchie, et on
expose ceux-là. Quel est le cas qui t'ennuie ?
-- Fil
Le 1 oct. 07 à 21:34, Fil a écrit :
Introduire #EXPOSE_ARTICLE, c'est peut-être bon pour
le compilo,et pour ses utilisateurs...
ben non, en tous cas pas tous ;
bah si, ça c'est irréfutable: si le compilateur produit du meilleur code, c'est bon pour ses utilisateurs. La question est de savoir si le prix est trop cher sur d'autres plans.
pour moi, insister sur _ARTICLE
(#EXPOSE_ARTICLE) évoquerait plutôt "l'exposition de l'article mais
pas de sa hiérarchie"
On peut mettre EXPOSE_HIERARCHIE_ARTICLE si tu y tiens
mais ça me paraît peu clair pour l'auteur des squelettes,
car (cas de la page d'un article) on veut aussi exposer les rubriques
qui mènent à un article.Moi ça me parait déjà plus clair que "EXPOSE" tout court, et c'est ce
#EXPOSE part du principe qu'il n'y a qu'un seul "objet principal" dans
la page. A partir de là on calcule cet objet et sa hiérarchie, et on
expose ceux-là. Quel est le cas qui t'ennuie ?
Le pb est toujours le même: si tu as écris "objet principal" entre guillemets c'est bien parce qu'il y a un contexte non explicité, et tu comptes sur l'intelligence humaine pour comprendre, chose qui n'est pas à la portée d'un ordinateur. L'informatique, c'est moins la science de l'information que de l'explicitation: si tu n'explicites pas aux machines ce que tu veux, elles ne vont pas le faire, ou très mal. Il faut donc expliciter ce que veut dire "objet principal", et je propose "la clé primaire de la boucle immédiatement englobante", en utilisant un marqueur syntaxique qu'on sait déjà gérer pour le cas rare où l'"objet principal" n'est pas ça, comme dans la boucle document du squelette article.
Committo,Ergo:Sum
Il faut donc expliciter ce que veut dire "objet principal", et
je propose "la clé primaire de la boucle immédiatement englobante",
en utilisant un marqueur syntaxique qu'on sait déjà gérer pour le cas
rare où l'"objet principal" n'est pas ça, comme dans la boucle
document du squelette article.
L'objet principal c'est celui qui est déterminé par le contexte de la
page). Ca ne pose pas de problème pour spip_urls
-- Fil
Le 1 oct. 07 à 22:39, Fil a écrit :
Il faut donc expliciter ce que veut dire "objet principal", et
je propose "la clé primaire de la boucle immédiatement englobante",
en utilisant un marqueur syntaxique qu'on sait déjà gérer pour le cas
rare où l'"objet principal" n'est pas ça, comme dans la boucle
document du squelette article.L'objet principal c'est celui qui est déterminé par le contexte de la
page). Ca ne pose pas de problème pour spip_urls
Quel rapport ? Ca ne lui en pose pas parce qu'il y a un table SQL à clé unique qui explicite le contexte immédiatement. Tandis que quand le compilateur compile un squelette il n'a pas sous la main l'URL où est explicité le id_qqch qui lui manque.
T'est sûr que tu étais d'accord avec mon analyse ?
Committo,Ergo:Sum
T'est sûr que tu étais d'accord avec mon analyse ?
Ca me rappelle un schtroumpf
Oui je comprends ce que tu dis : quand on compile on sait pas comment
est fait le contexte. Mais quand on calcule on le sait, et donc ça
marche. Autrement dit ce qui est bon pour le compilo n'est pas
forcément bon pour l'utilisateur. CQFD.
A mauvaise foi, mauvaise foi et demi !
-- Fil
Le 1 oct. 07 à 23:01, Fil a écrit :
T'est sûr que tu étais d'accord avec mon analyse ?
Ca me rappelle un schtroumpf
Oui je comprends ce que tu dis : quand on compile on sait pas comment
est fait le contexte. Mais quand on calcule on le sait, et donc ça
marche. Autrement dit ce qui est bon pour le compilo n'est pas
forcément bon pour l'utilisateur. CQFD.A mauvaise foi, mauvaise foi et demi !
Mauvaise foi ? Je pose une question très claire: est-il légitime de gréver le temps de calcul des pages dont le squelette comporte une balise EXPOSE, parce que leurs utilisateurs ont la flemme de taper 8 caractères de plus dans 1 cas d'utilisation sur 10 ? Je ne comprends pas que tu puisses répondre "oui".
Committo,Ergo:Sum
> A mauvaise foi, mauvaise foi et demi !
Mauvaise foi ? Je pose une question très claire: est-il légitime de
gréver le temps de calcul des pages dont le squelette comporte une
balise EXPOSE, parce que leurs utilisateurs ont la flemme de taper 8
caractères de plus dans 1 cas d'utilisation sur 10 ? Je ne comprends
pas que tu puisses répondre "oui".
Le problème c'est pas de taper des caractères, c'est de faire quelque
chose de lisible. La balise #EXPOSE existe, elle marche bien, et elle
ne "grève" pas les calculs, faut pas charrier. Sinon on va compter les
millisecondes des define() et des @ tant qu'on y est ???
Allez, stop.
-- Fil
Le 1 oct. 07 à 23:11, Fil a écrit :
A mauvaise foi, mauvaise foi et demi !
Mauvaise foi ? Je pose une question très claire: est-il légitime de
gréver le temps de calcul des pages dont le squelette comporte une
balise EXPOSE, parce que leurs utilisateurs ont la flemme de taper 8
caractères de plus dans 1 cas d'utilisation sur 10 ? Je ne comprends
pas que tu puisses répondre "oui".Le problème c'est pas de taper des caractères, c'est de faire quelque chose de lisible.
Que tout le monde trouve lisible, oui. En ce qui me concerne, je l'ai toujours trouvé incompréhensible.
La balise #EXPOSE existe, elle marche bien,
Elle marche pour les cas précis que tu as en tête, point. Elle devrait pouvoir se généraliser à n'importe quelle table non SPIP, dont la clé primaire ne commence pas nécessairement par "id_". Pourquoi veux-tu absolument la limiter ?
et elle ne "grève" pas les calculs, faut pas charrier.
On trouve toujours pire évidemment. Mais c'est aussi une question de lisibilité du code de SPIP: à l'exécution on devrait pas devoir appeler des bouts du compilateur.
Allez, stop.
pourquoi ?
Committo,Ergo:Sum
> Allez, stop.
pourquoi ?
parce que je n'ai plus rien à dire sur le sujet ! tu peux continuer
tout seul 
-- Fil
Le 1 oct. 07 à 23:22, Fil a écrit :
Allez, stop.
pourquoi ?
parce que je n'ai plus rien à dire sur le sujet ! tu peux continuer
tout seul
Bon, alors je vais continuer par le commit 
Committo,Ergo:Sum
Le 1 oct. 07 à 18:57, Committo,Ergo:sum a écrit :
Dans tous les exemples que je connais de EXPOSE, dans chacune de ses utilisations cette variable commençant par "id_" est toujours la même: l'URL du squelette utilisé n'aura pas un jour id_article, un autre jour id_rubrique etc.
De plus cette variable est toujours la clé primaire d'une boucle englobant la balise (souvent c'est même la première boucle englobante, dans la dist la seule exception est le squelette article avec BOUCLE_documents_portfolio(DOCUMENTS) dont l'EXPOSE référence implicitement id_article).
Ca devient comique: l'implémentation de #EXPOSE depuis son introduction en 1.8 fait que cet unique exemple n'est pas opérationnel: la fonction calcul_exposer recoit en argument le nom de la clé primaire de la boucle englobante, ici "id_document", et alimente les index "id_article" et "id_rubrique" de sa variable statique en espérant vainement que ça mettra qqch dans son index "id_document"!
Les choses sont donc claires: #EXPOSE repère si la clé primaire de la boucle courante a pour valeur la même que la variable d'URL homonyme. J'introduis en plus #nomboucle:EXPOSE qui permet de référencer un autre nom de clé primaire, on verra si des utilisateurs en auront vraiment l'usage.
Committo,Ergo:Sum
Le 2 oct. 07 à 12:00, Committo,Ergo:sum a écrit :
Ca devient comique: l'implémentation de #EXPOSE depuis son
introduction en 1.8 fait que cet unique exemple n'est pas
opérationnel: la fonction calcul_exposer recoit en argument le nom de
la clé primaire de la boucle englobante, ici "id_document", et
alimente les index "id_article" et "id_rubrique" de sa variable
statique en espérant vainement que ça mettra qqch dans son index
"id_document"!
Autre découverte: la statique mémorisant les calculs, mais se remettant à zéro pour les squelettes inclus se remet visiblement aussi à 0 car il y a visiblement un appel avant la conversion URL_propre et un autre après. Ca doit être un modèle, on peut admettre que c'est effectivement ce qu'il faut mais ça peut se discuter.
Committo,Ergo:Sum