SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribs sur SPIP-Zone, 284 visiteurs en ce moment

Accueil > Rédaction > Assistants de rédaction > Archives Assistants de rédaction > UnEditeurWysiwyg

UnEditeurWysiwyg

18 janvier 2007 – commentaire

1 vote

Ceci est une ARCHIVE, peut-être périmée. Vérifiez bien les compatibilités !

Un endroit pour reflechir

  1. à 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.

  1. 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)
  • 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 ...

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 :

  1. 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
  2. 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
  3. 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

piif : il faudrait se repartir le boulot entre plugin xhtml<->propre et plugin editeur

piif : je devrais pouvoir faire qqchose pour le premier

de mon point de vue, c’est vite vu :-)

j’aurai besoin de l’éditeur tot ou tard, pas du xml, donc forcement, coté motivation :-)

piif : mais il faut définir les points de liaisons entre plugins

en gros, l’idée c’est d’avoir un (ou plusieurs, mais pour quoi faire ?) editeur qui manipule du xhtml

avec des restriction sur ce qu’on est capable d’écrire en raccourcis spip aujourd’hui

l piif : l’idee c’est pour l’instant de stocker en spip non ? avec le plugin qui reprend le code de l’editeur xhtml et le transforme dans les deux sens

+ un mécanisme « format spip » <-> xhtml, c’est à dire une fonction propre modifée + une fonction sale

j’aurai besoin de l’éditeur tot ou tard, pas du xml, donc forcement, coté motivation :-)

piif : mais il faut définir les points de liaisons entre plugins

piif : j’ai dit xhtml pas xml

ça peut s’arréter aux fonction propre/sale a priori

ha ok, pardon

donc, un stockage en bdd en xhtml, ou en texte -> xhtml -> wys.. -> xhtml -> texte ?

en gros, l’idée c’est d’avoir un (ou plusieurs, mais pour quoi faire ?) editeur qui manipule du xhtml

avec des restriction sur ce qu’on est capable d’écrire en raccourcis spip aujourd’hui

piif : l’idee c’est pour l’instant de stocker en spip non ? avec le plugin qui reprend le code de l’editeur xhtml et le transforme dans les deux sens

+ un mécanisme « format spip » <-> xhtml, c’est à dire une fonction propre modifée + une fonction sale

ensuite, il faut voir comment intégrer cet éditeur dans l’admin ou ailleurs (form forum par exemple)

or, ce dernier point se rapproche de mon autre chantier du moment, les editables

mais ça, c’est pas immédiat, d’autant plus que j’ai pas eu des masses de retours sur la question

donc je sais pas du tout si c’est une impasse ou si ça vaut le coup de creuser plus

bref, aujourd’hui, le truc le plus avancé c’est le plugin tinymce mais il mélange un peu tout

piif : l’interet de choisir plusieurs editeurs c’est le choix, les spipiens aiment bien

quand j’aurai suffisamment avancé l’histoire du mail2spip, je reprendrai un peu ce plugin pour le mettre un peu plus au carré (quite à le découper en plusieurs

« le choix » ok, mais c’est quoi l’intéret si de toutes façons on limite aux mêmes possibilités d’html ?

piif : le createur du plugin FCK que je te citais cet aprem serait preneur

il faut faire un gros travail de personnalisation de tinymce pour rentrer dans ces contraintes.

si celui qui fait ce travail le fait aussi pour dojo, fck et j’sais pas quoi, à la fin, on aura 3 solutions techniques qui ont la même allure => choix sans interet :-)

la seule exception c’est jaxe, mais là, pour l’intégrer dans l’admin c’est chaud car l’idéal c’est d’utiliser le wys* pour chaque champ

et s’il faut lancer 8applets pour éditer un article !

et on en recause courant de semaine prochaine

piif : la je dirais que le wysiwwyg c’est bien pour le multiligne, par pour les titres, sous titres etc.. car alors c’est vraiment le bordel

piif : d’accord pour le wiki je fais

et chapo, ps, descriptif ? et les descriptions de rubriques, mots clé, bio d’auteurs...

if you want

l’idéal de l’idéal serait d’avoir 2 perso : une simplifiée pour les titres et compagnie

sans intertitre, tableaux et autres puces, mais avec gras, italique, voire code

si tu installes le plugin tinymce et que tu affiches un article, puis que tu modifie l’url pour appeler exec=articles_new à la place de exec=articles

tu verra une version ou un clique sur une zone de texte ouvre tiny dessus, puis le « sauver » peremt d’envoyer une mise à jour en ajax

pour l’instant, ça n’écrit rien, mais l’idée est là.

et ça permet de rendre toutes les zones éditables sans avoir un truc énorme avec 12 barres de boutons dans la page

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 interprétées comme telles par l’editeur wysiwyg ? car c’est bien lui qui pose problème. les plugin de tinyMCE permettraient-ils de faire cela ?

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

Dernière modification de cette page le 28 juillet 2007

Retour en haut de la page

Vos commentaires

  • Le 8 août 2008 à 12:06, par ? En réponse à : UnEditeurWysiwyg

    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

Répondre à cet article

Qui êtes-vous ?
  • [Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Adaptive Images

    15 novembre 2013 – 66 commentaires

    Un plugin pour permettre aux sites responsive d’adapter automatiquement les images de la page à l’écran de consultation. Adaptive Images, que l’on pourrait traduire par Images adaptatives, désigne la pratique qui vise à adapter les taille, (...)

  • Métas

    8 août 2009 – 50 commentaires

    Ce petit plugin permet l’ajout, depuis l’espace privé, de metatags aux articles et rubriques de SPIP, ainsi que la mise en exergue de mots importants.

  • Brownie

    6 juillet 2012 – 43 commentaires

    Brownie est une adaptation pour Zpip du thème du même nom initialement développé par Egrappler.com. Présentation Brownie est un thème Responsive à deux colonnes. La démonstration ci-dessous utilise la version 2.0.0 de Brownie, la dist de SPIP3 (...)

  • Métas +

    3 décembre – 13 commentaires

    Améliorez l’indexation de vos articles dans les moteurs et leur affichage sur les réseaux sociaux grâce aux métadonnées Dublin Core, Open Graph et Twitter Card. Installation Activer le plugin dans le menu dédié. Dans le panel de configuration, (...)

  • Acces Restreint 3.0

    11 décembre 2008 – 785 commentaires

    Le plugin accès restreint permet de définir et de gérer des zones de l’espace public en accès restreint. Cette version du plugin a été redévelopée et optimisée tout spécialement pour SPIP 2.0. Il en découle une amélioration des performances sur les gros (...)

Ça spipe par là