OpenRPGUI : introduction

Il va sans dire que l’IBM i et RPG se sont avérés incapables de produire une interface moderne depuis plusieurs années. Les sites RPG n’ont certainement pas reçu beaucoup d’aide d’IBM, dont la voie de modernisation a toujours été orientée vers Java, PHP, ou EGL—à l’exception de RPG Open Access. Je ne dis pas que Java, PHP, et EGL ne peuvent pas faire le travail, mais dès lors qu’il y a plus d’un langage côté serveur impliqué dans le processus de modernisation, la complexité va poser  des problèmes : multiples serveurs d’applications, multiples mises à jour de divers compilateurs et runtimes, nécessité de  s’accommoder de la courte durée de l’information pour chaque langage, etc. Il en serait de même pour un site .NET intégralement Microsoft à qui l’on demanderait de faire passer son back end sur des bases de données Oracle fonctionnant sur l’OS Solaris. Cette recommandation susciterait quelques interrogations, n’est-ce pas ? Dans mon esprit, c’est la même chose pour mettre votre RPG en frontal de Java, PHP, EGL, ou .NET et n’utiliser RPG que comme une couche de logique de gestion : cela ne fournit pas une infrastructure efficace ou intégrée pour l’activité côté serveur et ne devrait être envisagé qu’en dernier ressort.

Ne doublez pas les points de défaillance

D’après mon expérience, beaucoup de sites IT délèguent l’UI moderne à d’autres piles technologiques, comme ASP.NET, JavaServer Faces, ou PHP, au lieu de rechercher les manières dont RPG peut “parler” au navigateur. Le plus souvent, ASP.NET est utilisé pour l’interface graphique frontale, et les appels sont renvoyés à RPG et DB2 par un mélange de technologies telles que SQL, services web XML, ou sockets bruts. Une telle approche risque de doubler le nombre de points de défaillance, ce qui est inacceptable selon moi, alors qu’il est précisément question de gérer efficacement de grands comptes.

Et si vous pouviez moderniser votre UI en n’utilisant que RPG côté serveur ? Et si vous pouviez tirer parti des décennies de programmation RPG, un langage très efficace et modulaire avec une syntaxe tournée vers la gestion ? Et si vous pouviez utiliser des concepts similaires pour “parler” aux interfaces modernes, comme écrire et mettre à jour des enregistrements de fichier d’affichage pour naviguer d’un écran à un autre ?

Ce qu’il nous manque

Pendant ces dernières années, je me suis intéressé à ce qui nous manque, en tant que programmeurs RPG. Le seul vrai manque important est un moyen de communication facile avec les interfaces utilisateur modernes. Celles-ci incluent non seulement le navigateur, mais aussi des appareils mobiles du type Android, iPhone, et iPad. Il n’a pas été compliqué de parvenir à cette conclusion, mais j’y suis arrivé en évaluant aussi ce que nous avons et que d’autres plates-formes n’ont pas, des choses que nous tenons pour acquises. Nous sommes supérieurs en intégration avec la base de données, OS, job logs, et piles d’appel. Nous avons un OS très stable construit d’emblée pour gérer beaucoup de transactions et d’utilisateurs à la fois, et qui n’est pas un paradis pour les virus. Nous avons un excellent contrôle de jobs et le meilleur système de lignes de commandes et de menus qui soit. Ma pratique de Linux et Mac ces trois dernières années m’a fait apprécier tous les mérites des lignes de commandes et des menus pour l’administration système. Nous pouvons déboguer des jobs côté serveur en production et nous avons aussi des mécanismes de contrôle d’environnement à la fois puissants et simples avec des listes de bibliothèques et des descriptions de jobs. Je pourrais continuer à égrener la liste des choses positives, mais je m’égare.

(((IMG6556)))
Figure 1 : Définir un panneau

C’est pour ces raisons que j’ai constamment recherché des technologies qui ne concernent que la couche de présentation. Je suis heureux de dire que c’est devenu une réalité tangible ces dernières années, avec des frameworks basés sur JavaScript tels que Ext JS de Sencha. J’aime Ext JS parce qu’il aborde la conception d’écran en configurant des panneaux et des composants d’UI plutôt que de pousser vers le navigateur une masse de HTML, à chaque fois. Par exemple, avec Ext JS je peux définir un panneau avec la syntaxe de la figure 1 ; ce code est transféré vers le navigateur une fois par visite vers le site web, au lieu d’un transfert chaque fois que l’utilisateur navigue vers la page ou à partir d’elle.

(((IMG6557)))
Figure 2 : Panneau créé par le code de la figure 1

La syntaxe JavaScript de la figure 1 définit le panneau de la figure 2. Si cela vous semble étrange, c’est bien normal. Après quelque pratique et exercice, vous constaterez qu’il n’y a que quelques règles syntaxiques à mémoriser quand vous travaillez avec des objets d’Ext JS pour les configurer via JavaScript. Cet article ne prétend pas expliquer la syntaxe JavaScript ; pour plus d’informations, voir en.wikipedia. org/wiki/JavaScript_syntax.

Les définitions de panneaux sont volontairement simples pour que nous puissions nous concentrer sur les concepts sans être gênés par trop de syntaxe. Il y a en fait deux syntaxes dans la figure 1 : JavaScript proprement dit, et l’API Ext JS, qui utilise JavaScript mais a certaines exigences quant aux types de choses acceptables pour une  configuration donnée. La documentation de l’API Ext JS et la documentation Ext.Panel sont en ligne.