Jointure sur des bases de données différentes avec WebDev 16: encore une déception !

Dans la cas d’une application multibase, on peut être amené à aggréger des données en provenance de bases différentes. La sélection peut s’opérer en 2 étapes: rapatrier les données de chaques bases puis les aggréger en mémoires. Si l’aggrégation consiste à faire une jointure on préfèrerait que cela se fasse dans la “base”.

En J2EE, le développeur ferait appel à des EJB puis avec un EQL ferait la sélection interbase. Il s’appuirait ainsi sur des mécanismes de chargement paresseux afin limiter l’occupation mémoire en évitant de charger la base en mémoire! Comment webdev adresse-t-il se problème ?

Prenons un cas concrêt de 2 requêtes paramêtrées, chacune mettant en jeu des tables sur des bases de données différentes. Le test SQL de chacune de ces 2 requêtes dans l’IDE se fait sans encombre puisque aucune ne fait pas intervenir l’autre. Créons une 3e requêtes qui fait une produit cartésien sur les 2 premières. Cette 3e requête est elle-même paramêtrée afin d’assurer la jointure. Et bien le test SQL de la 3e requête dans l’IDE se passe parfaitement !

Cela donne l’illusion au développeur de pouvoir utiliser la 3e requêtes comme source pour un tableau. Que nenni ! On a droit à une belle explosion, webdev se plaigant que le fichier (table) correspondant à la 3e requête n’existe pas. Dommage que l’IDE laisse au développeur espérer une opération magique qui n’existe pas !

La solution consiste à remplir le tableau manuellement avec le résultat de l’appel à des requêtes SQL manuelles. Il faut déclarer une source de données pour chacune des requêtes et executer le SQL associé sur chacune d’elle (HExecuteEquêteSQL). Ensuite il faut faire de même avec une nouvelle source de données et un requête SQL faisant un produit cartésien sur les 2 premières sources de données.

Finalement on arrive a nos fin mais au prix d’un effort de programmation non négligeable et une rupture dans les concepts: le médecin doit abandonner le confort de la manipulation d’objet dans l’IDE (requêtes) pour écrire du SQL dans une chaine de caratères non validée par l’IDE. Quel dommage !

Webdev 16 de déception en déception

Voulant partager du code entre plusieurs projet, l’idée naturelle est de mettre ce code dans des bibliothèques dont va dépendre les projets. En java cette dépendance peut être définie par Maven qui gère le cycle de build. Avec Windev on est loin d’une solution industrielle….

Tout d’abord le simple partage de code via le centre de réutilisabilité revient ni plus ni moins à partager les sources sur un disque réseau sans versionnage aucun des pseudo-bibliothèque obtenue. Chaque projet doit alors faire un copier-coller des sources. C’est vraiment pauvre !

Il existe néanmoins un notion plus intéressante en WebDev qui gère le versionnage: le composant. Avec des composants, les projets sont mis à jour automatiquement quand une nouvelle version est disponible pour peu que le composant indique sa compatibilité. Cela se rapproche de la gestion des dépendances de Maven et de son système de dépôt, grâce à la mise en ligne du composant dans le Gestionnaire De Sources (GDS) de WebDev (son SCM propriétaire).

Malheueusement la notion de composant impose des limites. Un composant doit être vu comme un boîte offrant un service de bout en bout à l’application utilisatrice. Il peut fournir des procédures, des pages etc mais le composant ne peut accéder aux objets de l’application utilisatrice. Le terme objet est volontairement flou car c’est là que les ennuis commencent. Le WLangage ne pousse pas à faire de l’objet et toutes les fonctions du WLangage sont globales (ex: HChangeConnexion). Malheureusement ce paragdigme est vraiment insuffisant pour expliquer clairement la magie qui s’opère à l’execution. Ainsi selon que la fonction WLangage est appelée dans le composant ou pas, son résultat est différent. Par exemple un composant ne peut être utilisé pour effectuer un changement des connexions de l’application utilisatrice, car HChangeConnexion echoue silencieusement (comble de l’horreur…là où Java léverait une exception) si appelée depuis le composant.

