------
Dans le cadre de la mutualisation des sources de Spip, il est souhaitable de ramener tous les petits scripts initialisant les variables $fond et $delais à un seul.
C'est une louable intention,
merci ESJ pour tout ce travail.
J'attire toutefois ton attention sur la perte de sémantique.
Je cause pas dublin core ou autre web3technology++,
mais juste du patois humain qu'on cause devant la machine à café.
Là où $délais=24*3600; était clair pour tous
(y compris le webmaster chez free),
tu substitue un #HTTP{7200}
franchement ésotérique et antimnémotechnique,
donc carrément dissuadif pour quelqu'un qui aborderait spip.
C'est plaisant à court terme
parceque c'est plus facile pour automatiser la substitution ?
Mais quid à la suite quand la V1.9 sera oubliée
et qu'on se demandera pourquoi cette particularité syntaxique ?
Si particularité syntaxique tu introduis,
alors stp qu'elle soit claire et durablement plaisante.
Par exemple #DELAIS(24*3600)
Qui à l'avantage secondaire
d'être compris par tout anglophone de bonne volonté.
Déesse A. a écrit :
> > ------
> > Dans le cadre de la mutualisation des sources de Spip, il est
> > souhaitable de ramener tous les petits scripts initialisant les
> > variables $fond et $delais à un seul.
C'est une louable intention,
merci ESJ pour tout ce travail.
J'attire toutefois ton attention sur la perte de sémantique.
Je cause pas dublin core ou autre web3technology++,
mais juste du patois humain qu'on cause devant la machine à café.
Là où $délais=24*3600; était clair pour tous
(y compris le webmaster chez free),
tu substitue un #HTTP{7200}
franchement ésotérique et antimnémotechnique,
donc carrément dissuadif pour quelqu'un qui aborderait spip.
C'est plaisant à court terme
parceque c'est plus facile pour automatiser la substitution ?
Mais quid à la suite quand la V1.9 sera oubliée
et qu'on se demandera pourquoi cette particularité syntaxique ?
Si particularité syntaxique tu introduis,
alors stp qu'elle soit claire et durablement plaisante.
Par exemple #DELAIS{24*3600}
Qui à l'avantage secondaire
d'être compris par tout anglophone de bonne volonté.
La nouvelle gestion des délais, compatible avec la mutualisation,
consiste à indiquer dans le squelette, à l'aide d'une balise, la
duree de vie des pages qu'il produit.
Ce qui signifie que la durée de vie est uniquement indiquée par le
squelette et plus du tout par l'appelant.
Je répète que s'il n'y a pas la directive max-age dans le squelette, Spip se comporte comme avant donc en tenant compte de la globale $delais.
Une fois stabilisés, les fichiers standards de Spip n'utiliseront plus cette fonctionnalité mais elle sera toujours maintenue.
Donc, on ne peut pas adapter
le délai à certains éléments de l'url (j'ai pas d'exemple concret en
tête, mais il me semble que j'ai déjà été confronté à ce problème),
Sur le principe ce n'est pas bon car ça prete le flanc au déni de service: ce n'est pas aux visiteurs de régler le fonctionnement du cache.
ou
appliquer un délai différent à un "inclu".
Pour le second cas, est-ce qu'il est possible de passer le delai en
paramètre dans un <inclure> ?
Pour le premier, est-ce qu'il est possible de faire une bidouille
de ce genre :
<BOUCLE_xx(...){ critère pour isoler des cas où on veut du "direct" }> #HTTP{1}
</BOUCLE_xx> #HTTP{3600}
<//B_xx>
Non, parce que les inclusions ont lieu après la première passe de php sur la page a envoyée.
Pour ce genre de bidouilles, il faut revenir à la technique du script séparé ou de l'interpolation de PHP dans le squelette.
Il faut bien voir que le but est de simplifier le cas général, en l'occurrence ne plus avoir besoin d'écrire 2 fichiers (articles.html+article.php3 etc) mais un seul, dans lequel le langage d'implémentation (php) n'apparait pas. Pour les cas particuliers, il faut ressortir sa connaissance du dit langage, ca me parait inévitable donc pas contrariant.
Tu ne crois pas si mal dire: delay en anglais veut dire "retard", ce qui ne désigne absolument pas le phénomène dont il s'agit.
Belle démonstration involontaire que les choix syntaxiques prétendument "clairs pour tous" (sic) ne le sont que pour une minorité.
Maintenant, on peut effectivement changer ça, ça m'est complètement indifférent. Pensez seulement que Spip est internationalisé, ce qui veut dire pensez à la signification ou l'absence de signification qu'a un mot dans toutes les langues du monde.
>Donc, on ne peut pas adapter le délai à certains éléments de l'url (j'ai
>pas d'exemple concret en tête, mais il me semble que j'ai déjà été
>confronté à ce problème),
Sur sedna, le $delais est réglé en php en fonction de l'âge du fichier
ecrire/data/syndic.lock ; mais bon, tant que $delais continue à fonctionner,
ça roule.
En revanche je suis d'accord sur l'idée qu'il faudrait renommer cette balise
autrement, et permettre une expression numérique complète, par exemple
sous la forme #DELAI[S]{3600*4} (pour conserver l'historique) ; ça évitera
aussi le cas particulier sur #HTTP{numeric}, qui induit de la confusion.
#DELAIS serait plus historique que #DELAI, mais ça pourrait aussi être
l'occasion de corriger la fôte
Maintenant, on peut effectivement changer ça, ça m'est complètement indifférent. Pensez seulement que Spip est internationalisé, ce qui veut dire pensez à la signification ou l'absence de signification qu'a un mot dans toutes les langues du monde.
Et un balise #TEMPS_CACHE ou #CACHE_TIME serait peut être plus parlant et moins confusionnant qqsoit la langue...
À mon avis, il faut garder le français partout, ou nulle part, mais si
on commence à mettre du franglais dans tous les coins, ça sera vite
incompréhensible.
Maintenant (pour faire plaisir à Klaus on peut faire un
inc-english-squel.php qui mouline des squelettes en anglais, ou passer
par un dictionnaire ...
J'avoue que j'ai du mal comprendre pourquoi le nom des choses defrayent autant la chronique de cette liste: dans le contexte international où nous travaillons, tout choix syntaxique sera "ésotérique" pour une partie de la communauté. Partant, je trouve que la seule attitude non linguistiquement impérialiste est de piocher dans le vocabulaire technique standardisé internationalement. #HTTP{3600} a le meme degré d'ésotérisme pour tout le monde. Je n'y tiens pas plus que ça, mais qu'on reconnaisse que tout autre choix relève du favoristime d'une communauté linguistique, ce qui personnellement me déplait beaucoup plus que cet ésotérisme qui m'indiffère complètement.
J'avoue que j'ai du mal comprendre pourquoi le nom des choses
defrayent autant la chronique de cette liste
Hi hi
je crois que c'est une des choses qui a fait le succès de SPIP : les noms
donnés aux objets ont été (pour la plupart) soigneusement choisis pour être
"intuitifs" (avec parfois des bourdes).
Certains fonctionnent avec une mémoire intuitive, on "sent" ce que veut dire
un truc, parfois en se gourant de façon magistrale d'ailleurs ; d'autres
avec une mémoire plus "langage de programmation", où chaque mot n'a de sens
qu'à partir de sa définition technique, au risque de faire des balises
nommées #XTZ (un nom comme un autre, quoi).
Il me semble que tu fais partie du second groupe, tendance hard-core
mais il faut essayer d'accommoder les deux.
J'avoue que j'ai du mal comprendre pourquoi le nom des choses defrayent autant la chronique de cette liste
Hi hi
je crois que c'est une des choses qui a fait le succès de SPIP : les noms
donnés aux objets ont été (pour la plupart) soigneusement choisis pour être
"intuitifs" (avec parfois des bourdes).
tout à fait
je t'avoue que simple (très simple) spipien de base, je préfère #DELAI avec ou sans le S que #HTTP-xxx pour lequel j'aurai besoin d'un lexique
peut-être #HTTP-DELAI ou HTTP-CACHE ou HTTP_s (avec le S de seconde, grandeur internationale)
Partant, je trouve que la seule attitude non linguistiquement
> impérialiste est de piocher dans le vocabulaire technique standardisé
> internationalement. #HTTP {3600} a le meme degré d'ésotérisme
> pour tout le monde.
Le langage machine est international, c'est vrai,
il t'est très familier et pour filer la métaphore, tu en es un grand prêtre...
mais c'est un langage et une tournure d'esprit à part entière,
tu dois le reconnaître,
et assez peu répandu somme toute, quelque soit la contrée.
Je n'y tiens pas plus que ça, mais qu'on reconnaisse que tout autre choix relève du favoristime d'une communauté linguistique, ce qui personnellement me déplait beaucoup plus que cet ésotérisme qui m'indiffère complètement.
L'indifférenciation des squelettes vis a vis de la langue de programmation
c'est un autre éventuel chantier ... (avec pcode et tokenisation ?)
J'ai vu un film de SF marrant hier : evolution.
Les héros se demandent
- "pourquoi favoriser les humains par rapport aux extra terrestres ?"
- "Parceque les humains étaient les premiers"
- "Oui mais et les dinosores ?"
- "Eh ben alors : parcequ'on est humain."
- "Ah oui. C'est bien les humains..."
J'avoue que j'ai du mal comprendre pourquoi le nom des choses defrayent autant la chronique de cette liste: dans le contexte international où nous travaillons, tout choix syntaxique sera "ésotérique" pour une partie de la communauté. Partant, je trouve que la seule attitude non linguistiquement impérialiste est de piocher dans le vocabulaire technique standardisé internationalement. #HTTP {3600} a le meme degré d'ésotérisme pour tout le monde. Je n'y tiens pas plus que ça, mais qu'on reconnaisse que tout autre choix relève du favoristime d'une communauté linguistique, ce qui personnellement me déplait beaucoup plus que cet ésotérisme qui m'indiffère complètement.
Et si on arrétait de couper les cheveux en 4 ? #DELAI, au moins ça ressemble à l'existant $delais, point.
Ensuite, la version i18n, méga normalisée et tout, les puristes
la feront dans un inc-xml-squel plus tard.
Non, #TTL est très parlant pour les spécialistes des packets IP.
Et il y en a quelle proportion parmi les utilisateurs de SPIP ???
C'est une super idée qui dit bien ce que cela veut dire.
Bof, je ne trouve pas, non.
Si on lit TTL et qu'on connaît un peu, on comprend.
Mais si on cherche quel est le nom de cette %#£$ de balise qu'on sait pouvoir mettre pour définir le délai de raffraichissement du cache, c'est pas gagné.
on peut faire un