Produits Entr'ouvert » Passerelle

Je ne fais pas de l'ergonomie de l'admin Django (interface hiérarchique sur les dates) un objectif essentiel, déjà si on a un champ début + fin avec un sélecteur, c'est byzance.

Et si on peut réutiliser un truc existant genre django-filter encore mieux (je n'ai pas regardé si ça aidait ou pas).

Quelle opinion on a de django-tables2 ? il est déjà dans authentic.

Moi mauvaise.

Note : j'ai trouvé un datepicker sans aucun JS : https://codepen.io/maheshambure21/pen/VYJQYG

0001: à poser dans un autre ticket (à créer)

0002: ok

0003: pour avoir le nombre de secondes d'une datetime "dt" depuis le 1/1/70 c'est « time.mktime(dt.timetuple()) » . Mais en dehors de ça, aucun besoin d'avoir les logs en json, il faut une page web et je pense que c'est plus simple à faire (juste envoyer la queryset dans le contexte) que d'inventer une sérialisation.

0004: heu.. bah... c'est bien mais... donc tu effaces ce que tu as fait dans 0003 ? je me déclare perdu :)

• pas besoin de object.get_log_url : il faut passer par {% url 'view-connector-log' connector=... slug=... %}
• je m'étais dit qu'on devrait éviter d'appeler la page juste "logs", ça me semblait un peu trop court et ça pourrait rentrer en conflit avec un endpoint; plutot "_logs" ou "logwatch" ... et puis bon, on n'a pas de endpoint "logs" dans aucun connecteur, alors pourquoi pas.

Donc à mon avis, faut reprendre un peu l'affaire en 2 patches, le manager (0002) puis la page (0004). Le 0001 doit aller ailleurs et le 0003 disparaitre.

Elias Showk a écrit :

Note : j'ai trouvé un datepicker sans aucun JS : https://codepen.io/maheshambure21/pen/VYJQYG

Vraiment <input type=date> et <input type=time> ça suffira très bien.

Vraiment <input type=date> et <input type=time> ça suffira très bien.

Oui; et si jamais on veut moduler les <input tpye=date> pour ajouter une icône dedans, comme c'est le cas à l'URL pointée, on fera ça dans gadjo.

(pas supprimer l'existant avec la mini-vue sur les logs récents, assurer un lien de celle-ci vers une page avec les logs prolongés)

(Et si le souhait était vraiment de dégager ce tableau, ça devrait passer par un lien "logs" dans les actions primaires du connecteur, pas au milieu de la page).

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

(pas supprimer l'existant avec la mini-vue sur les logs récents, assurer un lien de celle-ci vers une page avec les logs prolongés)
(Et si le souhait était vraiment de dégager ce tableau, ça devrait passer par un lien "logs" dans les actions primaires du connecteur, pas au milieu de la page).

Perso àa me va très bien de laisser le tableau en bas, très pratique. Idéalement sur les lignes affichées, avoir un lien vers la page concernées dans les logs (genre, je clique sur un événement que je vois à 9h43, ça m'envoie sur la page des logs qui affiche cet événement en premier de la liste).

• sur la vérif des droits sur la page, on peut pas faire mieux qu'une gestion dans le template (ie vérifier au niveau de la vue) ?
• le code qui parcours les lookup_dict.items est un peu tordu, genre un "del" sur un dico qu'on est en train de parcourir, non, pas bien. On peut certainement ré-écrire ça plus proprement et sans passer par une q_list intermédiaire, construire directement le filter().
• dans la vue, la construction du kwargs peut aussi être simplifiée, en construistant d'abord le lookup_dict (get+update(post)) et en y extrayant les éventuelles clés page,lookup_or,order_by,page_size

Perso et brutalement, parce que mon idée des tickets que je pointais c'était des petits améliorations rapides, genre max ½ journée et des patchs évidents à relire : un premier commit, qui serait une ListView, max 20 lignes; puis un second commit qui ajoute en haut de page un <input>, qui filtre sur la date (ou le contenu selon ce qui sera trouvé dans le champ), 15 lignes de plus. Avec comme résultat ce qu'on a aujourd'hui dans TransactionListView dans combo, une vue qui tient sur un écran, un template presque pareil.

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

Perso et brutalement, parce que mon idée des tickets que je pointais c'était des petits améliorations rapides, genre max ½ journée et des patchs évidents à relire : un premier commit, qui serait une ListView, max 20 lignes; puis un second commit qui ajoute en haut de page un <input>, qui filtre sur la date (ou le contenu selon ce qui sera trouvé dans le champ), 15 lignes de plus. Avec comme résultat ce qu'on a aujourd'hui dans TransactionListView dans combo, une vue qui tient sur un écran, un template presque pareil.

OK donc j'essaye de résumer la suite :
- conseil de pas passer plus d'une 1/2j de travail en plus
- garder le tableau des logs en bas de page, mais avec un lien vers une page pleine
- une interface simplissime avec un input de dur à cuire
- améliorer le code de la requete de filtrage (q_dict, lookup_dict.items, et extraction des paramètres type page page_size dans le code de la vue)

- améliorer le code de la requete de filtrage (q_dict, lookup_dict.items, et extraction des paramètres type page page_size dans le code de la vue)

C'est là qu'on arrive à des commentaires différents Thomas et moi; mon option serait de totalement dégager ça, pas de manager, pas de gestion de plein d'infos différentes possibles en paramètre, juste un get_queryset de 10 lignes qui regarde dans un champ. (comme TransactionListView).

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

C'est là qu'on arrive à des commentaires différents Thomas et moi; mon option serait de totalement dégager ça, pas de manager, pas de gestion de plein d'infos différentes possibles en paramètre, juste un get_queryset de 10 lignes qui regarde dans un champ. (comme TransactionListView).

J'entends bien le besoin de simplifier, et je vais essayer de me limiter au maximum, j'ai souvent tendance à faire ça. Le dernier patch est encore mal foutu et il faut simplifier le code et l'algo, sans forcément revenir sur la fonctionnalité qu'il propose, c'est très possible en peu de temps.

Mais :

- mon idée avec ces filtres, c'est qu'un seul filtre ne suffit pas pour toujours: "et à quand le filtrage des sourceip ?" - demande X ou Y demain. "et quand sur le message ?" un autre. Bref, je propose de prévoir des filtres au vu des champs du modèle Django concerné.

- aujourd'hui, je préfère utiliser le formalisme proposé par Django : "on cherche une requête un peu complexe sur un modèle, on regarde le Manager". Les manager sont là pour rester dans Django à priori...

- mon idée avec ces filtres, c'est qu'un seul filtre ne suffit pas pour toujours: "et à quand le filtrage des sourceip ?" - demande X ou Y demain. "et quand sur le message ?" un autre. Bref, je propose de prévoir des filtres au vu des champs du modèle Django concerné.

Mais ça viendra avec de l'UI, et il y aura ajout de <input name="ip"/> et dans le get_queryset l'ajout d'un if 'ip' in request.GET: queryset = queryset.filter(ip=request.GET['ip']); ça sera un patch de cinq lignes, simples, beaucoup plus simple que la proposition.

- aujourd'hui, je préfère utiliser le formalisme proposé par Django : "on cherche une requête un peu complexe sur un modèle, on regarde le Manager". Les manager sont là pour rester dans Django à priori...

Il y a un grand bénéfice à limiter les endroits à lire/comprendre; je préfère de très très loin la simplicité d'un get_queryset dans la vue, avec un .objects.filter(message__contains=...), qui est limpide et compréhensible par tout le monde en un coup d'œil. Plutôt qu'y avoir un .paginated_objects.get_paginated_logs(lookup_dict=request.GET.dict()).

De ton résumé :

- garder le tableau des logs en bas de page, mais avec un lien vers une page pleine

"une page pleine", cette page étant une vue, basée sur ListView, ressemblant à la TransactionListView dans combo. Le patch n'a pas de vue.

- une interface simplissime avec un input de dur à cuire

Et le patch propose un LogFilterForm avec 7 champs, et zappe au passage la pagination qu'on devrait partager via gadjo avec les autres modules.

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

"une page pleine", cette page étant une vue, basée sur ListView, ressemblant à la TransactionListView dans combo. Le patch n'a pas de vue.

J'ai réduit la quantité de temps et de code en faisant l'impasse là dessus. En échange, on peut afficher plus de lignes avec le paramètre page_size

- une interface simplissime avec un input de dur à cuire

Et le patch propose un LogFilterForm avec 7 champs, et zappe au passage la pagination qu'on devrait partager via gadjo avec les autres modules.

Les 4 champs sont date et time, impossible d'avoir un input datetime compatible firefox.
Les 3 autres champs ne rende que paramétrables le Paginator qui était déjà dans le code.

Pour la pagination par Gadjo, là comme ça je ne vois pas comment faire pour avoir en même temps le fonctionnement par POST form et le fonctionnement par GET de Gadjo. Est-ce que c'est indispensable ?

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

Non pour moi ça ne va pas du tout; l'élément important c'était simplement avoir une vue, basée sur une ListView.

On a une sorte de "fuzzy-filter" sur message aussi, pas mal, mais on perd la possibilité de faire une fenêtre de date et time, ici seulement + 1 jour.

La façon de désérialiser la date avec dateutil est intéressante, mais moins clair pour l'utilisateur à mon avis, plus magique.

Les deux versions me vont. La mienne plus lourde c'est sûr.

Elias Showk a écrit :

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

Non pour moi ça ne va pas du tout; l'élément important c'était simplement avoir une vue, basée sur une ListView.

On a une sorte de "fuzzy-filter" sur message aussi, pas mal, mais on perd la possibilité de faire une fenêtre de date et time, ici seulement + 1 jour.

En fait on a juste besoin d'un heure de début et comme date_util renvoie du date time on peut taper ("2018-04-13" ou "<idem> 09:34" et on verra tout à partir de ce moment là, avec la pagination c'est suffisant, je dirai même que ce n'est pas nécessaire de mettre une date de fin dans le filtrage, la pagination suffit, à la rigueur on pourrait souligner les changements d'heure en surlignant pour aider la lecture mais c'est du chipotage).

La façon de désérialiser la date avec dateutil est intéressante, mais moins clair pour l'utilisateur à mon avis, plus magique.

Pour moi le message d'aide dans le span devrait d'office proposer les formats acceptés, le seul souci avec cette implémentation c'est qu'on ne peut pas à la fois définir la date de démarrage et filtre sur un texte libre, à Thomas de dire s'il en a quelque chose à foutre, j'en doute.

Les deux versions me vont. La mienne plus lourde c'est sûr.

Je préfère la simplicité.

Benjamin Dauvergne a écrit :

Je préfère la simplicité.

Merci pour le retour, je vais reprendre et terminer la patch de fred, donc.
Par contre, je ne vais pas me lancer dans les aides visuelles pour rattraper cette implémentation du backend, c'est une perte de temps, il faudrait avoir des retours d'utilisation dans un second ticket et un second temps

Merci pour le retour, je vais reprendre et terminer la patch de fred, donc.

Vraiment je ne souhaite demander à personne d'écrire des tests pour ce code; je vais le faire, il sera relu, etc.

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

Vraiment je ne souhaite demander à personne d'écrire des tests pour ce code; je vais le faire, il sera relu, etc.

Ack, testé sur mon publik local tel quel. Je te passe la main

Ca me plairait que sur chaque ligne affichée dans resource-logs-table.html, on fasse un lien vers « view-logs-connector?=q=datetime_de_la_ligne », par exemple au niveau de la colonne timestamp. Comme ça hop, ça nous fait une URL partageable avec les collègues très facilement.

Mais si tout le monde est lassé de ce ticket, ack ainsi.

Il y a quantité d'évolutions possibles mais oui je les préférerais dans de nouveaux tickets.

Et donc comme je disais, «ack» ainsi.