Les choix stratégiques concernant le développement des grilles dans l’interface

sans titre 1

Lorsqu’on veut mettre au point une grille, dans un programme, on utilise soit une grille du marché, soit on hérite de la grille de Microsoft.

Les grilles du marché sont des boîtes préprogrammées à tout faire, mais tout est rédigé façon non démontable, elles sont plein de macro-fonction dont on ne peut pas se départir pour s’accoler à tel ou tel principe, et si le besoin informatique du projet est pesant, le nombre est important de ces macro-fonctions qui répondent peu au besoin ou qui s’éloignent complètement du besoin, ou qui sont d’une ergonomie affreuse qu’on ne peut pas retoucher. Exemple, encore maintenant, dans la grille la plus connue, les filtres en entête, si on choisit une liste, n’affichent que les 50 premiers éléments sans barre de défilement. Autre exemple que je connais, quand ça coche tout seul plusieurs milliers de lignes, c’est lent. Ces grilles sont faites pour vendre leur macro-fonctions, leur côté visuel, leur côté attrape l’attention première et primaire.

Pour un petit besoin, mieux vaut prendre la grille de base, pour un moyen besoin, elles peuvent répondre à la demande d’un développement court, pour un grand besoin, il faut prendre le principe d’un développeur pompier de Microsoft que je connais qui dit : « Se dire que le développement avec une grille ne marche jamais bien ».

En ce qui concerne le besoin informatique pesant, on peut conjuguer grand besoin et petit budget en utilisant une grille du marché, donc qui ne répondra jamais bien au besoin, mais on peut aussi avoir le budget pour développer quelque chose de très personnel, très personnalisé, très personnalisable. On hérite alors d’une des grilles de Microsoft, la DataGridView en WinForms ou la DataGrid en WPF.

Pour les mobiles, pour les Stores, il est pratiquement impossible de faire de vraies grilles. Pour Internet, il est pratiquement impossible de faire de vraies grilles de saisie, ainsi qu’une fenêtre pratique sur un grand nombre de données, des arbres et des grilles à la fois…

Mais une grande erreur de repartir de l’héritage d’une grille Microsoft, est que pour chaque projet on hérite une nouvelle fois de la grille.

Pourtant, au bout d’un moment, on se rend compte que ce sont toujours un peu les mêmes fonctions qu’on redéveloppe dans chaque projet. Et les projets sont devenus irréconciliables, les fonctions ayant été ajustées au cas par cas sans une pensée pour la réutilisation. Pourtant, on en aura besoin, de la réutilisation. On voudra profiter de telle barre de filtres, de telle ouverture de sélection directement dans la grille, de tel outil de regroupement, de tel outil d’exportation en règle, de telle personnalisation… On voudra intégrer deux projets en un, puis deux… Si le code est écrit avec le minimum de méthodologie, cela équivaut à imbriquer trente grandes fonctions dans trente grandes fonctions, chaque ligne de code d’un côté venant potentiellement influencer de l’autre côté, chaque cas où on teste tel cas multi-conditionnel risquant de devoir être complété sans oubli, sans erreur, sans passage nouveau inopportun.

Donc, l’héritage est un bon principe, par exemple en vue de se faire une grille d’entreprise, mais il faudra qu’elle soit complètement générique, complètement indépendante de toute déclaration spécifique quelconque, et qu’elle contienne suffisamment de fonctions de base pour répondre aux cas majeurs.

Je vous invite de ce pas à consulter mon autre article sur un tel héritage que j’ai développé de manière inter-entreprises. C’est une grille qui, on peut le dire, répond à la totalité des cas grâce à un principe modulaire, héritable, décorable, avec les bonnes fonctions en virtuel choisies. A l’occasion, je peux vous faire des démonstrations, ou tenter une participation ensemble. Elle a une couche de personnalisation telle qu’elle pourrait être commercialisée sans la partie pour le développeur.