Du coup il est impossible d’initialiser les connexions de l’application comme indiqué dans ce billet et il faudra mettre le code dans l’application même. Dommage, cela calme les ardeurs du concepteur qui cherche à faire du code réutilisable et classe définitivement WebDev hors-jeu pour le développement professionnel.

WebDev 16 vs J2EE : connexion aux sources de données par programmation

On a vu précédemment que la gestion des sources de données se devait d’être faite manuellement dans un contexte d’entreprise. En effet l’utilisation de telle ou telle base de donnée doit être configurée dans l’environnement, sur site, et non pas dans l’AGL. Cette article résume la marche à suive pour rendre une application Webdev 16 réellement professionnelle.

En premier lieu, puisque l’AGL ne le propose pas, on créera un mini-socle technique. Ce sera un projet webdev de type “composant”. Il pourra contenir des pages, des bibliothèques de procédures, des classes etc.

Le socle technique devra tout d’abord rechercher le fichier de configuration qui permettra de paramétrer l’application. On créera donc dans le projet socle, une bibliothèque de procédures que l’on nommera Initialisations. Dans cette bibliothèques on créera une procédure que l’on appellera ChercheFichierInit dont le rôle sera de trouver le fichier de configuration afin que le reste de l’initialisation puisse se faire.


PROCEDURE ChercheFichierInit(LOCAL sNomFichierConfig est une chane = "config.ini", LOCAL sNomRepConfig est une chane = "config")

// recherche du fichier de configuration

// recherche dans le rpertoire de config du rpertoire donnes de l’application
gsRepertoireConf = fRepDonnes()
//Info(“Rep de donne”, gsRepertoireConf)
gsFichierConf = ComplteRep(ComplteRep(gsRepertoireConf) + sNomRepConfig) + sNomFichierConfig
//Info(“Recherche fichier conf “, gsFichierConf)
SI fFichierExiste(gsFichierConf) = Faux ALORS

// on monte 2 fois car le composant est install dans un sous rpertoire le rpertoire web de l’application utilisatrice
gsRepertoireConf = fRepParent(fRepParent(fRepWeb()))
// Info(“Rep du site”, gsRepertoireConf)
// fichier de config spcifique l’environnement (ex: production)
gsFichierConf = ComplteRep(ComplteRep(gsRepertoireConf) + sNomRepConfig) + sNomFichierConfig
// Info(“Recherche fichier conf “, gsFichierConf)
SI fFichierExiste(gsFichierConf) = Faux ALORS
// fichier de config par dfaut (ex: en developpement)
gsFichierConf = ComplteRep(gsRepertoireConf) + sNomFichierConfig
// Info(“Recherche fichier conf “, gsFichierConf)
FIN

FIN

RENVOYER gsFichierConf

Une fois que le fichier de configuration a été déterminé on peut s’occuper de connecter les tables (appelées Fichier dans la terminologie WLangage) de l’analyse à la bonne base de données.


PROCEDURE InitConfigurationBase(sListeFichierAnalyse est une chane)
logInfo("Chargement de la configuration des connexions aux bases de donnes...")
SI fFichierExiste(gsFichierConf) ALORS

logInfo(“Lecture des paramtre d’initialisation de la base de l’application”)
gsUtilisateur_app = INILit(gsCFG_SECTION_BD_APPLI,gsCFG_SECTION_BD_APPLI_KEY_USER,””,gsFichierConf)
gsMotdepasse_app = INILit(gsCFG_SECTION_BD_APPLI,gsCFG_SECTION_BD_APPLI_KEY_MDP,””,gsFichierConf)
gsSource_app = INILit(gsCFG_SECTION_BD_APPLI,gsCFG_SECTION_BD_APPLI_KEY_SOURCE,””,gsFichierConf)
gsServeur_app= INILit(gsCFG_SECTION_BD_APPLI,gsCFG_SECTION_BD_APPLI_KEY_SERVEUR,””,gsFichierConf)
logInfo(“source serveur : ” + gsServeur_app + CRLF + “source base: ” + gsSource_app + CRLF + “utilisateur: ” + gsUtilisateur_app + CRLF + “mot de passe : ******”)

// changer les connexions des FICHIER de la base de l’application
// Description de la connexion

