Création d'un nouveau type de champ pour formulaire dédié au stockage d'un dessin sur une image

Les sujets de cette catégorie concernent le développement du logiciel MedshakeEHR.
Avatar de l’utilisateur
Bertrand
Messages : 177
Inscription : 21 juil. 2020, 18:08
Localisation : Dans le grand bain
Contact :

Re: Création d'un nouveau type de champ pour formulaire dédié au stockage d'un dessin sur une image

Message non lu par Bertrand »

Le proto est top.
Il faut effectivement toujours réfléchir et mettre en place avec l'idée la plus large possible, ce qui permet pour la suite d'envisager toutes les utilisations possibles.
Ici l'annotation sur phonecapture ou images DICOM.
Pour le json dans un champ mysql, j'ai vu ça il n'y a pas longtemps. Même question sur les perfs ... ! A voir si MariaDb gère aussi, car on assiste quand même à un switch mysql->mariadb dans les distrib apparemment ...

Pour l'implémentation, je n'ai pas encore la vision complète en tête. La gestion des backgrounds est une question, l'utilisation d'une photo / images dicom vient la rejoindre.
Je dirais que la source du background devrait entrer dans le json : la provenance (bitmap / dicom / ...) et l'url ou l'identifiant permettant de le récup.
Faut-il attacher le data_type au groupe medical ou en créer un spécifique ... là-dessus, faut voir les tenants et aboutissants (liés à la gestion de la data et au comportement en cas de réédition secondaire), voir le code de msObjet::createNewObjet()

Bref, grosse grosse avancée ! Merci et bravo.

B.

MedShakeEHR : Le Logiciel Médical Modulaire Libre
http://www.medshake.app/

MedShake : communauté médicale bien fraîche (et un peu secouée) !
https://www.medshake.net/

marsante
Messages : 175
Inscription : 25 juil. 2020, 18:42

Re: Création d'un nouveau type de champ pour formulaire dédié au stockage d'un dessin sur une image

Message non lu par marsante »

J'ai fait un première pull request ce matin pour l'ajout du tactile. J'ai copié le code existant et remplacé les mouses events par des touchs events, je n'ai pas testé en condition réelle par contre. Je vais essayer d'ajouter une fonction "effacer tout", ça me fera un bon exo vu que la logique change pas mal du canevas je trouve.

Concernant les remarques :
Si je comprends bien l'organisation future de la fonctionnalité, la librairie SVG.js sera placée dans le module de base et le JS du prototype sera à placer dans les formulaires qui en auront besoin via un sqlinstall ? Si c'est exact on pourra custom le code et notamment

Code : Tout sélectionner

// Outil sélectionné par défaut
	this.selectTool('square');
pour sélectionner l'outil le plus utilisé par chaque profession ?

Je n'avais pas trop saisi l'intérêt de donnée structurée pour un schéma, mais avec l'exemple j'ai enfin compris. Le champ description est top pour par exemple faire un schéma avant et un après, ou pour annoter une imagerie. Actuellement par défaut on ne peut pas modifier la première description, pareil que pour la fonction "effacer tout" ça peut être un bon exo pour moi de trouver pourquoi.

Par rapport à l'idée de la fonction que j'ai du module ostéo c'est déjà parfait en l'état, pour les autres besoins je ne me rends pas compte.
Concernant tout ce qui est stockage de la donnée perf etc etc j'y connais rien donc je ne me prononcerai pas :lol: .

Sinon si vous avez envie de m'orienter pour que je vous aide, n'hésitez pas.
marsante
Messages : 175
Inscription : 25 juil. 2020, 18:42

Re: Création d'un nouveau type de champ pour formulaire dédié au stockage d'un dessin sur une image

Message non lu par marsante »

Je viens de capter en regardant de façon plus approfondie le code que le fait que le premier champ de description n'est pas modifiable est une fonction voulue et pas un bug my bad :D .
Avatar de l’utilisateur
Indelog
Administrateur
Messages : 71
Inscription : 10 juil. 2020, 10:06

Re: Création d'un nouveau type de champ pour formulaire dédié au stockage d'un dessin sur une image

Message non lu par Indelog »

marsante a écrit : 05 sept. 2020, 12:13 J'ai fait un première pull request ce matin pour l'ajout du tactile.
C'est mergé, la démo est à jour, je le ferais régulièrement si je vois des pulls requests pour tester facilement les nouvelles implémentations.

