Un endroit pour reflechir
- à ce que cela pourrait offrir comme fonctionnalités, un editeur WYSIWYG adapté a SPIP.
Avec le souci de différencier des qui est vraiment indispensable aujourd’hui, souhaitable a court terme, et les bonus envisageables a long terme.
ce sujet revient régulièrement sur les listes. Il y a differentes contributions qui permettent d’adapter un editeur comme FCK ou HTMLarea mais elles ne sont pas satifaisantes.
Les développeurs de spip se sont souvent montrés très réservés face à ces développement, avec raison, car ils introduisent du code html directement dans spip, et permettent trop souvent aux rédacteurs de faire n’importe quoi, sans souci des règles typographiques.
pour cela il semble que les réflexions posées par jacques Pyrat sur son site me semblent être une bonne base de départ
http://www.pyrat.net/Un-editeur-WYS....
Il faut comme lui rappeler que la typographie est au service du texte et pas du délire du rédacteur.
Le but est donc de répondre a la demande légitime des rédacteurs de pouvoir voir ce qu’ils écrivent comme ils le font avec un traitement de texte de tous les jours.
En effet, ils ne s’habituent pas a la manipulation des codes qu’il faut effacer pour revenir en arrière.
Ils ne s’habituent surtout pas a la création de tableaux meme avec l’aide d’une barre typographique évoluée comme celle que propose jacques pyrat ou meme spipedit.
J’ai encore eu ce matin un collègue qui a installé un SPIP avec FCK imposé par un directeur, c’est difficile de dire après aux utilisateurs que c’est pas beau. Surtout s’ils jonglent entre divers SPIP avec et sans éditeur.
Donc pour éviter que nos chers rédacteurs contournent spip en bricolant du code html pour faire ce qu’ils veulent faire, offrons leur les moyens de faire ce que spip permet de faire, proprement.
D’autant plus que les propositions de plugins arrivent sur la zone qui permettent d’etendre les codes typograhiques utilisés.
- sur quels outils de base faut-il s’appuyer : par exemple sur quel éditeur baser ce plugin ( je suppose que SIP 1.9 sera la cible)
-
- quel est le meilleur éditeur ?
pas forcement celui qui présente le plus de fonctionnalités mais celui qui sera le plus souple à paramétrer
Voir du côté de Dojo Editor
- la contrib en cours de rédaction de damien est prometteuse elle s’appuie sur JAXE et donc une machine JAVA sur poste client.
xcvv - se limite-t-on aux raccourcis SPIP ou bien prend-t-on en compte (dans un deuxième temps) les raccourcis intégrés par les plugins (BBcode par ex)
- cela peut-il être un outil non intégré au navigateur (SPIPedit en java)
- quel est le meilleur éditeur ?
- part-on du html produit par l’éditeur et à travers une fonction « sale » produisons nous du code SPIP et inversement
- pour aller plus loin on peut assi regarder du coté de Ez-publish qui possède un éditeur intégré mais qui supporte le format OpenDocument
- dans PHPSolution ( n°1/2006) où est décrit comment intégrer ce format à des applis PHP mais surtout le lien en mode WebDAV de OpenOffice
avec EZ-publish c’est a dire la copie directe d’un fichier Odt vers l’arborescence des rubriques de EZ-publish. - Matthieu Lecarme proposait cette approche dans la liste de diffusion spip-lab, il a laissé tomber les spipistes.
- (pif) cette approche semble séduisante à première vue, mais n’est pas immédiate à mettre en place : on peut « facilement » mapper l’arbo de rubriques à une arbo
ldap et y mettre les articles comme des fichiers, mais que faire des documents attachés, des auteurs, mots clé, descriptifs de rubriques ...
- dans PHPSolution ( n°1/2006) où est décrit comment intégrer ce format à des applis PHP mais surtout le lien en mode WebDAV de OpenOffice
Il me semble que l’ensemble des raccourcis proposés actuellement devraient etre pris en charge ainsi que l’intégration des images.Celles-ci pourraient éventuellement etre auparavant intégrées dans l’article.
À noter (edit de Beurt) : Il existe une alternative très interessante à l’éditeur WYSIWYG qui est la prévisualisation dynamique (avec un peu d’AJAX) proposée par dams : Prévisualisation dynamique d’articles (avec Ajax). Cette solution particulièrement interessante permet de concilier l’aspect sémantique des raccourcis typo tout en autorisant un aperçu aux rédacteurs. Hélas, elle fonctionne avec Spip 1.8.x (où x n’est pas 3 !).
(Arnaud) Nous avons développé ce petit composant pour répondre rapidement aux rédacteurs qui avaient l’habitude de travailler leurs article dans Word, le côté prévisu directe a été apprécié, hélas restait le pb de la correction du texte « à la main ». C’est Spip edit qui a été déployé ensuite. Nb : pour la 1.8.3 le portage arrive, on a eu u peu de mal à suivre les versions ces temps ci ;-)...
(philippe) J’ai aussi mis en place cette fonction, mais on se trimballe toujours les codes a modifier, c’est bien pour des choses simples.
correction : Dojo editor, c’est de l’ajax, pas du java.
— Réflexion Clever Age —
Réflexion éditeur WYSIWYG pour SPIP(-Agora)
Nicolas Steinmetz (Clever Age)
Objectif de mon intervention : mutualiser la réflexion et éventuellement une partie des développements (personnalisation de [->[->[->[->TinyMCE]]]] notamment vue qu’Agora reste basé sur SPIP 1.7.x + ses évolutions propres)
Pour reproduire un fonctionnement similaire à partir de [->[->[->[->TinyMCE]]]] :
- Restriction des fonctionnalités aux balises XHTML sémantiques (h1, h2, p, listes, etc),
- (pif) quid des gras et italique ? les puces (hors listes) ?
- (Nicolas Steinmetz) : ils sont dans le etc de mon énumération - l’idée est de reprendre les éléments de mise en forme actuelle, voir d’en enrichir certains le cas échéants (tableaux par ex)
- Utilisation des rulesets pour répondre aux spécificités fonctionnelles actuelles de SPIP(-Agora). (ex :
<docxx|center>
,
<imgxx>
,<sitexx>
, ...)- (pif) c’est quoi les ruleset ?
- (Nicolas Steinmetz) C’est il me semble le nom des plugins sous tinyMCE si je ne me trompe pas
Pour les aspectes techniques :
- Nous envisageons de stocker le XHTML produit directement (pas de conversion en langage spip)
- (pif) quid du rss dans ce cas, ou des éventuels diffusions vers d’autres canaux (wap ...)
- (Nicolas Steinmetz) : il y aura un équivalent de texte_brut ou extension de celui-ci par ex
- Car l’éditeur wysiwyg prend en charge nativement l’affichage du contenu
- Le convertisseur syntaxe SPIP vers XHTML ne se limitant plus qu’aux balises XML spécifiques,
- (pif) pas compris
- (Nicolas Steinmetz) : comme tout est au format xhtml, on a juste les balises spécifiques SPIP (
& co) à convertir.
- Modification du moteur de rendu pour gérer les contenus saisis dans [->[->[->[->TinyMCE]]]].
Avantages :
- On limite la modification de tinyMCE pour suivre les évolutions de l’éditeur à moindre coût
- Interopérabilité de ce contenu avec d’autres éditeurs ou d’autres formats de stockage est amélioré du fait des caractéristiques du XML/XHTML
A creuser si on part sur une cohabitation des 2 solutions :
- Définition d’un mode de saisie de préférence (lors de l’install par ex)
- Définition du mode de saisie préférentiel pour un auteur (SPIP/WYSIWYG)
- Si un auteur rédige en raccourcis SPIP et un autre en WYSIWYG que se passe-t-il quand ils veulent éditer un même article ? Je suis partisant de flager l’article selon le mode de rédaction de l’auteur et c’est le mode du 1er auteur qui reste ensuite dominant. Je n’ai pas envie de me lancer dans du xhtml<->spip à la volée en fonction des cas.
- (pif) ça me parait très restrictif : on impose un mode d’édition à certains auteurs. Ne serait-ce qu’en termes d’accessibilité, je ne pense pas que tinyMCE soit ’braille compliant’
- (Nicolas Steinmetz) : en effet, je n’y avais pas pensé - on voulait éviter les conversions pour s’adapter à chaque mode de saisie... mais cela risque de s’avérer nécessaire en effet...
Maj 05/05/06 : Le marché en question ayant été perdu, ce n’est pas Clever Age qui implémentera cela dans Agora, sauf si le besoin apparaît pour un autre projet.
— Réflexion Clever Age —
Cedric MORIN
J’ai commence a travailler sur la fonction sale() qui doit permettre de ramener du (x)html en syntaxe SPIP, quitte a conserver certaines balises html non convertissables si necessaire.
Les pre-requis sont :
- la transformation d’un texte brut avec raccourcis SPIP par propre() puis sale() doit rester invariante. Sur ce point il est clair que les evolutions de propre() entre une 1.7.x et une 1.9 ne sont pas de nature a favoriser une fonction qui supporte les deux facilement ; a tester. Cette etape est en cours, obtenue pour les objets les plus courants de SPIP, encore a completer pour les moins usites
- un texte brut avec raccourcis SPIP, passe dans propre(), ouvert dans l’editeur (mais aucune modif), sauvegarde, puis passe dans sale() doit aussi rester invariant -> plus vicieux qu’il n’y parait car le simple fait d’ouvrir dans l’editeur engendre des reformatages html
- etape ultime, un texte html produit par l’editeur (from scratch, ou depuis du html venant de propre() ) doit etre converti en raccourcis SPIP avec une efficacité maximale
Si l’étape 1 ne depend pas de l’editeur choisi, rapidement, dans l’etape 2, sont a prendre en compte les reformattages eventuels de l’editeur. Il faudra voir si cela impose le choix ou pas.
Philippe Lara :
en voyant arriver sur la zone des plugins divers de traitement de code (BBcode ; coloration, textism) je me demande s’il ne serait pas intéressant de carrément stocker du xml dans la base de SPIP, en affichant au choix du code SPIP, du wysiwyg, du BBcode etc, suivant les besoins.
avec pourquoi pas un plugin codeSPIP
(pif) effectivement, techniquement parlant, c’est séduisant : si le format est bien foutu, il suffit ensuite de regex <machin> => <truc>
pour convertir, ce qui serait bien plus efficace.par ailleurs, si on fixe un tag englobant imposé (genre <spip:texte>
) on est alors capable de savoir si on a en base du xml ou du spip, ce qui évite de tout transférer lors de l’upgrade. Il suffit d’un avant_propre qui passe la main à la version xml, ou la version originale selon qu’il y a la balise ou pas. Cote édition, il faut transformer en xml lors du « save » pour pouvoir basculer un site petit à petit d’un format à l’autre.
par contre, il faut alors un couple propre/sale pour la syntaxe spip (pour ceux qui veulent rester comme aujourd’hui). Mais c’est pas pire que la version actuelle
autre point : il faut une syntaxe très light pour pas alourdir le stockage, xml ayant tendance à être très verbeux.
Mais le code de SPIP s’il est moins verbeux devient completement incompréhensible sitot que l’on commence a faire des choses qu’il n’avait pas prévu au départ. Du genre tableau avec cellules fusionnées et code gras, par ex.
C’est simple soit on veut faire du balisage simple, et le code SPIP est suffisant, soit on veut du complexe et là je pense qu’il est raisonnable de changer de code.
a propos des tableaux :
pourquoi ne pas envisager de les gérer comme des objets a part, peu comme les documents, les images ou les formulaires ?
En fait ce n’est pas une bonne idée, les formulaires ou l’intégration d’objets déjà existants devraient suffire.
Une comparaison des différents éditeurs wysiwyg Ici]
Le choix de l’editeur s’orienterait plutôt vers [->[->[->[->TinyMCE]]]] voila ce que cela donne sur leur site [[->[->[->[->TinyMCE]]]]->http://tinymce.moxiecode.com/example_advanced.php?example=true]
Damien Guillaume :
Je viens de voir les fonctions propre() et sale(), et je trouve que ça ressemble à ce que je fais dans JaxeSPIPApplet.java. L’applet Java (dont le code source est disponible dans la partie privée de spip-contrib) transforme du SPIP en XML et du XML en SPIP. C’est assez complexe. On pourrait peut-être essayer de rassembler ces travaux, en faisant une transformation SPIP -> XML en PHP (PHP car le code serait proche de celui du coeur de SPIP) puis éventuellement (pour les éditeurs HTML) XML -> XHTML en XSLT (cette dernière opération serait facile). Dans l’autre sens, ce serait XHTML -> XML en XSLT puis XML -> SPIP (quel langage serait approprié ici ? Java/XSLT/PHP sont trois options).
La conversion de XML vers SPIP est plus facile que l’inverse, car la syntaxe XML est plus claire, plus simple, non ambiguë, et validable. L’édition en XML ou XHTML serait donc plus simple si, comme le suggère Philippe Lara, le code stocké dans la base était du XML. Au niveau stockage, c’est sûr que du XML prend plus de place que du SPIP, mais je pense qu’aujourd’hui ça n’a aucune importance : il vaut mieux avoir du code bien lisible, même si ça prend plus de place. Le code XML n’est par contre pas destiné à être édité comme le SPIP (c’est trop pénible à éditer à la main), donc il faudra garder la possibilité d’éditer du SPIP en faisant les conversions nécessaires.
Maj 02/08/06 : JaxeSPIP a maintenant son site web, et est disponible sous forme de plugin pour SPIP 1.9.
Choix de l’editeur :
Je voies deux projets dans le svn du spip 1.9, dojo et tinymce. Peut-être que faire un choix de l’editeur serait un premier pas. J’ai vue dans tinymce qu’il est possible d’avoir un système de plugin. Je ne connais pas Dojo. Listons les pour et les contres de chacun :
Dojo :
- pour :
- contre :
TinyMce :
- pour :
- contre :
BBComposer :
- pour :
- contre :
ça fait plaisir de voir que Diala s’en est préoccupée aussi ici
voici un copier-coller de la conversation que non venons d’avoir sur IRC le 4 mars 2006 a 22h
l’idée étant de séparer la conversion XHMTL produite par l’éditeur du code SPIP stocké
et donc de créer deux plugins
un plugin xhtml<—>propre
un plugin editeur
l
et si on inversait le problème ?
suite a un entretien autour de l’intégration de tinyMCE dans SPIP, il semble facile de le faire si on se limite a coller du xhtml dans spip, mais le pb c’est bien sur "que se passe-t-il si l’on veut pouvoir bénéficier de certains raccourcis propres a spip que sont les liens internes (vers art, rub, mot, sites etc). la solution de javascript transcodant tout cela semble faisable pour les cas simples et c’est d’ailleurs déja fait. mais le nombre d’objets spip enflant de jour en jour il me semble que cela va devenir une usine a gaz immonde.
pourquoi ne pas accepter de stocker du xhtml avec des balises complementaires
Avec le BBComposer, tu peux spécifier une URL personnalisée pour l’éditeur et ainsi, pourquoi pas, inclure les classes CSS utilisées par Spip. Et, comme je le disais plus haut, un simple overlay avec, pkoi pas, un menu contextuel contenant les raccourcis et mises en formes spécifiques à Spip. C’est du simple XUL et ça ne prends pas énormément de temps en développement. Apprendre XUL.
C’est fait : Le BBComposer peut être étendu avec Spip Typo une extension qui le fait supporter les raccourcis typographiques de Spip. Des béta-testeurs sont les bienvenus.
Nicolas FROIDURE :
Je me permet d’intervenir dans cette discussion pour vous faire connaître le BBComposer qui peut correspondre exactement à vos besoins en terme d’éditeur XHTML/CSS WYSIWYG. De plus, la création d’un Overlay pour étendre l’extension à la syntaxe Spip est tout à fait possible. Et, avantage indéniable, vous n’avez pas à bidouiller le code de Spip pour le faire fonctionner, il est complètement externe et ne demande qu’un textarea pour fonctionner.sdfgsdfsdfd
Discussions par date d’activité
Une discussion
WYM Editor permet de respecter la logique du HTML tout en permettant aux rédacteurs de s’adonner à toutes les fantaisies rendues possibles et cadrées par les feuilles de style du site.
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires : |