[spip-dev] Re: [spip-commit] CVS: spip/ecrire inc.php3,1.24,1.25 inc_auth.php3,1.17,1.18 inc_base.php3,1.27,1.28 inc_version.php3,1.56,1.57

Restriction : serialize() dans un tinytext, on risque de remplir les
255 caractères assez vite si on ajoute d'uatres types de préfs...

Quel est l'avantage d'un TINYTEXT par rapport à un VARCHAR(255) ?

Pour éviter de déborder, mais rester libre d'ajouter des paramètres,
pourquoi ne pas utiliser le principe de la table meta ?

-Nicolas

Quel est l'avantage d'un TINYTEXT par rapport à un VARCHAR(255) ?

J'en sais rien ! Y fallait bien mettre quekchose...

Pour éviter de déborder, mais rester libre d'ajouter des paramètres,
pourquoi ne pas utiliser le principe de la table meta ?

La table meta est pour tout le spip, là on parle préférences par auteur.
M'enfin, pour ne pas déborder le mieux est de ne pas trop en rajouter, et de
donner des noms relativemnet courts aux variables. Si on déborde on changera
le type de la colonne et basta. (A mon avis il y a des choses plus
importantes sur lesquelles griller quelques neurones.)

-- Fil

Quel est l'avantage d'un TINYTEXT par rapport à un VARCHAR(255) ?

J'en sais rien ! Y fallait bien mettre quekchose...

OK, alors il me semble que le VARCHAR est mieux niveau perfs et place
occupée, mais ça demande vérification ...

pourquoi ne pas utiliser le principe de la table meta ?

La table meta est pour tout le spip, là on parle préférences par
auteur.

Oui, oui, je parlais du principe uniquement.

M'enfin, pour ne pas déborder le mieux est de ne pas trop en
rajouter, et de donner des noms relativemnet courts aux variables.
Si on déborde on changera le type de la colonne et basta. (A mon
avis il y a des choses plus importantes sur lesquelles griller
quelques neurones.)

C'est pas deux ou trois neurones de plus qui changeront la donne, donc
autant prévoir flexible tout de suite, non ? :wink:

-Nicolas

OK, alors il me semble que le VARCHAR est mieux niveau perfs et place
occupée, mais ça demande vérification ...

Tu nous diras

C'est pas deux ou trois neurones de plus qui changeront la donne, donc
autant prévoir flexible tout de suite, non ? :wink:

Autant mettre un gros BLOB, ça ira, de toutes façons il n'y a pas de
question de performances sur ce champ (jamais de WHERE).

