> Ca veut surtout dire que sur 500 billets en base en syntaxe
wiki, on aura
> 500 fois la même information qu'il faut utiliser legacyEditor. Là où vous
> me reprochiez d'avoir trop de champs dans les préférences utilisateur
(ie.
> 1 par syntaxe), vous en finissez par en coller un par billet...
>
>
Regarde comment est stockée l'information aujourd'hui ? Côté public on
n'affiche que du html jusqu'à preuve du contraire mais on aura 500 fois la
même information pour dire que le billet a été rédigé en syntaxte wiki,
textile ou ce-que--tu-veux. N'est-ce pas plutôt logique de faire un filtre
sur ce qu'on passe aux templates plutôt que de s'inquièter d'ajouter une
méta-données aux billets ?
L'information sur la syntaxe d'un billet est bien liée à un billet,
puisqu'on peut avoir des billets écrits en syntaxe différente, et que cela
sert au core pour convertir les colonnes post_excerpt et post_content en
post_excerpt_xhtml et post_content_xhtml. Dans la mesure ou la syntaxe est
compilée au niveau du backend, on doit bien pouvoir stocker la syntaxe
utilisée et le code originel en base. Le post_format a donc tout son sens
en base. Pas le post_editor.
L'information sur l'éditeur à utiliser n'est pas pour moi liée à un billet.
C'est soit lié à une préférence de l'utilisateur, soit lié à une syntaxe
donnée (soit au deux). Avoir un post_editor pour chaque billet est une
information ultra_redondante dans 99% des cas.
Ce n'est pas tant l'empreinte mémoire qui m'embête, mais le fait que la
même information soit répétée autant de fois en base.
Si en plus l'éditeur du billet n'est pas l'éditeur choisi
par
> l'utilisateur, on affiche un textarea, aucun intérêt donc.
Comme maintenant, si le format du billet était textile et qu'on a supprimé
le plugin idoine l'information ne sert plus à rien !
On parle de 2 choses distinctes : la syntaxe qui est liée à ce qu'on va
proposer d'éditer, et l'éditeur qui n'est qu'une couche cosmétique pour
avoir un champ user friendly. Supprime une syntaxe, on ne pourra plus
modifier un billet (du moins on ne pourra plus le compiler en html).
supprime un éditeur, on pourra toujours faire quelque chose avec une
textarea.
Je donne l'impression de "défendre" mon bout de gras en
le justifiant par
l'existant, mais si tu as mieux à proposer, tes idées sont bien entendu les
bienvenues.
Je réitère ma suggestion : proposer un éditeur préféré par syntaxe dans
les
préférences utilisateur. Pas de redondance, information à un seul
endroit, choix lié à l'utilisateur, pas au billet.
--
Bruno