Produits Entr'ouvert » w.c.s.

Tu pourrais rebaser ça en moins de patches ?

Ensuite, à survoler les patches, je ferais attention à ne pas amener comme ça la documentation dans l'interface (0011-workflows-add-help-text-on-ODT-templates-in-the-side.patch); à respecter la PEP8 (0009-workflows-add-specific-treatment-of-odt-templates-us.patch), à ne pas changer sans justification un nom de variable (0001-workflows-factorize-building-of-the-variable-diction.patch), etc.

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

Tu pourrais rebaser ça en moins de patches ?

Je vais viser 3 patch le refactoring, la fonctionnalité en elle même et les traductions.

Ensuite, à survoler les patches, je ferais attention à ne pas amener comme ça la documentation dans l'interface (0011-workflows-add-help-text-on-ODT-templates-in-the-side.patch);

J'ai bien pu croire qu'on était d'accord que c'était une bonne idée à un eo camp quelconque, mais j'ai du m'auto-persuader quelque part :) On a pris une décision contraire à un moment ?

à respecter la PEP8 (0009-workflows-add-specific-treatment-of-odt-templates-us.patch),
à ne pas changer sans justification un nom de variable (0001-workflows-factorize-building-of-the-variable-diction.patch), etc.

La variable couvrait un builtin; si il n'y a pas un PEP quelque part qui interdit ça je m'en coupe une...

Aussi, à dormir là-dessus, ça ne me va pas du tout de d'ajouter une dépendance et de conditionnaliser la fonctionnalité, certes c'est quelque chose qui se fait à d'autres endroits mais ça rend par exemple impossible le travail sur la documentation, "alors là peut-être que vous pourrez mettre de l'odt, ou pas, ça dépend de votre install".

Vu le travail à faire ici, je pense vraiment qu'on peut ouvrir l'odt, parler le content.xml, remplacer les balises, refermer le tout, sans dépendance extérieure.

Sur la documentation, le travail à faire c'est de permettre un lien / une intégration entre un espace wcs et une page précise de la doc (contextuelle), pas d'écrire la documentation dans le code.

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

Aussi, à dormir là-dessus, ça ne me va pas du tout de d'ajouter une dépendance et de conditionnaliser la fonctionnalité, certes c'est quelque chose qui se fait à d'autres endroits mais ça rend par exemple impossible le travail sur la documentation, "alors là peut-être que vous pourrez mettre de l'odt, ou pas, ça dépend de votre install".

Vu le travail à faire ici, je pense vraiment qu'on peut ouvrir l'odt, parler le content.xml, remplacer les balises, refermer le tout, sans dépendance extérieure.

Je ne ferai pas ce dernier effort, on peut aussi intégrer OOoPy dans les sources comme ezt & co dans l'idée qu'on aura d'autres manipulatoins OpenDocument dans le futur.

Sur la documentation, le travail à faire c'est de permettre un lien / une intégration entre un espace wcs et une page précise de la doc (contextuelle), pas d'écrire la documentation dans le code.

Ok je comprends le besoin de ne pas dupliquer la doc, par contre il y a à mon avis une vrai plus-value à pouvoir voir la documentation directement sans popup ou clique (la colonne de droite me parait parfaite pour ça); si on peut le faire directement depuis les sources mallard c'est cool.

Benjamin Dauvergne a écrit :

Vu le travail à faire ici, je pense vraiment qu'on peut ouvrir l'odt, parler le content.xml, remplacer les balises, refermer le tout, sans dépendance extérieure.

Je ne ferai pas ce dernier effort, […]

Si tu ne veux pas t'en charger, tant pis, je maintiens ma position.

Pour la personne qui serait intéressée à reprendre ça, ma perspective sur les choses à faire :

1. avant toute chose déplacer l'action dans wcs/wf/export_to_model.py
2. faire la modif pour accepter l'odt
3. pour la transformation de l'odt, ouvrir le zip, prendre le contents.xml via ElementTree
4. pour les remplacements, pour tous les <text:user-field-get/>, changer le nom de l'élément en text:span, changer le contenu de l'élément à la valeur souhaitée
5. les valeurs souhaitées, les obtenir via workflows.template_on_formdata(), pour permettre les expressions ezt, pas juste les subtitutions

Le point 5 me parait impossible gérer les boucles ou les conditions au milieu du contenu XML par exemple. Si c'est pour mettre une condition directement dans le nom du champ je ne sais pas si LO le permettra (y qu'à essayer hein :) ) mais ça sera particulièrement pas lisible; à voir si on ne peut pas utiliser directement un système de macros interne à LO, au moins pour du "{% if x 1 }contenu 1 { elif x 2 }contenu 2{ endif %}". Et aussi parmi mes patchs celui de refactoring me parait utilisables tel quels, ensuite il n'y a qu'à changer la méthode qui s'occupe particulièrement de l'ODT pour la méthode préconisée par Fred (là pareil partir de mon patch et virer toute référence à OOoPy donne un canevas).