Quand je parlais de neurones, c'est par exemple pour savoir ce qu'on fait du
meta[email_webmaster], qui pour l'instant ne sert à rien :wink: -- ou de 50
autres trucs en attente (dont l'authentification pour forums sur
abonnements, qui implique de savoir à quoi va ressembler l'auth publique).

-- Fil

OK, alors il me semble que le VARCHAR est mieux niveau perfs et place
occupée, mais ça demande vérification ...

Tu nous diras

c'est pareil, par contre VARCHAR est plus standard que TINYTEXT
qui est une spécificité MySQL.

Au fait, s'il n'y a pas de problème particulier, ce serait mieux
(plus lisible dans la base) d'utiliser un join qu'un serialize.
Exemple : options=basiques;couleur=6

Quand je parlais de neurones, c'est par exemple pour savoir ce qu'on
fait du meta[email_webmaster], qui pour l'instant ne sert à rien :wink:

Comment ça ? Il ne sert pas au "from" dans l'envoi d'e-mails ?

(dont l'authentification pour forums
sur
abonnements, qui implique de savoir à quoi va ressembler l'auth
publique).

Pour moi, la même chose que l'auth privée. Par contre, c'est vrai
que le pop-up est un peu superflu pour une telle chose.

a+

c'est pareil, par contre VARCHAR est plus standard que TINYTEXT qui
est une spécificité MySQL.

Yep.

Au fait, s'il n'y a pas de problème particulier, ce serait mieux
(plus lisible dans la base) d'utiliser un join qu'un serialize.
Exemple : options=basiques;couleur=6

Ouais, c'est pareil niveau place, et ça permet de "lire" les infos en
base ...

Quand je parlais de neurones, c'est par exemple pour savoir ce
qu'on fait du meta[email_webmaster], qui pour l'instant ne sert à
rien :wink:

Comment ça ? Il ne sert pas au "from" dans l'envoi d'e-mails ?

Oui, je pensais aussi. Et puis un lien "contacter" le webmaster
accessible uniquement aux admins pourrais être pas mal.

(dont l'authentification pour forums sur abonnements, qui implique
de savoir à quoi va ressembler l'auth publique).

Pour moi, la même chose que l'auth privée. Par contre, c'est vrai
que le pop-up est un peu superflu pour une telle chose.

L'idéal serait qu'on puisse avoir juste un petit formulaire placé où
on veut dans la page. Il me semble que les modifs de ces derniers
jours étaient faites pour ça, non ?

-Nicolas

Autant mettre un gros BLOB, ça ira, de toutes façons il n'y a pas de
question de performances sur ce champ (jamais de WHERE).

Les perfs ne sont pas impactées que pour un WHERE, le binaire n'est
que rarement utile dans une BDD ...

-Nicolas

c'est pareil, par contre VARCHAR est plus standard que TINYTEXT
qui est une spécificité MySQL.

Au fait, s'il n'y a pas de problème particulier, ce serait mieux
(plus lisible dans la base) d'utiliser un join qu'un serialize.
Exemple : options=basiques;couleur=6

Non, pas de problèmes dans les deux cas si tu veux changer ; j'avais envie
d'utiliser serialize, pour voir. Avec join il faut décoder.

> Quand je parlais de neurones, c'est par exemple pour savoir ce qu'on
> fait du meta[email_webmaster], qui pour l'instant ne sert à rien :wink:

Comment ça ? Il ne sert pas au "from" dans l'envoi d'e-mails ?

Non, pour l'instant il ne sert à rien. Le but n'est pas qu'il serve de from,
mais qu'il reçoive les mails "panique" de spip (plus d'espace disque, un
pirate nous attaque, vous venez de franchir le cap des 10000 articles
publiés félicitations, etc.)

> (dont l'authentification pour forums sur abonnements, qui implique de
> savoir à quoi va ressembler l'auth publique).

Pour moi, la même chose que l'auth privée. Par contre, c'est vrai
que le pop-up est un peu superflu pour une telle chose.

A mon sens il faut un truc très léger et graphiquement joli, ce que permet
justement le popup : tu cliques sur "authentifier", ça popup en te demandant
ton email ou ton login ET en proposant de t'en envoyer un si besoin (avec
accès ecrire/ ou pas selon les cas) ; tu mets ensuite soit ton cookie de
validation reçu par email soit ton mot de passe, le popup s'efface et la
page en-dessous se recharge en mode "authentifié".

J'ai fait une maquette, l'as-tu essayée ?

Pour la validation des pétitions, c'est pareil : il vaudrait mieux un popup
où se passerait toute la partie interactive, puis recharger la page finale
dans la fenêtre de base.

-- Fil

Avec join il faut décoder.

???

J'ai fait une maquette, l'as-tu essayée ?

Où ça, où ça ??? :wink:

-Nicolas

J'ai fait une maquette, l'as-tu essayée ?

Je ne sais pas, j'avais vu le pop-up d'il y a une semaine ou deux.

Pour la validation des pétitions, c'est pareil : il vaudrait mieux un
popup où se passerait toute la partie interactive, puis recharger la
page finale dans la fenêtre de base.

En fait, pop-up ou pas, il faut surtout que la décision soit globale, et
vale à la fois pour les forums, le login, la pétition....
Si on suit ce qu'on a fait jusque maintenant, les formulaires sont intégrés
à la page, il serait logique qu'on fasse de même pour le formulaire de
login (surtout qu'il fait partie du formulaire de forum).

En fait, pop-up ou pas, il faut surtout que la décision soit globale, et
vale à la fois pour les forums, le login, la pétition....

oui

Si on suit ce qu'on a fait jusque maintenant, les formulaires sont intégrés
à la page, il serait logique qu'on fasse de même pour le formulaire de
login (surtout qu'il fait partie du formulaire de forum).

à mon avis, un truc en popup a pour avantages :

1) de ne pas se trouver n'importe où dans le squelette, ce qui oblige au
   lamentable URL avec un # dedans pour retrouver l'endroit où inch'allah
   s'affichera la réponse

2) d'offrir une interactivité plus fine et plus complète, et plus rapide

3) de proposer un truc visuellement neutre, qui n'a donc pas à s'intégrer
   dans le design d'une page pas forcément prévue pour être très souple
   ou compatible avec les choses nécessitées par l'interactivité.

Il faut avoir en tête que désormais l'auth publique d'un visiteur ou d'un
rédacteur, ou d'un admin, suivront la même procédure. Il faudra donc qu'elle
soit assez souple et intelligente (proactive, comme on dit). Ce qui implique
de ne pas être dans un espace visuel encombré.

-- Fil

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

> Avec join il faut décoder.
???

