Côté public on n'affiche que les métadonnées de type "tag" (ou "serie" ou "…") mais pas "editor", non ?
Du coup je vois mal l'impact côté public. Le 6 mai 2014 09:37, Nicolas <[email protected]> a écrit : > Le 6 mai 2014 09:32, Philippe <[email protected]> a écrit : > > > Je ne sais pas pour l'optimisation, mais ce serait chouette > > d'enregistrer la préférence de l'éditeur pour chaque billet, pour les > > ceusses qui font des tests d'éditeurs :P > > > > Tout à fait mais ça n'empêche pas de filtrer cette info côté public. > > > > > > Une question par exemple : deux utilisateurs sur le blog ont des > > préférences distinctes pour l'éditeur. Si le rédacteur simple rédige > > avec markdown et que l'admin corrige en xhtml, ça ne mettra pas à jour > > le code markdown, si ? > > > > Non. > > > > -- > > Philippe > > > > > > Le 6 mai 2014 08:18, Bruno <[email protected]> a écrit : > > > Le 6 mai 2014 08:07, Franck Paul <[email protected]> a > écrit > > : > > > > > >> Ce n'est justement pas au niveau du billet que l'éditeur est stocké, > > sinon > > >> on l'aurait collé directement dans la table post, avec la syntaxe > > utilisée. > > >> D'autre part, conserver cette info permet d'activer l'éditeur idoine à > > >> l'ouverture du billet, j'ai pas de meilleur endroit pour stocker ça. > > >> > > > > > > nouvelle colonne ou métadonnée, c'est de toutes façons chargé coté > public > > > (colonne post_meta). > > > 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... > > > > > > 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. Autant dire > > que > > > je n'adhère pas du tout à ce choix. > > > > > > -- > > > Bruno > > > -- > > > Dev mailing list - [email protected] - > > http://ml.dotclear.org/listinfo/dev > > -- > > Dev mailing list - [email protected] - > > http://ml.dotclear.org/listinfo/dev > > > -- > Dev mailing list - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Franck -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