Comme je l'écrivais je préférerais commencer par déplacer cette action de workflow dans un fichier isolé, y appliquer ensuite les modifications souhaitées rendra celles-ci plus faciles à retrouver plus tard.

Sur le point 5 (je trouve dommage que redmine ne permette pas de marquer des patchs comme obsolètes, "obligeant" à les supprimer), je ne suis pas sûr d'avoir dans mes petites recherches procédé de la même manière que toi pour le remplacement des champs, mais je n'ai pas eu de problème à y encoder des crochets et des espaces. L'utilisation que je vois ici, ce n'est pas des trucs compliqués, c'est simplement de pouvoir, en tête d'un document, d'écrire "Cher citoyen" ou "Chère citoyenne", en fonction des données.

À définir après la rencontre avec imio, pour confirmer l'utilisation d'appy.pod.

(note pour l'écrire quelque part : l'ayant vu plusieurs fois dans d'autre logiciels, je me dis qu'il est peut-être plus simple ou plus robuste de faire des remplacements dans un document de type tableur)

Le support OpenDocument est générique, on peut mettre de l'ezt n'importe où il y a du texte.

C'est implémenté par ces deux bouts de code:

def transform_opendocument(instream, outstream, process):
    '''Take a file-like object containing an ODT, ODS, or any open-office
       format, parse context.xml with element tree and apply process to its root
       node.
    '''
    zin = zipfile.ZipFile(instream, mode='r')
    zout = zipfile.ZipFile(outstream, mode='w')
    assert 'content.xml' in zin.namelist()
    for filename in zin.namelist():
        content = zin.read(filename)
        if filename == 'content.xml':
            root = ET.fromstring(content)
            process(root)
            content = ET.tostring(root)
        zout.writestr(filename, content)
    zout.close()

...

class ExportToModel(...):
    ....
    def apply_od_template_to_formdata(self, formdata):
        def process_root(root):
            def process_text(t):
                if isinstance(t, unicode):
                    t = t.encode(get_publisher().site_charset)
                t = template_on_formdata(formdata, t)
                return unicode(t, get_publisher().site_charset)
            for node in root.iter():
                if node.text:
                    node.text = process_text(node.text)
                if node.tail:
                    node.tail = process_text(node.tail)
        outstream = StringIO()
        transform_opendocument(self.model_file.get_file(), outstream,
                               process_root)
        return outstream.getvalue()

Quelle "information needed" ?

0001. Renommer template_context_on_formdata (get_formdata_template_context peut-être).

0002. Ne pas oublier l'entête GPL dans le wcs/wf/export_to_model.py.

0003.

La fin du test_formdata_generated_document_odt_download() continue à parler de RTF.

J'allais dire que les fichiers .odt ajoutés pour les tests devraient sans doute figurer dans le MANIFEST.in mais je me rends compte que les tests n'y sont en fait pas du tout inclus. :/

Pour le is_opendocument(), je vérifierais plutôt le contenu du fichier mimetype. (.startswith('application/vnd.oasis.opendocument.')).

Plutôt que les "od" à certains endroits, je laisserais "opendocument" en long.

Je passerais aussi le meta.xml dans la transformation (dans l'idée qu'on pourrait mettre [form_var_whatever] en dc:title, par exemple.

Profiter du moment pour lever une exception en cas d'erreur, plutôt que ce retour de deux valeurs dans model_file_validation() ?

Le fp.seek(0) ligne 187, il ne me semble pas utile, mais par contre il faudrait avoir un seek(0) dans le is_opendocument(), non ?

C'est normal, je vérifie juste que si je change de modèle et que je fais un export sur un formulaire ou il y a déjà un tel export, il n'y a aucun micmac.

Même avec l'explication je dois me tordre le cerveau, s'il fallait étendre le commentaire "# change file content, same name" dans le test, pour être plus clair, est-ce que ce serait correct de dire :

# change export model to now be a RTF file, do the action again on the same form and
# check that both the old .odt file and the new .rtf file are there and valid.

Pour le 0004, c'est ainsi et on peut imaginer des gros fichiers odt, ça me va de laisser l'affaire comme ça.

Je dirais donc qu'avec un commentaire précisant l'intention de cette partie du test, tu peux pousser le tout.

Oh, l'erreur survenue sur jenkins me fait penser à un commentaire que j'ai oublié; il aurait fallu s'assurer qu'une ancienne action continue à se charger correctement. (sans doute nécessaire de faire un from wf.export... import ... dans workflows.py).

Ack.

(je le note ici par facilité; pour des évolutions plus tard, si jamais, plutôt que appy.pod, il y a http://relatorio.readthedocs.org/)