quand on relit la base, il faut parser le contenu du champ pour créer
l'array prefs[].

> J'ai fait une maquette, l'as-tu essayée ?
Où ça, où ça ??? :wink:

Message du 1er juillet ci-dessous. Seul problème, pour changer de serveur
cvs j'ai vidé mon répertoire de tests, où se trouvaient les fichiers en
question. Gasp ! Et en plus c'est pas dans le cache de google ! Personne
n'avait suivi la discussion à ce moment-là, et pourrait retrouver le fichier
en question ?

Bon, ben je suppose que tu nous feras la doc expliquant à Mari-Jo
comment son site des camps de scout, elle peut en réserver l'accès
aux parents d'élèves sans devenir dingue. Je te fais confiance.

Commençons par fournir un système de login et par l'utiliser sur les forums
sur abo, hein !

tu fais le truc qui fonctionne

Création d'auteur 6forum à la demande, login en session (et md5 jajascript)
pour tout le monde, c'est fait, dans deux fichiers que je ne vais pas
commiter, mais que tu peux trouver là :
    http://rezo.net/~fil/spip/spip-sessions/
et tester ici :
    http://rezo.net/~fil/spip/toto.php

(toto.php ne fait que vérifier la présence ou non d'une session et appelle
si besoin le popup d'identification ; je ne sais pas comment le popup, quand
il se ferme parce qu'il est content de l'identification, peut envoyer un
"reload" à la page qui l'avait appelé).

et je repasserai derrière si nécessaire.

Pour utiliser les sessions à l'intérieur d'inc-forum.php3, c'est sûrement
facile à condition de rentrer dans la logique de ce bout de code, avec ses
hash_action, ses mots-clés etc. Et là, c'est trop bordélique pour moi...
M'enfin, il suffit de regarder si une session existe (si oui, c'est qu'elle
a été vérifiée par inc-public (global $auteur_session est vide sinon).

On peut alors utiliser les contenus de $auteur_session['statut'], ['nom'],
['email'], ['id_auteur'] pour remplir/vérifier les infos nécessaires.

-- Fil

Avec join il faut décoder.

???

quand on relit la base, il faut parser le contenu du champ pour
créer l'array prefs[].

explode() ...

> J'ai fait une maquette, l'as-tu essayée ?
Où ça, où ça ??? :wink:

Message du 1er juillet ci-dessous. Seul problème, pour changer de
serveur cvs j'ai vidé mon répertoire de tests, où se trouvaient les
fichiers en question. Gasp ! Et en plus c'est pas dans le cache de
google ! Personne n'avait suivi la discussion à ce moment-là, et
pourrait retrouver le fichier en question ?

Pas suivi, non, désolé !!! :frowning:

-Nicolas

1) de ne pas se trouver n'importe où dans le squelette, ce qui oblige
au
  lamentable URL avec un # dedans pour retrouver l'endroit où
  inch'allah s'affichera la réponse

Bof, je ne vois pas où l'URL pose problème.

2) d'offrir une interactivité plus fine et plus complète, et plus
rapide

Plus rapide peut-être, mais plus fine et plus complète, je ne comprends pas
... ?

Le problème avec les forums c'est que si l'auth se fait en pop-up mais la
saisie du message à l'intérieur de la page, c'est totalement bordélique...
Il faut donc choisir entre les deux.

Perso, je suis toujours partisan du formulaire quand on peut. Il me semble de toute façon que si on veut un jour exploiter l'identification sur le site public de manière plus générale, les forums seront beaucoup plus naturels à intégrer dans le site qu'un jaillissement de pop-up. Meilleur contrôle graphique (inutile de founir un "ecureil-dist.png", puisqu'alors on intègre ça dans une page dont on a le contrôle total), et plus c'est dans les habitudes (cf. Nuke).

Et comme l'indique Antoine, vu que c'est lié pour l'instant à des forums, l'interface cohérente c'est le formulaire intégré à la page.

Je n'ai aucune idée de la complexité du truc, mais si on pouvait simplement imaginer une fonction
afficher_formulaire_identification
qui pourrait par ailleurs être appelée par un #FORMULAIRE_IDENTIFICATION, ce serait épatant.

ARNO*

Meilleur contrôle graphique (inutile de founir un "ecureil-dist.png",

:))

Perso, je suis toujours partisan du formulaire quand on peut.

En l'occurence, il me semble qu'on ne peut pas.

S'il y a 4 étapes pour se loger (tentative, demande de login, envoi du code,
confirmation que c'est OK) c'est gérable, en termes d'interface et de temps
d'affichage, uniquement dans un popup (ou une fenêtre spécifique, façon
login.php3 actuel).