gConnexionManuelleAppli..Utilisateur = gsUtilisateur_app
gConnexionManuelleAppli..MotDePasse = gsMotdepasse_app
gConnexionManuelleAppli..Serveur = gsServeur_app
gConnexionManuelleAppli..BaseDeDonnes = gsSource_app
gConnexionManuelleAppli..Provider = hAccsHFClientServeur
gConnexionManuelleAppli..Accs = hOLectureEcriture

gbCOnnexionManuelleAppliOuverte = False
logInfo(“Ouverture de la connexion la base de l’application…”)
SI HOuvreConnexion(gConnexionManuelleAppli) ALORS
logInfo(“OK Connexion ouverte ! “)
gbCOnnexionManuelleAppliOuverte = True

logInfo(“Modification des connexion des tables propres l’application”)
ListeFichierAnalyse = sListeFichierAnalyse
ChangeConnexionApplication(ListeFichierAnalyse)

logInfo(“Fin du traitements des tables applicatives”)
SINON
logFatal(“Erreur lors de l’ouverture de la connexion à la base applicative” + CRLF + HErreurInfo())
Erreur(“Erreur lors de l’ouverture de la connexion à la base applicative”,HErreurInfo())
FIN
SINON
logFatal(“Le fichier de configuration ” + gsFichierConf + ” est introuvable”)
Erreur(“Impossible d’initialiser la configuration de base de donnes, Le fichier de configuration ” + gsFichierConf + ” est introuvable”)
FIN

 

La liste des fichiers de l’analyse de l’application utilisatrice de notre composant ne peut être déterminé par le composant lui-même. En effet la fonction HListeFichier() appelée depuis le composant, retourne les fichiers de l’analyse du composant. C’est donc à l’application d’appeler cette fonction et de passer la liste des fichiers dont il faut changer la connexion. Voici la procédure qui change la connexion:


PROCEDURE PRIVE ChangeConnexionApplication(ListeFichierAnalyse)

POUR TOUT CHAINE fichier_analyse DE ListeFichierAnalyse SEPAREE PAR RC

HChangeConnexion (fichier_analyse,gConnexionManuelleAppli)
SI ErreurDtecte ALORS
Erreur(“Erreur lors de l’attachement de la table : ” + fichier_analyse,HErreurInfo())
SINON
logInfo(fichier_analyse + ” attache ” + gsSource_app + ” sur ” + gsServeur_app)
FIN

FIN

 

Dans le code de l’initialisation serveur du projet de l’application cliente il suffit de mettre ces lignes:


Intialisations.ChercheFichierInit()
Initialisations.InitConfigurationBase(HListeFichier())

NB: Le lecture corrigera de lui même les références à des variables nom déclarées telles que les constantes des clés utilisées dans le fichier d’initialisation.

NB: les fonctions LogInfo(), LogFatal() utilisées dans le code sont des fonctions personnelles afin de palier le manque de niveau de log dans WebDev, et feront éventuellement l’objet d’un billet ultérieur.

Comparaison WebDev 16 et J2EE : session web

En J2EE le mécanisme des Servlets est entièrement documenté. Une servlet est instanciée pour servir les requêtes des clients. Chaque execution (traitement) peut obtenir la session à laquelle il appartient en invoquant peu ou prou un getSession sur la requête courante. Cet objet de session peut servir à accueillir des objets que l’on souhaite rattacher à la session courante comme, par exemple, des informations à passer de page en page.

Le modèle de programmation de WebDev est de son côté peu documenté mais de façon empirique on arrive à la conclusion suivante: dans les pages dynamiques webdev, les objets globaux au projet sont en fait des objets de sessions.. Du moins en développement car une particularité troublante est que la gestion des sessions est différente dans l’AGL de sa gestion dans le vrai serveur WebDev. Cela est regrettable car un code qui fonctionne sur le poste du développeur risque de ne pas fonctionner en intégration… D’autant plus que la gestion des sessions peut devenir critique mais utilise-t-on WebDev pour des applications critiques ?

Webdev 16 vs J2EE : log applicative

