Produits Entr'ouvert » Passerelle

+ la possibilité de nommer les autres colonnes du CSV, pour utilisation en mode "étendu" de wcs.

+ la possibilité de nommer les autres colonnes du CSV, pour utilisation en mode "étendu" de wcs.

Je voyais ça dans la définition, pas lors de l'appel.

Aussi, je ne mettrais pas ce module dans contrib.

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

+ la possibilité de nommer les autres colonnes du CSV, pour utilisation en mode "étendu" de wcs.

Je voyais ça dans la définition, pas lors de l'appel.

Pareil. Peut-être une simple ligne : nom,nom,nom,nom ? (pour faire vite et ne pas avoir une UI tordue)

Je disais à l'instant à Serghei : pas de cache explicite du fichier CSV, comptons sur l'OS pour ça.

Oui oui, le cache c'était dans la situation d'un CSV distant (« indiquer l'url d'un fichier CSV (qui serait mis en cache, durée du cache paramétrable...) »).

Je suis plutôt favorable à avoir un .po unique à Passerelle.

Pour la logique de columns_title. quand c'est mis, ok, on s'en sert, et quand c'est pas mis, on utilise la première ligne du CSV. J'ai l'impression que dans la pratique, ça va surtout nous ennuyer parce qu'on aura des CSV avec des titres de colonne en première ligne mais pas avec les titres qu'on veut (id, text).

# Create your tests here.

Fichier à supprimer; mais ce serait par contre super d'ajouter des tests dans un tests/test_csv_datasource.py.

Je me demande si on ne gagnerait pas à ne pas mélanger CSV local et CSV distant.

cache.set(self.slug, je préférerais qu'on utilise un hash de l'URL plutôt que permettre via le web d'altérer n'importe quel contenu du cache.

Le filtre, on pourra voir plus tard pour le faire évoluer.

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

Je suis plutôt favorable à avoir un .po unique à Passerelle.

D'accord, j'ai fait un ticket séparé: #8121.

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

Pour la logique de columns_title. quand c'est mis, ok, on s'en sert, et quand c'est pas mis, on utilise la première ligne du CSV. J'ai l'impression que dans la pratique, ça va surtout nous ennuyer parce qu'on aura des CSV avec des titres de colonne en première ligne mais pas avec les titres qu'on veut (id, text).

• une case à cocher qui indique si la première colonne est un titre, et génère des slug à partir de ça ("nom du village" -> "nom-du-village")
• dans ce cas, si columns_title existe, elle "écrase" le nom de certaines colonne : «,,id,,,text» dit que "id" est dans la colonne 3 et text dans la 6ème.

Je me demande si on ne gagnerait pas à ne pas mélanger CSV local et CSV distant.

Oui, ça ferait un code beaucoup plus clair (on n'a pour l'instant pas besoin du principe des CSV distants)

Le filtre, on pourra voir plus tard pour le faire évoluer.

Oui, par rapport à http://git.entrouvert.org/passerelle.git/tree/passerelle/datasources/models.py on a quand même des regressions, je trouve (possibilité de choisir la/les colonne à considérer comme résultat, c'est utile pour le dispatch cg14 par exemple)

Mais on peut pousser une version simple et jouer ensuite.

Thomas Noël a écrit :

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

Pour la logique de columns_title. quand c'est mis, ok, on s'en sert, et quand c'est pas mis, on utilise la première ligne du CSV. J'ai l'impression que dans la pratique, ça va surtout nous ennuyer parce qu'on aura des CSV avec des titres de colonne en première ligne mais pas avec les titres qu'on veut (id, text).

Il fallait faire un choix, je pense savoir guidé Serghei sur celui-ci. On peut en faire un autre, par exemple:

• une case à cocher qui indique si la première colonne est un titre, et génère des slug à partir de ça ("nom du village" -> "nom-du-village")
• dans ce cas, si columns_title existe, elle "écrase" le nom de certaines colonne : «,,id,,,text» dit que "id" est dans la colonne 3 et text dans la 6ème.

Oui, je trouve plutôt important de pouvoir zapper la première ligne.

Je me demande si on ne gagnerait pas à ne pas mélanger CSV local et CSV distant.

Oui, ça ferait un code beaucoup plus clair (on n'a pour l'instant pas besoin du principe des CSV distants)

Si on n'en a pas besoin, alors, pour moi, on peut tout à fait zapper cette partie pour l'instant et avoir du code plus simple.

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

Oui, je trouve plutôt important de pouvoir zapper la première ligne.

Pareil.
Et je rendrais columns_title obligatoire au format «,,id,,,text», comme sugère Thomas.

Il n'y a plus besoin de CACHE_SENTINEL.

Le patch zappe désormais systématiquement la première ligne, ce n'est pas souhaité. (le test passe à côté de ça en commançant le csv par une ligne vide).

        titles = self.columns_titles.split(',')
        indexes = [titles.index(t) for t in titles if t.split()]
        caption = [titles[i] for i in indexes]

Il y a ce if t.split() qui m'interloque; c'est quoi son rôle ?

columns_titles='id,,nom, prenom, sexe'

Avec une définition pareille, les noms de colonne vont garder les espaces, ça ne fera pas un truc facilement exploitable; ce serait bien que ça soit aussi testé par les tests.

Dans les tests aussi, en plus de vérifier que les dictionnaires ont les bonnes clés, ça peut être utile d'en vérifier aussi les valeurs (genre assert csv.get_data()[0] == {'id': '69', 'text': 'DELANOUE'}).

Dans les données de test il y a parfois des points-virgules parfois des virgules (?).

Il manque l'appel à gettext :

    class Meta:
        verbose_name = 'CSV File'

Et je mettrais les modifs au .po dans un commit séparé.

Il reste des références local_csv_file et remote_csv_file dans le template.

Aussi le columns_titles le "titles" m'ennuie parce qu'on y attend plutôt des identifiants (je suggère column_keynames à la place), et dans le help_text ne pas y mettre des crochets parce qu'on va se demander si on doit les taper (et je remplacerais peut-être juste par un exemple tout bête "ex: id,text,data1,data2").

Dernier truc j'espère, il reste un bout pas traduit; a priori ça pourrait être {{view.model.get_verbose_name}} :

<h2>CSV - {{ object.title }}</h2>

J'avais fait comme dans nos autres connecteurs:

{% block appbar %}
<h2>GDC - {{ object.title }}</h2>
...

{% block appbar %}
<h2>ClicRdv - {{ object.title }}</h2>
...

Certes, mais d'un côté on a des marques ou noms de produit et ici on a un nom générique.

ok, go.