Produits Entr'ouvert » w.c.s.

Rapidement fait pendant la réunion hier mais à vérifier, compléter de tests, etc.

--- a/wcs/fields.py
+++ b/wcs/fields.py
@@ -494,8 +494,12 @@ class CommentField(Field):
         pass

     def fill_admin_form(self, form):
-        form.add(TextWidget, 'label', title = _('Label'), value = self.label,
-                required = True, cols = 70, rows = 3, render_br = False)
+        if self.label and not self.label.startswith('<') and '\n\n' in self.label:
+            form.add(TextWidget, 'label', title=_('Label'), value=self.label,
+                    required=True, cols=70, rows=3, render_br=False)
+        else:
+            form.add(WysiwygTextWidget, 'label', title=_('Label'), value=self.label,
+                    required=True)
         form.add(StringWidget, 'extra_css_class', title = _('Extra classes for CSS styling'),
                 value=self.extra_css_class, size=30, advanced=(not self.extra_css_class))

Si tout le monde est bien conscient que cela risque de faire "exploser" les commentaires qui avait été rédigés avec du HTML (ckeditor ayant fortement tendance à nettoyer le HTML à sa façon), je suis ok.

Je serais d'avis de faire un tour des champs commentaires sur notre prod, quand même.

Ça ne va rien faire exploser de manière spontanée. À l'édition d'un champ commentaire dont l'HTML serait défectueux, celui-ci sera d'abord remis d'aplomb et ça correspondra au rendu DOM qui était de toute façon déterminé par le navigateur.

exemple : <p>comm<p>hello<li>TOTO donnera <p>comm</p><p>hello</p><ul><li>TOTO</li></ul>.

Ce qui ne sera plus possible, par contre, c'est vrai, c'est commencer de l'HTML dans un premier champ commentaire et le terminer dans un second; genre un premier je mets <div style="background: red";"> et un autre je mets </div>. Si on veut pouvoir continuer à faire ça, on doit modifier la détection sur l'usage du ckeditor pour l'activer uniquement si les balises sont correctement balancées.

On a le temps de discuter, je voudrais de toute façon d'abord avoir #9837.

(note quand même : je pense aussi aux commentaires avec des [if-any ...] qui risquent de devenir un peu moins clairs, faudra quand même bien tester tout ça)

On peut aussi ne pas activer le ckeditor si on voit un [.

Frédéric Péters a écrit :

On peut aussi ne pas activer le ckeditor si on voit un [.

Ce qui est sans doute excessif, mettons plutôt, si on voit un [if

pendant qu'on y est : [is, [if et [for ... ou bien plus bêtement [end] ?

Je viens de faire l'inventaire de la prod, il n'y a pas d'utilisation d'html divisé sur deux champs. (ma méthode : regarder ce qui commence par un < mais ne finit pas par un >, les résultats sont du genre <strong>Important : </strong>bla bla bla.

Du coup je ne sais plus quoi penser ;)

Ack

Je crois qu'on s'est trompé, le wysiwyg reste quand il y a un [end]

Test qui ne passe pas:

diff --git a/tests/test_admin_pages.py b/tests/test_admin_pages.py
index 0847a37..8ca7592 100644
--- a/tests/test_admin_pages.py
+++ b/tests/test_admin_pages.py
@@ -986,6 +986,13 @@ def test_form_edit_comment_field(pub):
     resp = app.get('/backoffice/forms/1/fields/1/')
     assert 'WysiwygTextWidget' in resp.body

+    # starting with a < but with ezt
+    formdef.fields = [fields.CommentField(id='1', type='comment',
+        label='<p>a comment [if-any test]with ezt[end]</p>')]
+    formdef.store()
+    resp = app.get('/backoffice/forms/1/fields/1/')
+    assert 'WysiwygTextWidget' not in resp.body
+
 def test_form_legacy_int_id(pub):
     create_superuser(pub)
     create_role()