La nouvelle barre typo est super-chouettos, et la fonction de prévisulation super-élégante. Mais il y a un détail qui me chagrine:
=> quand on a un lien hypertexte dans l'article, si on clique sur ce lien (pour le vérifier), hé ben illico on quitte l'édition et on a perdu les modifications.
Comme en plus le fait d'avoir une prévisualisation donne un aspect rassurant au truc (on voit le texte avec son véritable rendu, on a l'impression qu'il est déjà plus ou moins sauvegardé), on est bien parti pour se faire avoir régulièrement.
Plusieurs possibilités:
- forcer les liens à ouvrir une fenêtre dans la prévisulation;
- introduire un mécanisme de protection des pages édition, qui intercepte le fait de quitter la page une fois qu'on a fait des modifs, et demande confirmation.
Je préfère proposer un message de confirmation avant de changer d'URL oui. Je me demande si le plugin de Realet sur les barres typo faisaient pas déjà ça. Il suffirait de reprendre le code.
Plusieurs possibilités:
- forcer les liens à ouvrir une fenêtre dans la prévisulation;
- introduire un mécanisme de protection des pages édition, qui intercepte le fait de quitter la page une fois qu'on a fait des modifs, et demande confirmation.
On peut aussi enregistrer automatiquement le texte (mode brouillon) en permanance, comme Gmail.
J'avais travaillé sur un prototype de ce genre pour la 192.
Plusieurs possibilités:
- forcer les liens à ouvrir une fenêtre dans la prévisulation;
- introduire un mécanisme de protection des pages édition, qui
intercepte le fait de quitter la page une fois qu'on a fait des modifs,
et demande confirmation.
Je préfère proposer un message de confirmation avant de changer d'URL oui. Je me demande si le plugin de Realet sur les barres typo faisaient pas déjà ça.
Le principe: quand on modifie un input, textarea ou select, les liens hypertexte de la page se voient ajouter une fonction onclick qui bloque le changement de page et demande de confirmer. Ca ne s'applique qu'aux liens hypertexte pointant vers une adresse, et pas à ceux qui ont déjà un onclick. D'après mes quelques tests, ça ne bloque donc pas les boutons de la barre typo, et ça ne bloque pas non plus les boutons d'aide. Le script récupère le label du dernier champ modifié, et le nom de ce label est balancé lors de la demande de confirmation.
Le truc s'applique aussi lorsqu'on a chargé un formulaire en Ajax et qu'on y a fait une modif. Et, toujours côté Ajax, le blocage est levé une fois qu'on a validé un formulaire (exemple: je modifie le titre d'une image, je valide en Ajax, je n'ai plus besoin de bloquer la page).
Vous pouvez tester sous SPIP 2.0. Si le pipeline header_prive était déjà actif dans la 1.9, alors il fonctionnerait également dans cette version.
Le but était au début de corriger le problème d'ergonomie apparu avec la fonction de prévisualisation de la nouvelle barre typo de la spip-dev, mais j'en ai élargit le champ pour protéger tous les formulaires.
