[spip-dev] Appel de modéle via #TEXTE et sensibilité à la case

S'lt tous le monde

Je constate un pb de sensibilité de la case avec un SPIP 2.1 tout frais.

Soit un article dont le texte
<CommencezDemarche|1>
Soit un modèle
CommencezDemarche.html

=> Le modèle n'est pas pris en compte sur un système Debian/Alternc
=> Le modèle est pris en compte sur un système Mac

Soit un article dont le texte
<CommencezDemarche|1>
Soit un modèle
commencezdemarche.html

=> Le modèle est pris en compte sur un système Debian/Alternc
=> Le modèle est pris en compte sur un système Mac

Si je ne m'abuse SPIP cherche du coup à charger commencezdemarche.html
indifféremment de l'écriture. Ne devrait il pas tester d'abord
l'écriture exacte avant de se rabattre à un écriture non sensible à la
case ?

Km

S'lt

J'ai trouvé un "vieux" spip SPIP 2.0.3 SVN [13632]

Le bogue/La particularité est présente

<TesT|1> appelle bien test.html et non TesT.html

Toujours pas glop

Km

oui.
ecrire/public/assembler.php ligne 502 :
   $type = strtolower($type);

pourquoi de qu'est-ce que ?
miss gomme et boule de terre...

ecrire/public/assembler.php ligne 502 :
$type = strtolower($type);

pourquoi de qu'est-ce que ?

Il n'est pas raisonnable de faire des modèles qui dépendraient de la
casse, d'où l'unification vers le bas de casse ; avec le problème
constaté quand on exprime son modèle en haut de casse et qu'on cherche
un fichier de modèle en haut de casse sur un filesystem qui respecte
la casse. Solution : donner le nom du fichier de modèle toujours en
bas de casse.

-- Fil

Personnellement moi-même, ça ne me viendrait pas à l'idée de nommer mes fichiers de code informatique "COmmE_cECi.hTmL".

Bon là j'exagère, mais même en CamelCase, je vois pas l'intérêt. À l'intérieur du code, pourquoi pas (c'est l'habitude en Java, quoique je trouve ça moche et illisible en ce qui me concerne), mais pour les noms de fichier on sait tous pertinemment qu'il y a des différences entre les systèmes unix, mac, win, DONC on met toujours les fichiers en minuscule.

Azertty tu es donc entièrement fautif et tu devras créer 200 fichiers *à la main* nommés "j_ecrirais_toujours_mes_fichiers_en_minuscule".

S'lt

Bien joué denis, j'ai raté le coche dans ma relecture rapide.

Vincent bah écrire COmmE_cECi.hTmL est deconnant mais CommeCeci.html
beaucoup moins. C'est un réflexe qui se chope assez facilement. On
peut rétorquer qu'on peut écrire comme_ceci.html

Le cas se présente lors d'un transfert entre un système non sensible à
la case à un système sensible. (mpn cas en l'occurence)

Sur un système non sensible à la case il est tres facile de mettre une
majuscule sans s'en rendre compte ou se dire bah ça change rien donc
pas de pb ou pour l'esthétique.
Au début on ne voit pas de problème tout va bien, puis on transfert et
là patatrata

Suffit juste de le savoir et d'y penser.

Km

modifs apportées sur http://www.spip.net/fr_article3454.html :

   " On prendra soin de nommer son fichier en lettres minuscules (« bas
     de casse »). Pour éviter les différenciations sur certains systèmes
     serveur entre le_fichier01.html et Le_Fichier01.html, SPIP ne
     recherchera que des fichiers nommés en minuscules. "

denisb a écrit :

Suffit juste de le savoir et d'y penser.

modifs apportées sur Utiliser les modèles - SPIP :

  " On prendra soin de nommer son fichier en lettres minuscules (« bas
    de casse »). Pour éviter les différenciations sur certains systèmes
    serveur entre le_fichier01.html et Le_Fichier01.html, SPIP ne
    recherchera que des fichiers nommés en minuscules. "

Bonjour,

c'est quand même dommage de devoir s'abaisser aux lacunes des
systèmes de fichiers DOS. un peu comme IE 5.

