Moderniser avec EGL

et à mesure que vous modernisez, vous vous préparez à l’environnement de gestion contemporain. EGL est un langage procédural qui ne vous demande pas d’apprendre la programmation orientée objet. En coulisse, EGL génère votre application en Cobol ou Java, mais le langage EGL lui-même est beaucoup plus simple que Cobol, Java ou RPG. RBDe et EGL vous concentrent sur le développement des applications de gestion et offrent des structures SOA faciles d’emploi et une orientation naturelle vers une UI de type navigateur. Il ne s’agit pas du langage idéal, mais simplement de celui idoine pour le job, avec un outillage complémentaire pour accélérer la chose.

J’admets mon expérience limitée (j’écrirai davantage sur EGL quand j’en aurai plus), mais je propose déjà quelques observations, positives et négatives :

• Le wizard database import de RBDe crée environ 90 % de la logique d’accès base de données présente dans une application classique. Il vous incombe de le régler finement et d’optimiser sa performance. Au début du cycle de développement, vous consacrerez le plus gros de votre temps à affiner les éditions sur les éléments de données (essentiellement les champs dans un fichier de références de champs) pour accélérer le développement de l’interface utilisateur.

• La facilité de construction de l’interface utilisateur est, à mon avis, sans égale. Peupler une page Web de composantes JSF avec des données de gestion complexes se fait normalement par glisser/déposer. Vous règlerez finement cela avec CSS et avec JavaScript (ou Ajax si vous préférez), mais RBDe/EGL ramène la complexité du développement de page et de site de 10 à 6 (sur une échelle de 1 à 10).

• Tout ce que j’ai tenté de faire en RBDe/EGL pour la première fois m’a pris plus de temps que prévu. Je ne sais pas si je dois incriminer mon lourd passé en programmation orientée objet, ou des déficiences de l’outillage. Je suis désarçonné par les étapes de développement contre-intuitives. Par exemple, l’import base de données génère initialement du code marqué « in error » par le compilateur. Il faut cliquer sur le projet et régénérer le code pour éliminer les erreurs. Aurait-il été si difficile pour le créateur de l’outil d’initier la régénération du projet après l’import ? A tout le moins, il aurait pu faire surgir une boîte de dialogue indiquant la nécessité de cette étape. Il y a beaucoup d’autres bizarreries dans ce genre qui vous lancent sur des pistes incertaines jusqu’à ce que la solution simple, mais pas évidente, vous saute aux yeux.

• Il y a très peu d’information à partir de la source la plus précieuse de tout programmeur : Internet. Parce qu’il n’y a pas encore assez d’utilisateurs d’EGL sur le System i. Si vous tapez « EGL » sur Google, vous trouverez que le site le plus connu est le European Gemological Laboratory. Le site IBM developerWorks est l’un des seuls sites pertinents que j’aie trouvés.

Une fois les nuances de l’outillage apprises, vous éviterez les écueils quand il faudra répéter une tâche particulière. Certes, il faut toujours s’attendre à quelques obstacles quand on apprend un langage ou un outil de programmation. Mais IBM a vraiment besoin de régler les anomalies de RBDe pour que cet outil tienne pleinement sa promesse. Le potentiel de RBDe/EGL dans les sites System i est énorme. Malgré ses imperfections, les avantages d’EGL l’emportent largement sur les inconvénients et, vu de ma position, ce produit mérite plus qu’un coup d’œil distrait de la part de tout site en voie de modernisation.

Une dernière réflexion : certaines des composantes essentielles de mon projet EGL actuel sont des classes Java. EGL fournit des structures qui facilitent l’interfaçage au code Java. Grâce à cela, toutes les fonctions de l’IBM Toolbox for Java (il n’existe pas de meilleur kit pour l’intégration System i) sont à portée de main, ainsi que l’autre code Java que j’écris pour faire ce qu’EGL ne fait pas ou ne fait pas bien.

Si, partant de votre situation actuelle, vous ne pouvez pas obtenir une solution Java d’entreprise intégrale, RBDe/EGL pourrait bien être la réponse. Mais, même dans ce cas, la connaissance de Java vous sera précieuse. Vous n’avez peut-être pas besoin de devenir le superspécialiste Java, et peut-être Java ne doit-il pas être le langage principal de votre développement, mais Java est là et bien là, en toutes circonstances !