Les applications écrites en Java adressent des problématiques techniques complexes notement en terme d’architecture et les développeurs (terme noble) de monde Java se sont attachés à répondre au besoin d’outillage suscité par ces développements. Ce besoin n’est pas spécifique à Java mais il est présent dès lors que les applications le nécessitent.

Parmi les outils, l’un des plus triviaux est un mécanisme de log. Ainsi avant le JDK1.4, les librairies tierces telles que Log4j ont permi aux applications de disposer d’une fonction de log modulaire par composants (domaine métier, domaine technique etc) et par niveau de sévérité (log d’information, de debug ou d’erreur etc). Cette solution , pour ne citer qu’elle, est bien sûr libre (et gratuite).

Que nous propose Webdev de son côté ? Il existe une fonction de trace (Trace) qui affiche des log dans une popup… Surtout pratique en développement et s’apparente plus à un vulgaire System.out.println qui est le niveau zéro de la log puisque non paramétrable et ni débrayable tel quel en production.

Une recherche rapide sur google dans le monde Java donne tout de suite une réponse aux problématiques de log en Java alors que la même recherche pour WebDev n’amène aucune réponse du même niveau. Comme d’habitude (cf la gestion des sources de donnéées) il faudra se créer des fonctions qui géreront le niveau de log et l’écriture de la trace dans un fichier. la fonction Trace sait écrire dans un fichier mais il nous faudra ajouter l’horodatage nous même…

Comparaison WebDev et J2EE : langage et gestion des sources de données

Le monde J2EE est souvent jugé complexe mais cette complexité apparente n’est que la réponse nécessaire aux problématiques réelles des SI. De son côté WebDev propose une solution aguicheuse pour le développement mais tient-il la comparaison ?

Dans un billet précédents je déclarais que la cible de WebDev n’était pas la même que J2EE. WebDev semble s’adresser à une population d’informatiien et surtout de non informaticien pour développer des applications de gestion CRAD (portemanteau de CDRUD et de RAD). Après quelques semaines passé à manipuler WebDev voici mes conclusions.

Du point de vue du développeur (rôle développeur en J2EE), le langage WLangage n’est pas Objet. On est trop souvent amené à appeler des fonctions qui ne sont pas des méthodes d’objet ni de classe. Ce sont bel et bien des fonctions. Le paradigme de programmation du WLangage (langage propriétaire utilisé par WebDev) est donc bancal. Se voulant objet, puisque l’on peu faire des objets, il n’impose malheusement pas ce modèle. Si le lecteur doute de la pertinence de l’objet en matière de génie logiciel, je ne peux que lui conseiller de mettre à jour ses connaissances.

Certaines fonctions sont elles-mêmes bancales dans leur signature. Ainsi le fonction qui test si une chaine commence par une autre est bien nommée ChaîneCommencePar mais ne retourne pas un booléen mais un entier…. Donc le développeur passe d’un niveau d’abstration fonctionnel avec des fonction dont le nom est significatif à un autre, celui d’un test en langage C….

Une fois l’application développé vient le temps du déploiement. Comme on veut comparer WebDev et J2EE, nous sommes dans le contexte d’un SI d’entreprise voire d’un éditeur, avec des environnements de test, de preé-production et de production. Là où J2EE permet de découpler le code de l’application des paramètres de l’environnement comme les sources de données qui sont du ressort de l’administrateur (rôle déployeur en J2EE). Ainsi le mème livrable pourra être déployé en test ou en production, le code étant totalement agnostique de l’environnement, Quelle solution propose WebDev ?

La notion de connexion nommée est interne à l’IDE qui confond allègrement nom de connexion et nom de variable dans le but de simplification à outrance. Ainsi une connexion définie dans l’IDE est référencé par son nom en tant que variable et nom pas en temps que chaine. Les connexions semblent devoir être définies lors du développement. WebDev inscite donc à repasser par l’AGL et déclarer les connexions spécifiques à l’environnement cibles puis recompiler et redéployer l’application. Une fois dployée l’application est alors scotchée à sa source de donnée…. WebDev ne fait donc pas de découplage entre application et source de données!