On découvre alors, en développant une telle grille, que certaines bonnes méthodes sont à remettre en question : En aval, pour un meilleur développement dans le cas de l’utilisation d’une grille, comme le développement de la couche entités de base de données, on comprend alors le problème du designer-first, le problème de la non indépendance des tables de clé externe de ce modèle, le problème de la répétition de la définition de champs dans plusieurs couches, particulièrement les couches MVVM, l’impossibilité chez Microsoft de pouvoir définir des requêtes sur des champs définis par l’utilisateur, donc que le passage par requête reste la meilleure formule pour notre cas…

Les deux grilles Microsoft sont limitées en nombre de fonctions, mais ont été ouvertes au développement aéré dans tous les sens, et proprement structuré. Ce qui n’est pas beaucoup le cas des grilles tiers, qui veulent surtout avoir un grand nombre de fonctions de base, à leur manière. Mais les grilles Microsoft ont encore de gros défauts, qu’un héritage permet de travailler avec quelques petits bidouillages de contournement. C’est aussi là qu’il vaut mieux avoir dans un outil réutilisé et donc sur lesquels ont aura planché pour stabiliser que de faire ce genre de forçage d’incapacité (car ce ne sont pas des bugs) dans des héritages multiples, fragiles si on ne les travaille pas, fragile s’ils peuvent subir les aléas des cas nouveaux et particuliers.

On découvrira au fur et à mesure des développements que certaines bonnes méthodes d’éditeurs de logiciels nous reviennent : comme le fait de faire une couche moteur indépendante de l’accès à la base, faire une couche d’un moteur d’accès à la base (un genre d’ensemble de builders, quoi), (suivie d’un héritage pour chaque logiciel de base de données), une couche très auto-générée de mapping avec la base (qui sera la couche Model), la nécessité d’écrire son propre générateur (pourquoi pas paramétrable), une couche par type d’interface (WPF, WinForms, et pourquoi pas à partir de là, la principale étant l’une de ces deux-là, développer de petits moteurs supplémentaires qui mettent à profit les autres développements pour avoir un rendu minimum sur un site…) Et une couche qui gère une personnalisation. (Tout ceci n’étant pas les couches ni ViewModel, ni View, qui sont dans l’ordre la couches métier orientée modules et la couche interface orientée modules).

On découvrira de nouvelles notions : Tel que l’intérêt de mettre un maximum de la couche métier dans des héritages des tables concernées du mappage de la base de données (purement, unitairement, plutôt que les dupliquer dans la couche ViewModel), donc de mettre ce code dans la couche Model, ce qui permet de définir une fabrique de tables externes qui ne seront que des héritages normés de l’objet Table abstrait qu’on aura créé dans la couche de base, intéressant de les utiliser tels quels pour les valeurs suggérées d’un champ. Le principe de décrire le code là où il est logique de le mettre (par exemple si une décoration est reproduite dans l’ensemble d’une entité, décrire ce décorateur dans cette entité ou un héritage de base), donc qu’il n’est pas vilain d’avoir au minimum une possibilité de décrire quelques éléments graphiques de façon abstraite dans ces entités…

Même Microsoft, finalement, est toujours dans le doute que ça ne marche jamais bien en ayant réécrit un nombre incroyable de fois sa couche abstraite de moteur d’accès aux données et les outils correspondants de mappage (ODBC, DAO, ADO, ADODB, ADO.NET, LinqToSql, Entities, WCF, Entities code-first). Tout cela n’est qu’insistance pour que les développeurs redéveloppent dans chacune de ces écritures successives, mais suite à de véritables échecs de conception sur lesquels je reviens dans un autre article (futur). Bien des entreprises ont carrément redéfinis le leur (de couche de moteur d’accès aux données, ainsi que l’outil de mappage correspondant) et n’en bougent plus, car le cœur de Visual Studio.Net reste, indéfiniment, de 2002 jusqu’à maintenant. Sauf peut-être les concepteurs d’interface qui s’accumulent aussi.

Frédéric Decréquy, version 1 du 22 juillet 2017.

Print | posted on Friday, July 6, 2018 12:42 AM

Feedback

No comments posted yet.

Your comment:





 
Please add 6 and 5 and type the answer here:

Copyright © Frédéric Decréquy

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski