Mutualiser le code quick test et session

[bchartier]

Suggestion de @fphg :

Il faudrait plutôt que le comportement entre session et quicktest soit le même.
Je pense que la fonction js ne le permet pas actuellement.

pour éviter de maintenir 2 templates, peut-être faut-il supprimer quicktest et n'utiliser que session, avec un mode sans enregistrement

[bchartier]

D'après que je comprends (je ne suis pas encore un expert de Flask et SqlAlchemy) :

Le souci est qu'avec SqlAlchelmy les objets instanciés correspondent à des enregistrements de la base de données. Si l'on veut avoir les mêmes templates et le même code javascript il faudrait que les objets soient également instanciés à partir d'enregistrements de la base de données. C'est contradictoire avec l'esprit de quick test.

Sauf si, peut-être (je ne suis pas sûr d'y croire), l'on arrive à mettre en oeuvre une des solutions suivantes :

• utiliser SqlAlchemy avec une espèce de base de données purement mémoire et donc volatile. Est-ce que cela existe pour SqlAlchemy ?
• introduire un héritage ou quelque chose qui y ressemble dans les classes représentant les infos de la base de données qui permettrai de manipuler soit des enregistrements de la base soit des objets purement mémoire
• stocker temporairement les infos en base et les rendre inaccessibles par d'autres utilisateurs

Qu'en pensez-vous les gens ?

[fphg]

Le 16/09/2016 à 17:20, Benjamin C. a écrit :

D'après que je comprends (je ne suis pas encore un expert de Flask et
SqlAlchemy) :

Le souci est qu'avec SqlAlchelmy les objets instanciés correspondent à
des enregistrements de la base de données. Si l'on veut avoir les mêmes
templates et le même code javascript il faudrait que les objets soient
également instanciés à partir d'enregistrements de la base de données.
C'est contradictoire avec l'esprit de quick test.

Oui

Qu'en pensez-vous les gens ?

Je pense qu'on va rester comme on est, et que quick test pourra héberger
les fonctions pas forcément utiles en persistence. Donc mon bug report
sur le "refresh md" est à ôter, ce n'est pas le même usage.

En revanche on pourra travailler le passage de params depuis une session
vers quick_test et vice-versa, pour éviter de développer deux fois les
fonctions.

[bchartier]

En revanche on pourra travailler le passage de params depuis une session
vers quick_test et vice-versa, pour éviter de développer deux fois les
fonctions.

Bonne idée.

[bchartier]

Deux choses qui ne fonctionnent pas de manière identique dans les deux modes :

• les filtres sur le niveau d'erreur et le type de test ne fonctionnent que pour les tests stockés en base de données (on ne peut pas trop faire autrement car c'est un filtre sur les enregistrements en base mais il faudrait éviter que ces étiquettes soient cliquables dans quick-test)
• le clic sur le badge de rafraichissement ne fonctionne que dans quicktest. Dans une session enregistrée en base sa plante. (constaté après ce95953)

[fphg]

pour ce dernier bug (rafraichissement) j'ai récemment corrigé pour quick_test : initialement il n'y avait qu'un seul catalogue donc pas d'ambiguité. maintenant, pour un test 1-fiche, il faut aussi transmettre l'id de catalogue (&cat=)

[bchartier]

pour ce dernier bug (rafraichissement) j'ai récemment corrigé pour quick_test : initialement il n'y avait qu'un seul catalogue donc pas d'ambiguité. maintenant, pour un test 1-fiche, il faut aussi transmettre l'id de catalogue (&cat=)

Oui, j'ai vu. Mais je me demande si cela a un sens pour des données qui sont en base. Doit-on afficher dans cette vue le résultat d'un test qui n'a pas été réalisé au moment où la session a été exécutée ?

[fphg]

Ce n'est pas le même use case, cependant cela améliorerait l'ergonomie (même comportement) et tout ce qui peut réduire le nombre de clics pour l'admin est bon à prendre. Priorité basse.