Néanmoins on peut par programmation construire une connexion et l’affecter aux tables (appelées Fichiers) du programme. Cette méthode est celle préconisée par le support pour rendre l’application multi-cible. Finalement c’est un développeur si il a un minimum de compétence en génie logiciel, de prévoir ce qui est du ressort de la technique et donc contraire à la cible première de WebDev. Par ailleur le support propose une solution hasardeuse de détecter l’environnement en fonction de l’IP du serveur… sous-entendant que le code doit tester si il est en test ou en prod. WebDev est donc a proscrire pour les éditeurs qui devraient connaitre l’IP de tous les serveurs de ses clients!

Une première solution pourtant existe et aurait dû être proposée par le support. Lors du déploiement l’AGL propose d’inclure des fichiers supplémentaires. Il suffit d’ajouter un fichier de type INI qui contient la définition de la connexion pour l’instance en train d’être déployée. Par programmation, l’application lors de son initialisation va lire ce fichier et créer la connexion puis surcharger la connexion de l’analyse. Cependant, cette méthode oblige toute modification des sources de données de se faire soit en redéployant soit en allant modifier le fichier INI sur le serveur. On peut aller plus loin en incluant un fichier (Table) d’initialisation qui contiendrait les valeurs de connexions aux tables métiers et un module d’administration pour modifier la table de paramétrage… Dommage que WebDev ne propose pas cela dans son modèle, ce qui lui aurait permis de soutenir la comparaison avec J2EE.

Derrière un marketing singulier dans le monde des éditeurs, WebDev est un AGL qui ressemble plus à une boîte à outils pour assembler rapidement des applications focalisées sur l’apparence. Certes, on développe vite des IHM mais le modèle applicatif n’est pas celui attendu par des SI d’entrepise et encore moins celui de professionnelles de l’informatique comme les éditeurs. Définitivement, a moins de s’adjoindre les services d’un spécialiste en architecture ou génie logiciel, l’utilisation de WebDev n’est pas adaptée à un SI d’entreprise avec des contraintes autres que celles du médecin qui veut développer un IHM sur son fichier de patients.

Accès Oracle natif avec WebDev

L.’AGL WebDev propose moyennant finance d’accéder nativement à une base Oracle. On entend par nativement le fait de na pas passer par ODBC ou OLE DB. L’application WebDev se connecte directement à Oracle.

Outre le gain de performence dû à l’absence de couche intermédiaire, PCSOFT indique que par l’utilisation de l’accès natif, le code de l’application ne nécessite pas de changement en cas de changement pour un autre base de donnée. Cela est étrange car d’un point de vue conceptuel, c’est justement interface commune indépendante de l’implémentation qui permet de ne pas changer le code utilisateur quand on change l’implémentation. En réalité l’interface commune semble être le WLangage et le RAD. Dans d’autres univers cette interface commune s’appelle par exemple JDBC… et le fournisseur de l’implémentation de l’interface c’est le fournisseur de la base de données.

Quoi qu’il en soit, PCSOFT vend un connecteur natif Oracle. L’installation du contenu du cdrom contenu dans la boîte jaune se fait sans encombre et WebDev propose ensuite le type de connexion Accès Natif Oracle pour WebDev dans le paramétrage des connexions.

Comme l’architecture est étrange pour ne pas dire antipattern puisque Oraccle ne fournit pas de driver pour la couche d’abstraction (inexistante car API propriétaire) de WebDev obligeant PCSOFT à fournir (vendre) un connecteur, l’installation de la boîte jaune ne suffit pas.

En effet la documentation indique que l’installation de la couche cliente Oracle est nécessaire. Pour cela il faut aller sur le site web d’Oracle pour télécharger Instant Client. La version Basic est suffisante. Il s’agit d’une archive dont l’installation consiste à rendre accessible les librairies qu’elle contient pour tout le système. Sous Windows, il faut alors mettre à jour la variable PATH.

Pour créer une connexion il faut ouvrir l’éditeur d’analyse puis aller dans le menu Analyse > Connexions …. Cliquer sur le bouton + pour ajouter une connexion. Dans l’onglet propriété voici les champs à remplir:

  • Nom : le nom qui sera utilisé comme variable dans le code WLangage
  • Connexion pas : choisir Accès natif Oracle pour WebDev
  • Source de donnée : c’est l’url de connexion de la forme serveur:port/base où le port peut être omis si c’est celui par défaut 1521