J'ai vu qu'il y avait beaucoup de correction pour l'orthographe dans le commentaires. J'ai vraiment des soucis de ce coté, pour résumer simplement si je fait pas très attention à décortiquer chaque lettres de chaque mot au moment ou je lit (c'est pire quant j'écris) je les voit tout simplement pas. Pour moi à la simple lecture "description" ou "desciption" c'est pareil, ça me saute pas du tout aux yeux ni ne me parait évident. Du coup me relire et me corriger me prend beaucoup de temps et d'énergie. Alors pour les commentaires du code que de pensais de toutes façon provisoire j'ai laissé tombé. Je ne pensais par contre pas qu'il y en avait autant fautes, désololé pour ça, je vais tout de même essayer de faire plus attentions mais ce sera jamais vraiment top.
marsante a écrit : 05 sept. 2020, 12:13 J'ai copié le code existant et remplacé les mouses events par des touchs events, je n'ai pas testé en condition réelle par contre.
J'ai pensé aux tactile mais je l'ai pas implémenté car les cas d'usages ne sont pas les même qu'avec la souris et il faut repenser le déclenchement d'évènements différemment. Un exemple à la con est celui de la mise en évidence de l'élément qui va être supprimé quant on utilise la gomme. Avec la souris je vérifie l'état de l'élément sélectionné à chaque déplacement de la souris ('mousemouve') et déclenche des éléments si il ya changement d'élément en fonction de l'état du dessin à ce moment la via les propreté de l'objet (utiliser 'mouseover' et 'mouseout' n'est pas une bonne idée pour cela car on se retrouve avec des cas à la con comme quant une forme est survolé tellement rapidement que l'évènement n'a pas le temps de se déclencher ou quant on dessine et que l'on lève le bouton de la souris en dehors du dessin).

Avec du tactile je pense qu'il faudrait déterminer l'état du dessin a chaque tapes sur l'écran (+ déclencher les actions de dessin si un outils de dessin est choisi à ce moment la jusqu'au levé du doigts ou dans ce cas l'action de dessin serai exécuté à chiques 'touchmove').

Enfin bon faudra de toutes façon faire des tests d'usages.
marsante a écrit : 05 sept. 2020, 12:13 Je vais essayer d'ajouter une fonction "effacer tout", ça me fera un bon exo vu que la logique change pas mal du canevas je trouve.
Attention car chiques élément du dessin est lié à une description du coup supprime t'on les descriptions avec ?

Sinon quant on supprime un description (croix rouge à la au bout de la ligne de description), on supprime aussi tout les élément du dessin attaché à la description.
marsante a écrit : 05 sept. 2020, 12:13 Concernant les remarques :
Si je comprends bien l'organisation future de la fonctionnalité, la librairie SVG.js sera placée dans le module de base et le JS du prototype sera à placer dans les formulaires qui en auront besoin via un sqlinstall ? Si c'est exact on pourra custom le code et notamment

Code : Tout sélectionner

// Outil sélectionné par défaut
	this.selectTool('square');
pour sélectionner l'outil le plus utilisé par chaque profession ?
J'aimerai que ce champs puisse être configurer dans le yaml qui décrit un formulaire comme n'importe quel autres champs, avec ces propre propriété spécifique comme le choix d'un backround, la taille du schémas et d'autres trucs comme l'outil sélectionné par défaut ou même des descriptions pré-remplis.

