Le projet open-source Betula est un framework multilingue (FR/EN) orienté objet pour les produits PC SOFT (WinDev, WebDev et WinDev Mobile).
Objectif du framework
Le framework est d’abord là pour faciliter la vie du programmeur en ne réinventant pas, à chaque projet, la même roue. De même, puisque faites une fois pour toute, les fonctions qui s’y trouvent peuvent atteindre un haut degré de complexité tout en restant simple lors de l’appel. L’objectif final est de diviser le temps de développement par 2 et d’augmenter la fiabilité du même facteur tout en offrant des fonctions inédites par la même occasion.
Dès son démarrage, en janvier 2018, il a été pensé pour devenir open-source. Sachant que plus de 50% des développeurs participent activement à des projets open-source, nous espérons qu’il attirera, autour de lui, une petite communauté de développeurs senior pour qu’il grandisse et devienne une référence (ici les modalités). L’open-source est également apprécié par les utilisateurs finaux/les clients puisque ça les assure une pérennité du noyau tout en bénéficiant des nouveautés et corrections.
Structure des classes du framework
Le framework se compose, pour l’instant, de 136 classes (+14 compatibles), chacune spécialisée. Les héritages sont peu nombreux, ce qui rend la compréhension rapide (un niveau avancé est quand même nécessaire).
Il est accompagné de 15 collections de procédures (une est illustrée ci-dessous), rassemblant 330 fonctions.
Afin d’avoir une compatibilité multi-plateforme, des contraintes liées au WLangage ont imposé au framework quelques tours de passe-passe dans le code. Entre-autres exemples : une classe ne peut hériter que d’une seule autre classe, des syntaxes de déclaration d’objet dynamique sont possibles pour certaines plateformes et pas d’autres, des constantes ne sont pas reconnues partout …
Concepts de la programmation orientée objet
Le framework est conçu, principalement, pour être utilisé en programmation orientée objet (POO). Pour ceux qui veulent commencer ou se perfectionner dans cette voie,
Dans le code d’initialisation du projet, 1 ligne pour initialiser la gestion des « plantages » et 2 lignes pour instancier la classe principale cApplication et récupérer une erreur le cas échéant. L’application est alors prête à fonctionner avec le framework.
d'utiliser une syntaxe simplifiée
Les classes présentes dans le framework utilisent des mots simples : Lit, Écrit, Recherche … Les outils PC SOFT sont choisis, entre-autre, pour leur syntaxe francophone. Dans le même esprit, toutes les méthodes sont en français pour éviter le « franglais » dans la programmation.
d'accéder aux données via les accès natifs ou l'ODBC
Faites tout d’abord deux classes par table manipulée : une héritée de cEnregistrement pour décrire un enregistrement (et son mapping et/ou ses balises de sérialisation) et une héritée de cSourceDeDonnées pour gérer les résultats multiples (p.e. suite à une requête). La seconde doit évidemment connaître la première puisqu’elle va mettre, en mémoire, un tableau de cEnregistrement.
Dans l’esprit de la programmation 3-tier, vos classes métier hériteront de ces classes de base cEnregistrement et cSourceDeDonnées .
Dans l’application :
Il faut tout d’abord créer la connexion à la base de données. Il suffit ici d’appeler la méthode Connecte() de la classe liée à la base de données manipulée (HFSQL local, HFSQL client/serveur, SQLServer, Oracle, SQLite, MySQL, PostgreSQL et LDAP/Active Directory). A noter qu’il n’est pas indispensable d’avoir une analyse dans le projet.
Instanciez ensuite des classes qui vont manipuler vos tables. Vous pouvez ensuite « binder » les classes de type « enregistrement » avec leur fenêtre « formulaire » et les classes de type « source de données » avec leur fenêtre « liste ».
Le framework propose 3 manières d’accéder aux données : soit grâce aux instructions Hxxxxx, soit via des requêtes SQL (une partie est gérées par le framework), soit via l’ODBC. Un seul paramètre à changer, le framework s’occupe du reste !
d'optimiser les accès réseau/base de données
Toute connexion ouverte sur un serveur, avec les instructions décrites au point précédent, est ouverte une seule fois. Tout le trafic des données passera par le canal ouvert, même si l’on déclare plusieurs fois la même connexion.
Lors de l’instanciation des classes qui accèdent aux données, il y a également des paramètres pour télécharger, ou pas, les mémos (binaires) au moment de la lecture de l’enregistrement et pour déclarer un répertoire « cache ». Grâce à ce dernier, le framework va utiliser, en priorité, les fichiers locaux, le trafic vers la base de données est donc réduit.
de gérer des 'mémos' en-dehors des tables
Quand on manipule des mémos nombreux et/ou de grande taille (ex : des photos), on peut avoir envie de les mettre hors de la base de données, tout simplement pour réduire les sauvegardes ou accélérer la récupération des données. Le framework permet ce paramétrage, en toute transparence, sur un répertoire local/réseau ou un serveur FTP.
de gérer les valeurs par défaut
Que ce soit dans les paramètres (ex : fichier ini) ou dans les classes cEnregistrement, des valeurs par défaut peuvent être facilement ajoutées.
Celles pour les paramètres de l’application peuvent ainsi « initialiser » un fichier INI créé au premier lancement. Si certains mots clés sont respectés, les connexions aux données est également facilité. La valeurs par défaut dans les cEnregistrement sont utiles pour être indépendantes des valeurs par défaut décrites dans la base de données et/ou quand aucune analyse n’est dans le projet. Une méthode RazDéfaut fait ce travail.
de gérer des logs et la trace
Les logs et les traces se ressemblent.
Les logs servent à historiser des passages, à des endroits précis, dans le logiciel ou a informer l’utilisateur et/ou le développeur de problèmes. Les logs se gèrent sur 4 niveaux : information, avertissement, erreur et aussi crash. Un 5eme niveau interne permet d’identifier les interactions de l’utilisateur avec les boites de dialogue (en loguant le message et la réponse de l’utilisateur) et les demandes d’impressions. Les logs s’enregistrent dans des fichiers texte et/ou une base de données et/ou sont envoyés par courriel. Les appels aux fonctions de log doivent être faits par le programmeur.
La trace, si elle est active, historise systématiquement tous les appels aux fonctions du framework avec leurs paramètres. On peut facilement suivre ce qui se passe à l’intérieur puisque chaque écriture de trace s’accompagne du nom de l’utilisateur, de la date et heure et de la pile d’appels à la fonction tracée. Indispensable en cours de développement mais aussi pour identifier un problème une fois l’application installée.
Un mécanisme existe pour protéger les mots de passe (dans le log et la trace).
de modifier/corriger des fonctions standard du WLangage
Certaines fonctions du WLangage ont des comportements différents selon la plateforme sur laquelle elles sont exécutées. Pour éviter des erreurs de compilation dans le framework, certaines fonctions sont mises dans du code-cible.
D’autres fonctions ne réagissent pas « comme attendu » à tel point qu’un contact est fait avec le support technique de PCSOFT. Mais force est de constater qu’il n’y a aucune garantie sur le délai de réponse de la part de l’éditeur. Voila pourquoi certains fonctions ont été refaites. Certes, elles sont plus lentes mais surtout plus efficaces. Aussi, si vous souhaitez les adapter, le code est là ! D’autres, qu’on peut considérer comme « manquantes », ont été ajoutées (exemples : DateHeureSys() n’existe pas pour Windows Mobile, SansEspace ne permet pas d’options en Mobile, Java et PHP).
d'avoir accès à des constantes (API, couleurs web, ...)
Certaines classes ont besoin de constantes pour fonctionner, d’autres sont ajoutées pour le confort. Ce sont donc des centaines de constantes qui sont accessibles.
Contexte légal
La licence choisie pour Betula est LGPL (Licence publique générale GNU amoindrie) qui n’oblige pas à ce que le logiciel qui utilisera ce framework soit aussi open-source. De ce fait, Betula peut être intégré, sans contrainte, dans un produit commercial ou un logiciel interne d’entreprise.
Garantie
Malgré toute l’expérience cumulée de l’équipe originale et de tous les autres contributeurs, malgré l’attention à coder et à tester correctement, nous savons tous que des erreurs peuvent se dissimuler dans un tel projet. De même, nous ne sommes pas à l’abri d’un problème dans les éditeurs eux-mêmes.
De ce fait, tant l’équipe originale que tous les contributeurs à ce projet déclinent toute responsabilité sur le fonctionnement du framework quel que soit la situation dans laquelle il est utilisé.
En pratique
Betula est livré complètement anonymisé (le seul « programmeur » visible est Betula) et en Unicode. Tous les projets qui l’utilisent doivent donc être paramétrés en Unicode.
Tous les messages et libellés sont traduits en 4 langues : Français (code Nation 5), Anglais (code Nation 3), Canadien Français (code Nation 9) et Américain (code Nation 2).
Code source
Pour chaque release, l’ensemble des sources sera disponible sous format ZIP (voir ci-dessous).
Composant
Pour ceux qui ne veulent pas « mettre les mains dans le cambouis » ou qui veulent « figer » le framework pour assurer sa stabilité, un composant externe sera proposé pour chaque release de Betula (voir ci-dessous). Pour rappel, les composants externes sont utilisables en WinDev et WebDev mais pas en WinDev mobile.
Ce framework se comportera alors comme une « boite noire ». Raison supplémentaire de parfaitement tester et documenter toutes les fonctions (voir ci-dessous).
Version
Betula a été développé, initialement, en WD23 afin de profiter des dernières évolutions de l’outil, notamment pour la POO. Chaque programmeur est libre de passer le framework à une autre version Wx mais, à nouveau, sans garantie de son bon fonctionnement dans ladite version.
Cliquez ici pour téléchargez l’ensemble des sources ou le composant
Parcourez le menu « Framework Betula » / « Documentation » pour en savoir plus
Cliquez ici pour télécharger un exemple d’utilisation du framework dans un modèle commande / détail / client / produit.
Un forum de discussion est à votre disposition pour poser des questions, proposer des idées, discuter de concepts, suggérer des modifications et corrections …
Pour ceux qui veulent participer, merci de respecter quelques règles et recommandations pour faciliter l’intégration de votre code dans la version de référence. Cette page contient aussi quelques pistes d’évolution et une section du forum vous permet d’en proposer d’autres.
Statut du framework
Le framework, qui fait presque 30.000 lignes de code, est encore en cours de développement et de debugging.
Le framework est présentement en cours de documentation et est déjà utilisé dans plusieurs projets, permettant de tester ses limites :
Logiciels divers de gestion (Windows/service Windows/webservice, SQLServer via Accès Natif,active directory, en production)
Logiciel de gestion d’employés (Windows, SQLServer via ODBC, en production)
Logiciel de gestion de flux XML (Windows, SQLServer via Accès natif, en développement)
Logiciel de gestion clientèle (Java/MariaDB/mémo par ftp, en développement)
Logiciel de gestion de stock (Android/SQLite) utilisant un webservice (service Windows, HyperFile+SQLServer, développé autour de la classe cHTTPServer du framework, en test)