Retour d’expérience sur WebDev 16

WedDev se présente comme un RAD professionnel permettant de développer 10 fois plus vite. Le marketing est très aguicheur mais que se cache-t-il vraiment derrière ? Une première réponse est apportée par ce billet que nous allons complété avec des exemples précis qui aideront le lecteur dans son choix (ou sûrement son non choix).

  • plantage de l’éditeur
  • droit avec le groupware ne marche pas sur tous les champs
  • la fonction de création automatique des tables ne marche pas toujours
  • mémoire insuffisante pour compiler un petit projet
  • plantage du centre de contrôle HyperFileSQL
  • HyperFileSQL est privateur de liberté

Plantage de l’IDE

Le problème se rencontre dès le début de l’utilisation du manuel d’auto-formation. L’éditeur propose la complétion et l’aide à la saisie des paramètre de procédures. Lors de la saisie dans l’éditeur de la procédure milieu, une saisie des paramètres provoque un crash de l’IDE. Nous avons reporté ce bug reproductible sur plusieurs machines auprès du support de PCSoft.

D’autre cas de plantage sont survenus au fil de l’utilisation dans d’autres parties de l’AGL, provoquant un crash de WebDev.

Limitation du groupeware

Alors que le manuel et la documentation en ligne indiquent que les champs des pages peuvent être limités à certains groupes d’utilisateurs du groupeware,  malheureusement après de nombreux essais, nous nous apercevons que cela ne fonctionne pas sur tous les champs mais seulement sur le menu, les boutons et les images ! Le support, réactif, nous à alors indiqué que l’aide en ligne allait être mise à jour. Cela illustre l’adage it is not a bug it is a feature

Un contournement est toutefois possible. Il suffit de modifier pour chaque page les propriétés des champs ou groupe de champs en fonction du groupe de l’utilisateur connecté.

Fonctionnement capricieux de la création automatique

Quand on utilise HyperFileSQL, on est étonné de ne pas trouver comment générer le script de création de la base. En effet de nombreux dialectes de SQL sont supportés mais pas celui de HyperFileSQL. Notons que l’utilisation du SQL standard ANSI 92 n’a pas fonctionné dans mon cas à cause d’une rubrique (colonne) de type BIT…

En fait il ne faut pas chercher à générer de script de création de table pour HyperfileSQL. Dans les propriétés du projet l’option de génération des fichiers (tables) au premier accès est activé par défaut. Donc lors du déroulement du programme (navigation sur le site web) les fichiers sont créés au besoin. Cette fonctionnalité ne marche pas toujours. D’un coup plus aucune table n’était créée.

La solution consiste à générer manuellement par WLangage le schéma de la base en début d’application.

Gourmandise mémoire

WebDev est occupe 2 Go sur le disque et l’IDE est un gros consommateur de mémoire vivre. Ainsi sur un poste disposant de 4 Go de ram, la compilation d’un projet de 10 tables et 40 écrans a échoué sur le message mémoire insuffisante.

Contraintes de HyperFileSQL

La base de données propriétaires de WebDev est présentée comme gratuite et installable partout. De plus un accès ODBC est disponible pour les applications tierces i.e. non WebDev. Cette offre est séduisante mais que vaut-elle réellement ?

Si la base est gratuite elle n’est pas au sens de la FSF un application libre. L’éditeur ne propose pas de façon libre l’accès au pilote ODBC. Ce dernier est installable si on installe l’AGL ou déploie une application WinDev mais il n’est pas téléchargeable séparément sans passer par l’achat d’une licence webdev. Finalement la base HyperfileSQL doit n’être vue que comme un moyen de persistance maison redistribuable sans royalties dans les applications développées par l’AGL. De plus l’accès ODBC est uniquement en lecture pour les applications non windev selon le support technique. Ainsi ne comptez pas brancher un ETL sur une base HyperfileSQL en écriture par exemple….

WebDev pour un développement rapide mais pour qui ?

