Le CodoBrowser est une application particulière, en ce sens qu'elle a été développée pour un contexte particulier, et pour un environnement particulier, celui d'une société pour laquelle je travaille régulièrement.
Ils disposent sur place d'un dictionnaire de données multi-plateformes, qui est utilisé via des composants maison, par pratiquement toutes les applications développées par ou pour la société.
Le principal problème de ce dictionnaire de données est qu'il existe au travers de plusieurs environnements différents (disons par exemple un environnement de développement et un environnement de production) et qu'il n'est pas toujours évident de voir quelles données sont disponibles dans quel environnement.
Les plateformes disponibles sont DB2 sur mainframe, SQL Server sur un serveur Windows NT, et une dernière version Access 97, qui peut être disponible en local ou sur un serveur dit de référence. Le CodoBrowser est actuellement capable d'exploiter les ports Access et SQL Server de cette base de données. Je doute de pouvoir exploiter la version DB2, qui est celle dite de référence, je ne sais pas si un middleware est prévu dans leur environnement pour exploiter directement la base de données en question, car habituellement, ce sont des modules Cobol tournant sur mainframe qui s'occupent d'exploiter les différentes bases de données DB2 mises en oeuvre.
Interrogation des données
Le CodoBrowser se résume donc à un interrogateur de données, il exploite les structures propres à chaque environnement.
Concrètement, il existe trois tables principales pour le dictionnaire de données et à chacune d'entre elles est consacrée une partie de l'interface. Chacun des panneaux de l'interface permet d'interroger une table selon le principe d'égalité ou du LIKE (SQL) en encodant une string, sur laquelle se basera la recherche. Pour l'exploitation du LIKE, il suffit simplement de placer des caractères génériques (%) et CodoBrowser fera le reste.
La règle d'overload
Le principal problème de ce programme, c'est qu'il ne peut pas se permettre de faire de lourdes requêtes sur la DB, du style ramener toute la table. En fait, ce n'est pas très gênant avec Access car la DB peut être locale, mais ça l'est beaucoup plus sur SQL Server. Pour résoudre ce problème, j'ai inventé le concept de l'overload rule, un mécanisme qui empêchera les grosses requêtes. Il est encore perfectible à ce stade.
Attention à la lourdeur de l'interface
J'ai aussi voulu éviter les boîtes de dialogue intempestives, il n'y a rien de plus ennuyeux que de taper tout le temps la touche enter ou d'aller cliquer sur OK parce que vous avez commis une erreur. j'y ai donc apporté deux remèdes.
Le rôle de la statusbar
Le premier est l'envoi de tous les messages d'information et d'erreur sur la barre de status, en faisant apparaître le message caractère par caractère, afin que l'utilisateur puisse se rendre compte qu'il s'est passé quelque chose. Par exemple, la règle d'overload a été appliquée, et donc, aucune ligne de la DB n'a été ramenée. Le message 'overload rule applied' est là pour indiquer à l'utilisateur qu'il doit préciser sa requête.
La validation colorée
Le second remède est la validation implicite des données entrées par l'utilisateur en vue d'une interrogation du dictionnaire de données. Si la donnée est valable, le fond du champ de saisie passera au vert clair (clair pour que la couleur soit adoucie au maximum, et non charger l'interface de couleurs flashy ou autres choses du genre). Si la donnée n'est pas valable (disons plutôt insuffisante), alors la couleur de fond restera d'un rouge clair. La validation se fait chaque fois qu'une frappe au clavier a lieu.
Communication entre les éléments de l'interface
Les listes de résultats ne sont pas éditables, et pour remédier à ce problème mineur, l'utilisateur aura loisir de copier la ou les données qui l'intéressent vers le presse-papiers de Windows. Il pourra également transférer une donnée d'un panneau à l'autre pour faire un filtrage sur une autre table. Il faut en effet savoir que les trois tables sont reliées par une et une seule clé qu'on appelle dans le jargon interne 'structure de code'. Ce code identifie un ensemble de libellés, et grâce auquel une application peut charger une combobox pour que l'utilisateur puisse faire un choix parmi ces différents libellés.
Ergonomie
Toute application doit être entièrement pilotable au clavier. Pour moi, c'est une règle d'or car c'est la manière la plus efficace de travailler. La souris permet sans doute une certaine souplesse mais je la trouve limitée en ce sens qu'il faut qu'une main quitte le clavier, effectue une manoeuvre et clique sur un bouton, puis revenir sur le clavier. Il n'était donc par question que le CodoBrowser fasse exception à la règle. Et de fait, j'y suis parvenu sans difficulté. Le principal défaut de cette ergonomie est qu'elle a été conçue pour les droitiers (puisque je suis droitier). Tous les éléments de l'interface que j'ai voulus accessibles directement (c'est à dire le plus possible) le sont en appuyant sur la touche Alt suivie d'un caractère. Ces combinaisons de touches se font à une main si on emploie l'index et le pouce de la main gauche, le pouce pressant la touche Alt, et l'index pressant la touche de raccourci désirée.
Un dernier raffinement
Le dernier raffinement apporté à l'application est une petite icône, non visible sur les screenshots, qui indique si l'application est en communication avec le serveur. C'est assez superflu ici mais je l'emploie volontiers dans des applications dont les communications avec un serveur DB sont plus intensives.
Screenshots
13/01/2008: ayant quitté mon boulot actuel depuis fin 2007, l'évolution de ce projet est terminée.
Description
Le CodoBrowser est une application particulière, en ce sens qu'elle a été développée pour un contexte particulier, et pour un environnement particulier, celui d'une société pour laquelle je travaille régulièrement.Ils disposent sur place d'un dictionnaire de données multi-plateformes, qui est utilisé via des composants maison, par pratiquement toutes les applications développées par ou pour la société.
Le principal problème de ce dictionnaire de données est qu'il existe au travers de plusieurs environnements différents (disons par exemple un environnement de développement et un environnement de production) et qu'il n'est pas toujours évident de voir quelles données sont disponibles dans quel environnement.
Les plateformes disponibles sont DB2 sur mainframe, SQL Server sur un serveur Windows NT, et une dernière version Access 97, qui peut être disponible en local ou sur un serveur dit de référence. Le CodoBrowser est actuellement capable d'exploiter les ports Access et SQL Server de cette base de données. Je doute de pouvoir exploiter la version DB2, qui est celle dite de référence, je ne sais pas si un middleware est prévu dans leur environnement pour exploiter directement la base de données en question, car habituellement, ce sont des modules Cobol tournant sur mainframe qui s'occupent d'exploiter les différentes bases de données DB2 mises en oeuvre.
Interrogation des données
Le CodoBrowser se résume donc à un interrogateur de données, il exploite les structures propres à chaque environnement.Concrètement, il existe trois tables principales pour le dictionnaire de données et à chacune d'entre elles est consacrée une partie de l'interface. Chacun des panneaux de l'interface permet d'interroger une table selon le principe d'égalité ou du LIKE (SQL) en encodant une string, sur laquelle se basera la recherche. Pour l'exploitation du LIKE, il suffit simplement de placer des caractères génériques (%) et CodoBrowser fera le reste.
La règle d'overload
Le principal problème de ce programme, c'est qu'il ne peut pas se permettre de faire de lourdes requêtes sur la DB, du style ramener toute la table. En fait, ce n'est pas très gênant avec Access car la DB peut être locale, mais ça l'est beaucoup plus sur SQL Server. Pour résoudre ce problème, j'ai inventé le concept de l'overload rule, un mécanisme qui empêchera les grosses requêtes. Il est encore perfectible à ce stade.Attention à la lourdeur de l'interface
J'ai aussi voulu éviter les boîtes de dialogue intempestives, il n'y a rien de plus ennuyeux que de taper tout le temps la touche enter ou d'aller cliquer sur OK parce que vous avez commis une erreur. j'y ai donc apporté deux remèdes.Le rôle de la statusbar
Le premier est l'envoi de tous les messages d'information et d'erreur sur la barre de status, en faisant apparaître le message caractère par caractère, afin que l'utilisateur puisse se rendre compte qu'il s'est passé quelque chose. Par exemple, la règle d'overload a été appliquée, et donc, aucune ligne de la DB n'a été ramenée. Le message 'overload rule applied' est là pour indiquer à l'utilisateur qu'il doit préciser sa requête.La validation colorée
Le second remède est la validation implicite des données entrées par l'utilisateur en vue d'une interrogation du dictionnaire de données. Si la donnée est valable, le fond du champ de saisie passera au vert clair (clair pour que la couleur soit adoucie au maximum, et non charger l'interface de couleurs flashy ou autres choses du genre). Si la donnée n'est pas valable (disons plutôt insuffisante), alors la couleur de fond restera d'un rouge clair. La validation se fait chaque fois qu'une frappe au clavier a lieu.Communication entre les éléments de l'interface
Les listes de résultats ne sont pas éditables, et pour remédier à ce problème mineur, l'utilisateur aura loisir de copier la ou les données qui l'intéressent vers le presse-papiers de Windows. Il pourra également transférer une donnée d'un panneau à l'autre pour faire un filtrage sur une autre table. Il faut en effet savoir que les trois tables sont reliées par une et une seule clé qu'on appelle dans le jargon interne 'structure de code'. Ce code identifie un ensemble de libellés, et grâce auquel une application peut charger une combobox pour que l'utilisateur puisse faire un choix parmi ces différents libellés.Ergonomie
Toute application doit être entièrement pilotable au clavier. Pour moi, c'est une règle d'or car c'est la manière la plus efficace de travailler. La souris permet sans doute une certaine souplesse mais je la trouve limitée en ce sens qu'il faut qu'une main quitte le clavier, effectue une manoeuvre et clique sur un bouton, puis revenir sur le clavier. Il n'était donc par question que le CodoBrowser fasse exception à la règle. Et de fait, j'y suis parvenu sans difficulté. Le principal défaut de cette ergonomie est qu'elle a été conçue pour les droitiers (puisque je suis droitier). Tous les éléments de l'interface que j'ai voulus accessibles directement (c'est à dire le plus possible) le sont en appuyant sur la touche Alt suivie d'un caractère. Ces combinaisons de touches se font à une main si on emploie l'index et le pouce de la main gauche, le pouce pressant la touche Alt, et l'index pressant la touche de raccourci désirée.Un dernier raffinement
Le dernier raffinement apporté à l'application est une petite icône, non visible sur les screenshots, qui indique si l'application est en communication avec le serveur. C'est assez superflu ici mais je l'emploie volontiers dans des applications dont les communications avec un serveur DB sont plus intensives.Screenshots