Trouver le bout de texte pertinent au milieu d'une page pleine de graphiques
etc. est impossible : déjà sur labassijysuis, où la maquette est simple,
l'URL en #machin t'amène à la bonne hauteur, mais le truc étant dans la
marge ton oeil peut très bien être attiré à droite au lieu d'aller à gauche,
et tu ne lis pas le message d'erreur ou de bienvenue ou de demande de
confirmation...

Il me semble de toute façon que si on veut un jour exploiter
l'identification sur le site public de manière plus générale, les forums
seront beaucoup plus naturels à intégrer dans le site qu'un jaillissement
de pop-up. Meilleur contrôle graphique (inutile de founir un
"ecureil-dist.png", puisqu'alors on intègre ça dans une page dont on a le
contrôle total), et plus c'est dans les habitudes (cf. Nuke).

Attends ! Le forum reste dans la page, ça ne change pas : c'est juste la
demande d'authentification qui fait pop !

Et comme l'indique Antoine, vu que c'est lié pour l'instant à des forums,
l'interface cohérente c'est le formulaire intégré à la page.

Je ne suis pas convaincu.

Je n'ai aucune idée de la complexité du truc, mais si on pouvait
simplement imaginer une fonction
afficher_formulaire_identification
qui pourrait par ailleurs être appelée par un
#FORMULAIRE_IDENTIFICATION, ce serait épatant.

A mon avis ça sera boîteux. Mais je ne vais pas me casser le cul à
reprogrammer une maquette juste pour vous le prouver. Si je le fais, c'est
pour que ça soit accepté. Donc si vous êtes vraiment convaincus que c'est un
mauvais design, je ne (re)commence pas :wink:

PS: et ce bug d'accents dans Mailman ! Parfois c'est gonflant, hein,
l'informatique !

-- Fil

Parfois c'est gonflant, hein, l'informatique !

Oui, tous les jours. C'est peut-être pour ça qu'on aime ... :wink:

-Nicolas

Il y a plusieurs problèmes qui s'entrechoquent.

Trouver le bout de texte pertinent au milieu d'une page pleine de
graphiques etc. est impossible : déjà sur labassijysuis, où la maquette
est simple, l'URL en #machin t'amène à la bonne hauteur, mais le truc
étant dans la marge ton oeil peut très bien être attiré à droite au
lieu d'aller à gauche, et tu ne lis pas le message d'erreur ou de
bienvenue ou de demande de confirmation...

Deux choses :
- un formulaire de pétition noyé au milieu d'une page, c'est pas génial
- mais c'est aussi la faute du webmestre s'il a décidé que la page de
signature devait aussi afficher trois pages de texte, et que le formulaire
serait déporté sur la page de gauche ! C'est vrai que les squelettes par
défaut ne donnent pas l'exemple.

Attends ! Le forum reste dans la page, ça ne change pas : c'est juste
la demande d'authentification qui fait pop !

Là le problème c'est que c'est non-bloquant : si l'utilisateur ignore
le pop-up et remplit le forum, qu'est-ce qui se passe ? Ca fait deux
formulaires différents qui s'affichent et qu'on peut tous les deux
remplir, mais en fait il faut remplir l'un avant l'autre sans que
l'interface nous y oblige explicitement.... Pas clair du tout.

Et comme l'indique Antoine, vu que c'est lié pour l'instant à des
forums, l'interface cohérente c'est le formulaire intégré à la page.

Je ne suis pas convaincu.

C'est mi-figue mi-raison. Avec une page séparée (pas forcément un
pop-up, hein !), on a un truc très propre mais pas du tout personnalisé.
Avec un formulaire intégré, ça se fond dans la mise en page mais au
prix d'une légère inélégance et d'une certaine lourdeur.

Mais encore une fois si on a une page séparée pour le login, il devient
illogique d'avoir un formulaire intégré pour le forum. Que devient
alors le #FORMULAIRE_FORUM (renvoi vers la page séparée ?!!).

PS: et ce bug d'accents dans Mailman ! Parfois c'est gonflant, hein,
l'informatique !

Moi c'est l'écureuil qui vide le titre de certains mails.

Heu, au fait, qui les utilise, ces forums sur abonnement ?
C'est peut-être pas la peine de se faire chier.... :wink:

par cette belle journée, Antoine raconte ce que suit :

Heu, au fait, qui les utilise, ces forums sur abonnement ?
C'est peut-être pas la peine de se faire chier.... :wink:

ça c'est une bonne question, à poser sur la liste spip !
moi je savais même pas que ça existait...

Dorian