Suggestions d'évolutions pour les futures versions

**Picsonald** · 24/11/2020, 16h46

Bonjour,

J'ouvre ce topic pour permettre aux utilisateurs de Looping de faire des suggestions d'évolutions de Looping, d'ordre fonctionnel ou ergonomique.
J'utilise Looping depuis la v2, et j'apprécie de voir que le logiciel est régulièrement mis à jour ! Alors je me dis que si Paprick passe par là, peut-être accordera-t-il du crédit à certaines idées partagées ici.

Je commence par publier quelques suggestions d'ordre ergonomiques :
Lorsque l'on double-clique sur un attribut d'une entité, on arrive directement dans l'écran d'édition de l'attribut.
Cependant, ergonomiquement, on n'a pas conscience de cela, et ton croit que peu importe ou l'on clique dans l'entité, ceci va ouvrir l'écran d'édition de l'entité.
Serait-il possible d'ajouter un effet de survol lorsque le curseur est sur un attribut, pour bien comprendre qu'on s'apprête à éditer l'attribut lui-même ?
Illustration :

Lorsque deux éléments sont sélectionnés, et que l'on double-clic sur l'un d'eux pour ouvrir l'écran d'édition : rien ne se passe.
Serait-il possible de faire en sorte que le double-clic ouvre l'écran d'édition de l'élément sélectionné (quitte à ce que ça désélectionne le reste)
Illustration :

Depuis le MCD, serait-il possible de pouvoir modifier les cardinalités d'une patte d'association via un menu contextuel ?
Illustration :

Lorsque l'on est dans l'écran d'édition d'une entité, serait-il possible de pouvoir modifier les nom des attribut directement dans la grille ?
Serait-il possible de sélectionner le type de données via un clic-droit qui ouvrirait un menu contextuelle ? (pour les données nécessitant une "taille", la dernière taille utilisée dans Looping pourrait être réutilisée)
Serait-il possible d'avoir une case a cocher cochable/decochable pour interdir/autoriser les valeurs vides ?
Illustration :

Coté technique, je n'ai pas grand chose à redire.
À la rigueur, si : lors de l'export pour MySQL, serait-il possible de spécifier explicitement l'engine InnoDB au niveau de chaque table ?
Sans ça, elles sont susceptibles de se créer en MyISAM qui ne gère pas les clé étrangères.

**Picsonald** · 24/11/2020, 19h03

Tiens, une autre suggestion me vient en tête :
Pourvoir ouvrir un MCD en effectuant un glisser-déposer du fichier, depuis l'explorateur Windows jusque dans Looping.
Petite "coquille" en passant : je constate que le lien "Forum" proposé par le logiciel n'est plus d'actualité.

**Paprick** · 24/11/2020, 19h41

Bonsoir,

Tout d'abord, merci pour l'intérêt que vous portez à Looping !

Vos suggestions sont intéressantes et je ne manquerais pas de les prendre en compte pour une future version.
Sans faire trop d'effet d'annonce alors que la 3.0 vient juste de sortir, je peux d'ores et déjà dire que la 3.1 est dans les tuyaux : cela concernera essentiellement des évolutions techniques avec, par exemple, plus de possibilités dans l'organisation des clés composées ; le lien vers ce forum sera bien sûr mis à jour (la version 3.0 est sortie avant la création du forum) et je rajouterai votre dernière suggestion technique (concernant InnoDB) en proposant le rajout de code avant et après la création d'une table (l'option existe déjà, mais uniquement en début et fin de script).
Pour les évolutions ergonomiques, j'ai moi aussi quelques idées d'évolutions (urbanisation des gros modèles, notation "crow's foot" pour les MLD graphiques, ascenseurs pour les grandes classes d'entités, ...) et certaines rejoignent les vôtres.
Mais là, nous parlons d'une version 4, et il faudra être un peu patient !

**Picsonald** · 25/11/2020, 19h36

Bonsoir, et merci pour ce retour très complet.

Il est parfaitement normal d'être patient pour voir progressivement naître les différentes évolutions. C'est déjà très gentil à vous de les prendre en compte ! Celles que vous évoquez me semblent tout à fait pertinentes et Looping en ressortira grandi !

Pour cette future version 4, il serait merveilleux de voir le "nombre de clics" réduits pour faire un MCD. C'est facile à dire, mais moins à faire : j'en ai conscience. Mais... C'était pour résumer l'idée, quoi ^^

Envoyé par Paprick

Je rajouterai votre dernière suggestion technique (concernant InnoDB) en proposant le rajout de code avant et après la création d'une table (l'option existe déjà, mais uniquement en début et fin de script).

Je crois comprendre. L'idée est bonne (et permet de faire bien + que "juste" choisir entre InnoDB et MyISAM) : mais j'ai peur qu'elle ne soit quelque peu rébarbative à implémenter (disons qu'il faut le faire entité par entité). Pour rendre ça plus transparent, serait-il pertinent que Looping "se souvienne" de la dernière portion de code a avoir été apposée au niveau d'une entité, de telle sorte à automatiquement la remettre sur les entités qui seraient créés par la suite ?
Notez que ce mécanisme pourrait aussi être appliqué au niveau d'un attribut pour la longueur/collation d'une chaine et la taille d'un entier/décimal. Une fois qu'on a "fait un choix", dès qu'on crée un nouvel attribut, ce choix est "par défaut" répercuté, pour peu que l'on choisisse le même type de données.
Une bonne alternative serait d'avoir un point d'entrée dans le logiciel, pour pouvoir paramétrer ces valeurs par défaut (le code avant/après une table ; la longueur/taille de certains types de données) qui seraient alors utilisées de partout.

**Paprick** · 25/11/2020, 20h14

Bonsoir,

Envoyé par Picsonald

Je crois comprendre. L'idée est bonne (et permet de faire bien + que "juste" choisir entre InnoDB et MyISAM) : mais j'ai peur qu'elle ne soit quelque peu rébarbative à implémenter (disons qu'il faut le faire entité par entité). Pour rendre ça plus transparent, serait-il pertinent que Looping "se souvienne" de la dernière portion de code a avoir été apposée au niveau d'une entité, de telle sorte à automatiquement la remettre sur les entités qui seraient créés par la suite ?
Notez que ce mécanisme pourrait aussi être appliqué au niveau d'un attribut pour la longueur/collation d'une chaine et la taille d'un entier/décimal. Une fois qu'on a "fait un choix", dès qu'on crée un nouvel attribut, ce choix est "par défaut" répercuté, pour peu que l'on choisisse le même type de données.
Une bonne alternative serait d'avoir un point d'entrée dans le logiciel, pour pouvoir paramétrer ces valeurs par défaut (le code avant/après une table ; la longueur/taille de certains types de données) qui seraient alors utilisées de partout.

En fait, l'idée est de proposer un même code pour toutes les tables (paramétré dans "Compléments script SQL").
Par contre, reprendre systématiquement la valeur précédente pour les longueurs de chaînes ou d'entiers ne me paraît pas opportun : les valeurs par défaut actuellement proposées sont assez génériques, mais pourquoi pas paramétrer d'autres valeurs par défaut... à suivre...