Editer un post sur place - Page 1

Voilà, un truc que j'ai vu sur un autre forum et qui m'a bien plu, c'est que quand on édite un post, ce n'est pas un popup qui apparaît, mais le post lui-même est remplacé par le formulaire et je me suis dit que ça serait cool de voir la même chose sur yN

EDIT : Ca marche ?

C'est en cours de test chez bob&moi ^^

merci !!!

Titane (./3) :
EDIT : Ca marche ?

CA MARCHE

il y a un petit bug avec l'edit en place, ça ne prend pas en compte les caractères unicodes

Euh bah ca marche en passant par &#xxx ...

ouais mais dans un formulaire normal ça marche en passant par le caractère lui même (ce qui est quand même plus pratique pour rajouter un caractère unicode )

Juste pour chipoter ... pourquoi faire une icône pour le "éditer sur place" et la popup avec "editer", au lieu du système utilisé dans les blogs, à savoir le contraire ? ce serait pas plus jouli ?

je pense que c'est temporaire (comprendre qu'à mon sens, l'édit in place remplacera sans doute définitivement l'édit popup à terme)

./7 > en fait c'est même pire que ça, non seulement si on ajoute des caractères spéciaux ils ne passent pas, mais ceux qui étaient déjà là avant l'édit sont détruits également (du moins avec firefox 1.5.0.5 linux). Ça n'est pas le cas avec le formulaire en popup.
Par exemple, si j'édite inline ce post et que je valide sans rien avoir modifié, les caractères suivants seront remplacés par des points d'interrogation : – — œ

(mais pas celui-ci : æ. La seule différence que je vois entre ce caractère et les précédents est qu'il appartient au jeu de caractères latin-1 et pas les autres, mais je ne sais pas si c'est la raison parce que si je vais voir dans le menu affichage/encodage des caractères de firefox, c'est mis sur « Occidental (Windows-1252) » et non sur « Occidental (ISO-8859-1) », or il me semble que les 4 caractères sont dans le windows-1252, donc pourquoi le quatrième passe )

N.B. : ce ne sont pourtant pas des caractères unicode (cf. code source de la page)
en fait un vrai caractère unicode est remplacé par un &#numéro; à l'édition, exemple : ộ

edit : ça se comporte exactement de la même façon sous windows (firefox 0.8)

chez moi (ff 2.0 windows) les caractères unicodes déjà présents ne sont pas détruits avec l'édit en ligne et si j'édite ton post en ligne, les caractères – — œ apparaissent bien dans le champ de texte

Ouais ils apparaissent dans le champ de texte, mais si je fais valider ils se retrouvent remplacés par des ?, à ce moment-là seulement...
alors par contre les caractères *unicode* déjà présents ne sont, eux, pas détruits parce que si j'édite en ligne ça les remplace par un code ? , du coup si après je valide le caractère revient. C'est seulement les caractères spéciaux non unicode qui sont détruits

ça peut se comprendre, vu que les requêtes vers le serveur sont forcément codées en unicode (unicode == UTF-8, non ?)
par contre, les caractères spéciaux non unicodes devraient ptêt être réencodés en javascript pour être envoyés au serveur

Satine (./10) :
Juste pour chipoter ... pourquoi faire une icône pour le "éditer sur place" et la popup avec "editer", au lieu du système utilisé dans les blogs, à savoir le contraire ? ce serait pas plus jouli ?

vince (./11) :
je pense que c'est temporaire (comprendre qu'à mon sens, l'édit in place remplacera sans doute définitivement l'édit popup à terme)

en fait c'était comme dans les blogs au début, mais sachant que j'étais pas sûr du systeme (on voit bien qu'il y a des pb ac l'unicode ... cas extrême on va dire), j'ai préféré inverser et laisser l'editer "par défaut" (ie celui sur lequel on appuie + facilement) en popup

---

sinon pour l'unicode, le texte est envoyé en UTF-8 à mon script php et je suis obligé de le decoder pour le traiter, sinon les accents ne passent pas pour le français, donc je sais pas trop cmt je vais regler votre pb ^^

Tu ne peux pas modifier le script JS qui envoie les données pour qu'il encode correctement les infos ?

Flanker (./17) :
Tu ne peux pas modifier le script JS qui envoie les données pour qu'il encode correctement les infos ?

xmlhttp fonctionne en utf8, et autrement JS fonctionne avec le charset de la page je crois

Ah, en fait le lien « valider » ne fait pas la même chose que le bouton « envoyer » du formulaire en popup normal, c'est ça ? c'est pas un POST ?

Sally (./19) :
Ah, en fait le lien « valider » ne fait pas la même chose que le bouton « envoyer » du formulaire en popup normal, c'est ça ? c'est pas un POST ?

si mais tu dois reconstruire les données le champ POST à la main avant de l'envoyer et c'est javascript qui s'en charge et qui fait la requête POST

Oui, sinon la page sera automatiquement rechargée

yAro (./18) :

Flanker (./17) :
Tu ne peux pas modifier le script JS qui envoie les données pour qu'il encode correctement les infos ?

xmlhttp fonctionne en utf8, et autrement JS fonctionne avec le charset de la page je crois

Oui, mais tu ne peux pas parcourir le texte que tu envoies et détecter les caractères qui déconnent pour les changer par une autre forme ?

sur mon propre site, j'utilise un script js qui parcourt les données que je vais envoyer et qui remplace les & par % 26, les = par % 3D et les + par % 2B avant de reconstruire le champ data qu'envoie xmlhttprequest

la fonction escape fait ca en JS, a voir avec un urldecode en php en traitement, jteste ca lundi

Bon là ca a l'air de mieux marcher, mais du coup je suis obligé de tout encoder et transformer en &# ... :/

mmh nan ça n'a pas l'air de marcher. les caractères spéciaux sont transformés en d'autres caractères (problème de charset)
et même avec l'édit normal ça ne conserve plus ces caractères