Par contre je pense pas du tout placer du js dans la description du formulaire. Pour moi tout doit être gérer en instanciant la classe js dédié à la gestion du champs schémas. La macro twig qui rend le champs ne devrais renvoyé que peut de html (genre un <div> avec un id spécifique et les class qui vont bien pour l'afficher convenablement par rapport au autres champs) mais renvoyer en plus une balise <script> avec le nécessaire pour instancier une objet champs schémas, je pense que le reste du html pour le champ devait être produit par le js affin que l'affichage du champs puisse être versatile.

J'ai déjà pensé la classe js pour le champ schémas extensible pour ses outils de dessin (via la sous class DrawTool, je voudrai que les éventuels modules puisse étendre la class DrawSVG pour y ajouter d'autres outils de dessin qui leur serait spécifiques.

A ce propos je trouve mon système de class d'outil de dessin mal foutus : je suffixe dans le nom le la class le nom de l'outil (par example "DrawTool_square") et près j'instancie la class avec un eval des enfers tout pété :

Code : Tout sélectionner

this.drawtool = eval('new DrawTool_'+tool+'(this)');
alors que l'on pourrais crée les outil de dessin dans un array d'objet :

Code : Tout sélectionner

this.DrawToos = [
		'square': {...},
		'circle': {...},
		'pen': {...},
		'rubber': {...}
	];
A noté qu'il existe du type d'outil de dessin (le second type n'est pas vraiment un outil de dessin du coup il faudra surement changer le nom de la class pour lui donner une sémantique plus correcte) :
  • les outils de dessin à proprement parler (squre, circle, pen) qui dessine des trucs (ajout d'élément au SVG).
  • les outils qui font des actions, le seul représentant de se type pour le moment est 'rubber' mai je pense qu'il en faudra d'autres comme par exemple un truc pour avoir la description d'un élément au survol de la souris.
C'est pour cela que je pense qu'il faut ajouter une propriété type au outils de dessin (type: 'drawtool' ou type: 'actiontool').

Il faut bien sur que les outil implémente les méthodes standard tel que décrites dans la class DrawTool (beginDraw, doDraw, endDraw pour les outil de dessin, elles seraient différentes pour les outils de d'action).
marsante a écrit : 05 sept. 2020, 12:13 Je n'avais pas trop saisi l'intérêt de donnée structurée pour un schéma, mais avec l'exemple j'ai enfin compris. Le champ description est top pour par exemple faire un schéma avant et un après, ou pour annoter une imagerie. Actuellement par défaut on ne peut pas modifier la première description, pareil que pour la fonction "effacer tout" ça peut être un bon exo pour moi de trouver pourquoi.
marsante a écrit : 05 sept. 2020, 13:52 Je viens de capter en regardant de façon plus approfondie le code que le fait que le premier champ de description n'est pas modifiable est une fonction voulue et pas un bug my bad :D .
C'est en effet voulut vu que chaque élément du dessin doit être rattaché à au moins une description la première prend le rôle de description par défaut en ne peut pas être supprimé. Par contre au lieux de fixer son contenus à "Aucune description" on aurai pu le rendre modifiable. Par contre cette description n'est pas supprimable, si on veut la "reste" il faudra lui ajouté un bouton supprimé qui surprime les éléments du dessin lié sans supprimer la description elle même.

A noter que chaque description possède un numéro qui lui est normalement unique (calculé en ajoutant 1 au numéro de la dernière description), celle par défaut à le numéro 0.

Autres chose à noter : quant un supprime une description ne peut pas annuler l'action avec les bouton annuler et refaire.
marsante a écrit : 05 sept. 2020, 12:13 Par rapport à l'idée de la fonction que j'ai du module ostéo c'est déjà parfait en l'état, pour les autres besoins je ne me rends pas compte.
Concernant tout ce qui est stockage de la donnée perf etc etc j'y connais rien donc je ne me prononcerai pas :lol: .

Sinon si vous avez envie de m'orienter pour que je vous aide, n'hésitez pas.
Pour le stockage, le json semble être la solution, les pb de perfs pour la recherche pourait être en partis limiter en la couplant à d'autres critère (lié à un patient ou une consultation particulière), bref a voire à l'usage.
Bertrand a écrit : 04 sept. 2020, 15:49 A voir si MariaDb gère aussi, car on assiste quand même à un switch mysql->mariadb dans les distrib apparemment ...
J'ai noté Mysql mais sa fonctionne tout pareil avec MariaDB (d'ailleur j'ai tésté avec MariaDB)
Bertrand a écrit : 04 sept. 2020, 15:49 Pour l'implémentation, je n'ai pas encore la vision complète en tête. La gestion des backgrounds est une question, l'utilisation d'une photo / images dicom vient la rejoindre.
Je dirais que la source du background devrait entrer dans le json : la provenance (bitmap / dicom / ...) et l'url ou l'identifiant permettant de le récup.
Faut-il attacher le data_type au groupe medical ou en créer un spécifique ... là-dessus, faut voir les tenants et aboutissants (liés à la gestion de la data et au comportement en cas de réédition secondaire), voir le code de msObjet::createNewObjet()
Pour le moment j'ai pas encore non plus d'idée pour gérer les annotations sur les ressource issue de phone capture mais il faut en effet prendre en compte un propriété pour gérer le backround et sa provenance. Après tous pourrai être géré l'installation de la class "DrawSVG" qui pourrai prendre un json comme param et faire que le champ d'édition de schémas s'adapte tout seul en fonction de la source et du contexte.

Pour le modules ostéo, désolé je pense pas pouvoir aboutir à un résultat très rapidement (peut être d'ici la fin du mois), je vais avoir peut de temps pour travailler dessus et je voudrai pas bâcler le turc pour ne pas aboutir à un truc boiteux qu'on trainerai au final comme un boulet. La je doit laisser ça pour les 15 jours à venir du coup je laisse Marasante avancer dessus comme il peut durant ce temps la.
DEMAREST Maxime (Indelog)
marsante
Messages : 175
Inscription : 25 juil. 2020, 18:42

Re: Création d'un nouveau type de champ pour formulaire dédié au stockage d'un dessin sur une image

Message non lu par marsante »

Indelog a écrit : 06 sept. 2020, 10:56 C'est mergé, la démo est à jour, je le ferais régulièrement si je vois des pulls requests pour tester facilement les nouvelles implémentations.
Etttttttttttt ça ne marche pas, enfin si, mais ça fait des carrés microscopiques. Je crois avoir compris pourquoi : le touchstart ne correspond pas qu'au premier appui, mais aussi à l'appui quand on glisse le doigt, du coup il faut que le touchstart déclenche une fonction handler en plus par rapport à la souris. J'essaierai de voir si j'ai la compétence de tester cette hypothèse prochainement.
Indelog a écrit : 06 sept. 2020, 10:56 J'ai vu qu'il y avait beaucoup de correction pour l'orthographe dans le commentaires.
Oui j'en ai corrigé dans les commentaires pour une bonne raison, étant nuls en js vos commentaires m'aident beaucoup à repérer à quoi correspond le code, je passe donc la majorité de mon temps à faire ctrl+F pour trouver les zones qui m'intéressent, ça me facilite la recherche naturelle des fonctions. Je n'ai pas tout corrigé, je n'ai pas regardé quand c'était en rapport avec un code que je comprends, et je suis moi-même peu doué en orthographe donc je n'ai probablement pas tout vu :D. Par contre, je pourrai aider à la relecture à la fin une fois qu'on aura viré tout ce qui ne sert pas. Au passage pour mon script bash je me suis relu, mais la relecture d'un tiers ne ferait peut-être pas de mal :D .
Indelog a écrit : 06 sept. 2020, 10:56 Sinon quant on supprime un description (croix rouge à la au bout de la ligne de description), on supprime aussi tout les élément du dessin attaché à la description.
Ah oui, je m'étais trop fixé sur la première description. Peut-être rajouter un bouton reset sur celle-ci du coup. Je vais voir si j'y arrive.

Indelog a écrit : 06 sept. 2020, 10:56 Par contre au lieux de fixer son contenus à "Aucune description" on aurai pu le rendre modifiable. Par contre cette description n'est pas supprimable, si on veut la "reste" il faudra lui ajouté un bouton supprimé qui surprime les éléments du dessin lié sans supprimer la description elle même.
En y réfléchissant, ça peut être intéressant que la première description soit fixée comme actuellement. Pour les utilisateurs souhaitant juste dessiner sans avoir besoin de plusieurs descriptions ça leur évitera de taper à chaque fois quelque chose, à moins qu'un champ vide soit valable. Pour donner un exemple pour le module ostéo, un certain nombre d'utilisateurs feront juste leur schéma avant traitement. D'autres avant et après traitement et une minorité aura des besoins moins prévisibles. Donc je pourrai sur le module faire deux champs préremplis en plus des champs personnalisables par exemple.
Indelog a écrit : 06 sept. 2020, 10:56 Pour le modules ostéo, désolé je pense pas pouvoir aboutir à un résultat très rapidement (peut être d'ici la fin du mois)
Pas besoin d'être désolé c'est déjà super sympa de m'aider à ce point sur cette fonction, je n'aurai pas pu aboutir à ça. Je vais rentrer dans le dur moi aussi, avec la reprise de mes enseignements jusqu'à début juin prochain. Ça aura surtout un impact sur ma courbe d’apprentissage des trucs que je ne maîtrise pas comme le js, mais je devrai pouvoir maintenir le script bash d'installation, les rôles Ansibles, ce que j'ai déjà fait sur le module ostéo et ajouter des pages aux wiki sans trop de problèmes.
Avatar de l’utilisateur
Indelog
Administrateur
Messages : 71
Inscription : 10 juil. 2020, 10:06

Re: Création d'un nouveau type de champ pour formulaire dédié au stockage d'un dessin sur une image

Message non lu par Indelog »

J'ai commencé une ré-écriture à partir de zéro de tout le prototype via l'ajout de deux fichiers sur le dépôt du prototype :
  • shemas2.html
  • schemas2.js
Malheureusement j'ai eu beaucoup moins de temps que je ne le pensai pour travailler dessus et j'ai pas du tout fini (on est juste à l'état d'un squelette pour le moment). Le nouveau prototype fonctionne pas et n'est pas publié sur la démo.

La nouvelle version à pour objectif :
  • de disposer d'un code plus claire (mon premier code et vraiment trop bordélique) et beaucoup mieux organisé
  • facilement extensible par tout module via le simple ajout d'un élément dans le propriété Shemas.tools de la class Shemas (voire le js)
  • crée le champs uniquement via du js et ensemble de propriété passe via un paramètre JSON (presque pas de code html à généré depuis la macro twig pour générer le formulaire)
Je me remet dessus dans 15 jours en espérant avoir le temps de terminer complètement le second prototype.
DEMAREST Maxime (Indelog)
Répondre