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.
Tags: WebDev