Après tout, puisque c'est maintenant documenté, pourquoi pas...

Je râle, mais j'apprécie l'évolution de Spip chaque jours.

A bientôt
Grégoire

*mercredi* 24/03/10 15:02 ...
un peu tôt pour le troll du week-end (non ?)

Wed, 24 Mar 2010 11:55:35 +0100, cam.lafit@azerttyu.net:

Le cas se présente lors d'un transfert entre un système non
sensible à la case à un système sensible. (mpn cas en l'occurence)

Les problèmes éventuels lors d'un *transfert* sont une chose, mais
c'est le problème de la personne qui fait le transfert, pas de SPIP.
Si je transfère de mon Linux à un autre Linux (par exemple), je sais
ce que je fais, et je veux pas que SPIP me dise "oui mais non,
imagine ça marche pas, alors c'est minuscules picétou".

Comme suggéré par azerttyu, le comportement premier devrait être de
chercher le fichier tel que mentionné. Ensuite seulement, par
"compatibilité" (pour être poli), si on le trouve pas, rechercher la
version tout en minuscules.

Les gens qui développent le noyau, les modules de systèmes de
fichiers, les divers programmes etc. se font tous ch*** pour qu'on
puisse utiliser des majuscules, des espaces, des accents, etc., alors
si juste à la fin de la chaîne y'a un SPIP qui pose des limitations
arbitraires à base de "nan mais arrêtez, c'est trop compliqué, hop,
minuscules pour tout le monde", c'est un peu ridicule [1].
<troll>À ce compte-là, on limite en format 8.3 et on exige du
"monmod~1.htm" au cas où quelqu'un utilise MS-DOS, et on demande aux
gens de pas mettre d'accents dans leurs mails sur la liste, comme au
bon vieux temps.</troll>

Je rappelle quand même que le sujet de la discussion c'est si SPIP
doit convertir en minuscules le nom appelé avec #MODELE dans les
squelettes. Ceux qui utilisent des systèmes de fichiers qui imposent
des minuscules feront de toute façon leur appel à #MODELE{truc} en
minuscules, et s'ils le font pas, c'est facile à corriger.

[1] Notez, je critique les limitations *arbitraires*. Si certaines
limitations (espaces ou autres) sont inhérentes à SPIP, c'est autre
chose. Mais là c'est pas le cas.

* Fil tapuscrivait, le 24/03/2010 08:09:

ecrire/public/assembler.php ligne 502 :
  $type = strtolower($type);

pourquoi de qu'est-ce que ?

Il n'est pas raisonnable de faire des modèles qui dépendraient de la
casse, d'où l'unification vers le bas de casse ; avec le problème
constaté quand on exprime son modèle en haut de casse et qu'on cherche
un fichier de modèle en haut de casse sur un filesystem qui respecte
la casse. Solution : donner le nom du fichier de modèle toujours en
bas de casse.

D'autant plus que si sous linux, on peut avoir :
monfichier.html
MonFichier.html
côte à côte.
En les transférant sous Windows, le 2e transféré écrasera le premier pour ne donner au final qu'un fichier.

Le genre de SAD qu'on cherchera donc à éviter...

-- RealET

Wed, 24 Mar 2010 18:46:00 +0100, RealET:

En les transférant sous Windows, le 2e transféré écrasera le
premier pour ne donner au final qu'un fichier.

Le genre de SAD qu'on cherchera donc à éviter...

... si on utilise Windows.

Qu'on passe en tout-minuscules ou pas est un choix à part,
effectivement censé si on utilise Windows, mais ça reste un choix (et
même dans ce cas, on fera évidemment aussi l'appel à #MODELE{truc} en
minuscules dans les squelettes, donc le strtolower est inutile).

Mais c'est pas un choix à part : le développeur n'utilise pas tel ou tel système, il produit des fichiers qui EUX seront utilisés potentiellement par des milliers de personnes, dont on ne sait absolument pas quel système ils utiliseront.

DONC on code de tel façon à ce qu'on soit sûr que ça marche à peu près partout.

Mais c'est pas un choix à part : le développeur n'utilise pas tel ou tel
système, il produit des fichiers qui EUX seront utilisés potentiellement par
des milliers de personnes, dont on ne sait absolument pas quel système ils
utiliseront.

Tout à fait, et cet argument suffit à emporter la décision.

Mais surtout : l'utilisateur du modèle, celui qui saisit un texte.
L'idée qu'on pourrait lui fournir deux raccourcis différents,
<monmodele> et <MonModele>, lesquels aboutiraient à des résultats
différents, serait comment dire…… saugrenue.

-- Fil

Wed, 24 Mar 2010 22:02:38 +0100, RastaPopoulos:

Mais c'est pas un choix à part : le développeur n'utilise pas tel
ou tel système, il produit des fichiers qui EUX seront utilisés
potentiellement par des milliers de personnes, dont on ne sait
absolument pas quel système ils utiliseront.

C'est peut-être moi, mais je n'arrive pas à voir en quoi ça justifie
l'utilisation de strtolower() sur l'argument passé à #MODELE.
J'aimerais bien qu'on simule un scénario pas à pas où chercher le
nom de fichier tel quel serait problématique, parce que là je vois
pas.

Pour moi, le compilo pourrait râler normalement si on appelle
#MODELE{tRuC}, tout comme il râle si on appelle #MODELE{truc.html}.
Le webmaster corrige son appel et voilà. À trop vouloir deviner
l'intention réelle de l'utilisateur, on adopte un comportement
inattendu qui cause des surprises (légitimes) comme celle de azerttyu.

DONC on code de tel façon à ce qu'on soit sûr que ça marche à peu
près partout.

Ton argument est pertinent, mais c'est la conclusion que je ne
comprends pas. Pour moi la conclusion serait: on conseille dans la
doc de nommer les fichiers de modèles en minuscules s'ils sont voués
à être distribués sur des systèmes divers.

Cordialement,

Teddy Payet

Wed, 24 Mar 2010 22:02:38 +0100, RastaPopoulos:

Mais c'est pas un choix à part : le développeur n'utilise pas tel
ou tel système, il produit des fichiers qui EUX seront utilisés
potentiellement par des milliers de personnes, dont on ne sait
absolument pas quel système ils utiliseront.

C'est peut-être moi, mais je n'arrive pas à voir en quoi ça justifie
l'utilisation de strtolower() sur l'argument passé à #MODELE.
J'aimerais bien qu'on simule un scénario pas à pas où chercher le
nom de fichier tel quel serait problématique, parce que là je vois
pas.

Ben si on veut distribuer un code, un plugin, des modèles etc sur la zone pour qu'il soit utilisé par le plus grand nombre, alors il faut faire en sorte que ton code SOIT utilisable sur le plus grand nombre de plateforme...

Pour moi, le compilo pourrait râler normalement si on appelle
#MODELE{tRuC}, tout comme il râle si on appelle #MODELE{truc.html}.
Le webmaster corrige son appel et voilà. À trop vouloir deviner
l'intention réelle de l'utilisateur, on adopte un comportement
inattendu qui cause des surprises (légitimes) comme celle de azerttyu.

DONC on code de tel façon à ce qu'on soit sûr que ça marche à peu
près partout.

Ton argument est pertinent, mais c'est la conclusion que je ne
comprends pas. Pour moi la conclusion serait: on conseille dans la
doc de nommer les fichiers de modèles en minuscules s'ils sont voués
à être distribués sur des systèmes divers.

Une doc, c'est bien, mais il faut aussi l'appliquer et c'est ce que ce fil est en train de dire... Appliquer la norme "toutenminuscule.html"...

* davux tapuscrivait, le 24/03/2010 23:16:
Ton argument est pertinent, mais c'est la conclusion que je ne

comprends pas. Pour moi la conclusion serait: on conseille dans la
doc de nommer les fichiers de modèles en minuscules s'ils sont voués
à être distribués sur des systèmes divers.

Je vais te donner un scénario vécu qui n'était pas prévu.
Un ami à moi développe sous Linux.
À la racine de son SPIP, il a le dossier IMG/ (normal !)
et un dossier img/ (pourquoi pas, ça marche sous Linux).
Il développait sur un serveur et avait besoin de copier le site sur un autre serveur.
Et Paf, panne d'Internet.
Du coup, il me demande de l'aide.
1er essai sous Windows : échec à cause du img/ écrasé par IMG/ sous Windows.

Donc, ne JAMAIS penser que ça ne se produira jamais....

(PS : épilogue : je suis passé par une machine Linux pour faire la manipulation).

-- RealET

Thu, 25 Mar 2010 01:13:29 +0100, RealET:

Je vais te donner un scénario vécu qui n'était pas prévu.
Un ami à moi développe sous Linux.
À la racine de son SPIP, il a le dossier IMG/ (normal !)
et un dossier img/ (pourquoi pas, ça marche sous Linux).
Il développait sur un serveur et avait besoin de copier le site sur
un autre serveur.
Et Paf, panne d'Internet.
Du coup, il me demande de l'aide.
1er essai sous Windows : échec à cause du img/ écrasé par IMG/ sous
Windows.

Ok. Comment SPIP pourrait corriger le problème ? Bien que tu parles
de casse, ton cas ne répond pas à la question: un scénario où
l'absence de strtolower() dans la recherche de modèles poserait
problème.

Là tu parles d'autres contextes, autres enjeux. Mais effectivement,
s'il ressort que le strtolower() doit rester dans assembler.php, il
faudrait appliquer la même logique partout où le code de SPIP
manipule des chemins, par exemple pour IMG.

davux a écrit :

Ok. Comment SPIP pourrait corriger le problème ? Bien que tu parles
de casse, ton cas ne répond pas à la question: un scénario où
l'absence de strtolower() dans la recherche de modèles poserait
problème.

Là tu parles d'autres contextes, autres enjeux. Mais effectivement,
s'il ressort que le strtolower() doit rester dans assembler.php, il
faudrait appliquer la même logique partout où le code de SPIP
manipule des chemins, par exemple pour IMG.

Et en inversant ?

On cherche le fichier modèle d'abord en bas de casse (la norme conseillée par la doc), et, dans le cas où on ne le trouve pas, on relance une recherche avec la casse respectée ?

Ca aurait pour avantage (théorique) de ne pas pénaliser au niveau perfs les développeurs qui suivent la norme de nommage conseillée (tout en minuscules), tout en permettant à ceux qui souhaitent voir des <MoDeLeS_d3_w4Rl0rdZ> sur leurs systèmes qui le gèrent de le faire.

Mes deux kopeks

    Simon

Salut,

2010/3/25 Simon Camerlo <scamerlo.work@gmail.com>

davux a écrit :

Ok. Comment SPIP pourrait corriger le problème ? Bien que tu parles
de casse, ton cas ne répond pas à la question: un scénario où
l’absence de strtolower() dans la recherche de modèles poserait
problème.

Là tu parles d’autres contextes, autres enjeux. Mais effectivement,
s’il ressort que le strtolower() doit rester dans assembler.php, il
faudrait appliquer la même logique partout où le code de SPIP
manipule des chemins, par exemple pour IMG.

Et en inversant ?

On cherche le fichier modèle d’abord en bas de casse (la norme conseillée par la doc), et, dans le cas où on ne le trouve pas, on relance une recherche avec la casse respectée ?

Ca aurait pour avantage (théorique) de ne pas pénaliser au niveau perfs les développeurs qui suivent la norme de nommage conseillée (tout en minuscules), tout en permettant à ceux qui souhaitent voir des <MoDeLeS_d3_w4Rl0rdZ> sur leurs systèmes qui le gèrent de le faire.

Non non non !

on ne peut pas se permettre d’inciter les développeurs à écrire leurs fichiers en minuscule, et laisser une liberté à d’autres.
Ça rajoute des tests, des situations ambigües, etc…

Pourquoi pas ensuite des accents dans les noms de fichiers ? On se trouverait alors face au problème du Mac qui encode en MacRoman, du Windows qui utilise l’iso8859-15, etc…

Il faut fixer une règle et demander à chacun de s’y tenir.

Il me semble stupide de polémiquer sur l’aspect mineur de la casse des modèles, sinon on est mal parti pour normaliser a minima l’écriture des plugins et thèmes.

.Gilles