L’outil WebDev édité par PCSOFT est un atelier de développement pour la création de site web dynamique. S’inspirant du principe RAD il permet de faire des pages web de façon visuelle et de partir de la base de données pour créer automatiquement ou presque les pages en accès CRUD. Le langage propriétaire, WLangage, est en français et facile d’accès car d’abord procédural et objet optionnellement.

La prise en main de l’outil est vraiment aisée. La facilité et la rapidité des créations d’un site en CRUD avec le RAD est bluffante. Toutefois toute belle fille ne peut donner plus qu’elle n’a. Si Webdev permet de baisser drastiquement la barrière de compétence pour développer, quelles sont les limites informatiques dans l’architecture du SI quand on mise ses développements sur Webdev ou tout outil équivalent ?

En premier lieu le choix de Webdev est judicieux pour permettre une population ancienne technologie d’accéder, sans montée en compétence, à des technologies nouvelles. La terminologie utilisée par Webdev sent bon l’ancien temps avec la notion de fichier ou de rubrique pour les tables et les colonnes. Le langage possède même une instruction GOTO ! En même temps l’outil propose sur simple clic d’accéder à des techniques dans l’air du temps: Ajax, Webservice… Cette dualité ouvre la porte au plus grand nombre aux dernières innovations sexy de l’informatique et cela dès la lecture d’une publicité commerciale ou du manuel utilisateur de Webdev…

Malheureusement la forme n’est pas tout et les organisations ont des besoins différents. Webdev est-il le graal ? La réponse est évidement non. Un raisonnement par l’absurde suffit à nous convaincre. L’échec des projets de développement informatique ne se conjurent pas par l’utilisation des AGL et le succès des projets utilisant des technologies non RAD dans les secteurs concurrentiels (banque, e-commerce…) montre la pertinence de ces choix technologiques.

Les secteurs où la technique relève d’un critère concurrentiel ne peuvent se permettre d’attendre la prochaine version de l’AGL pour offrir la dernière technologie à la mode à ces clients. L’accélération du monde fait que le “time to market” est parfois vital. Une bonne idée ce n’est pas suffisant, il faut la mettre en œuvre avant les autres.

Le modèle des appliccations WebDev promeut un développement CRAD (mélange de RAD et de CRUD). En effet la rapidité de développement pousse à la paresse conceptuelle. La conception consiste à modéliser (et faire apparaître) des objets artificiels qui ne sont ni issus du métier ni même technologiques (je n’utilise pas le terme technique pour bien préciser ma pensée). Cette tâche de conception nécessite de vrai compétence informatique que le public visé par Webdev n’a pas. L’approche RAD se focalise sur l’analyse qui n’est n’y plus ni moins qu’un modèle meurisien orienté données. La tentation est alors grande de se laisser enfermer dans l’outil et de ne pas passer par la case conception logicielle. La préjudice ne se voit pas si la logique métier est peu présente dans l’application;.. Mais on fait alors l’impasse sur l’évolutivité, la scalabilité et donc la pérénité de l’application.

Les organisations ayant une SI de grande ampleur où l’interconnexion des systèmes occupe une place importante ne peut se contenter du modèle applicatif proposer par WedDev. En effet la notion de réutilisation semble re dans WebDev qu’un partage de bibliothèques qui nécessiteront un “redéploiement” (livraison) de toutes les applications qui les utilisent. Pourtant des technologies datant de la fin des années 90 adressent ces problématiques comme les EJB ou plus anciennement les ORB Corba.

Si on replace dans l’utilisation de l’outil, la présentation du code est bien pensée en regroupant sur un écran les codes de différentes natures qui concourent au fonctionnement d’une page ou d’un bouton. Dommage que des bugs mineurs tels que le crash de l’IDE quand l’assistant de saisie présente les paramètres de la procédure Milieu() utilisée dans le premier exemple de l’auto-formation (Ce bug est répétable sur plusieurs machines de mon organisation, peut-être un problème de master spécifique). Ce n’est toutefois pas très gênant.

Pour conclure ce billet auquel d’autres succéderont au fil de mon utilisation de WebDev, je dirais qu’il faut prendre cet AGL pour ce qu’il est: un moyen de développer rapidement sans prétention. Il faut donc savoir faire le deuil de toute agilité du SI et pour cela bien analyser la typologie de son SI.