Exemple de CGIDEV2

deuxième temps le développement d’arrière-plan. Au moment où je conçois l’UI, les trois acteurs que sont RPG, HTML et CGIDEV2 ne sont pas encore en scène.
br> Pour l’exemple d’application, il me faut trois pages UI. La première affiche le message invitant l’utilisateur à entrer le numéro d’article (figure 1). La deuxième affiche les résultats quand l’article est trouvé (figure 2). La troisième montre la page d’erreur que reçoit l’utilisateur si l’article n’est pas trouvé (figure 3).Pour cette application, j’ai utilisé l’outil de conception Web WDSc, Page Designer. Il m’a favorablement impressionné jusqu’ici, mais vous pouvez utiliser n’importe quel outil de conception Web de votre choix. La figure 4 montre l’invite de consultation d’article et les pages de résultat dans l’outil de présentation WYSIWYG WDSc. J’ai voulu le HTML simple. Dans une application réelle, il est probable que vous utiliserez des CSS (Cascading Style Sheets), plus de couleurs, et d’autres éléments de conception. Cependant, vous pouvez voir dans les figures 1, 2 et 3 que j’ai agrémenté l’interface utilisateur de quelques couleurs et images.
La figure 5 montre le fichier itemlookup.html qui contient le HTML pour l’invite de consultation d’article et les formulaires de résultat.
La figure 6 montre le fichier errorforms.html, qui contient le HTML pour le formulaire d’erreur. CGIDEV2 vous permet de mettre un nombre quelconque de pages Web dans un fichier source unique, et on utilise le marqueur /$ pour séparer chaque formulaire ou page. Ainsi, comme on le voit figure 5, j’ai conçu deux modèles de formulaire, initialform et resultform, dans le fichier HTML unique. Dans la suite de cet article, nous verrons comment amener les formulaires dans le programme RPG.
A noter les marqueurs /%variablename%/, comme /% price%/. CGIDEV2 utilise des garde-places variables afin que, en RPG, je puisse insérer des valeurs comme noms de variables. Considérez ces gardeplaces comme des champs dans un fichier écran.
Une fois l’interface utilisateur conçue, je peux passer au développement du programme RPG. Sa logique coule de source :

• Afficher le formulaire d’invite (figure 1).
• Attendre que l’utilisateur entre un numéro d’article et clique sur le bouton Find It !.
• Extraire le numéro d’article du formulaire HTML.
• Essayer de trouver le numéro d’article dans le fichier base de données maître article.
• Renvoyer les résultats :
  • Si l’article est trouvé, montrer l’information le concernant, y compris son image (figure 2).
  • Si l’article n’est pas trouvé, renvoyer un message d’erreur dans le formulaire. Ce dernier contient un bouton Try Again sur lequel l’utilisateur peut cliquer pour revenir à l’étape 1 pou procéder à une autre consultation (figure 3).

La figure 7 montre le code source RPG du programme ITEMLOOKUP.

ITEMLOOKUP est compilé sur l’iSeries et est appelé chaque fois que le serveur Web doit demander à l’utilisateur un numéro d’article, afficher l’information correspondante, ou afficher une page d’erreur dans le cas où un article n’est pas trouvé. Le paramètre d’action du formulaire (A en figure 5) indique le programme serveur à appeler.

Examinons donc le code source pas à pas (les lettres qui suivent correspondent aux sections de la figure 7) :

• Sans aucun doute, CGIDEV2 et RPG permettent d’accéder facilement à tous vos fichiers DB2/400. J’ai indiqué l’emplacement du fichier.
  Généralement, les problèmes de liste de bibliothèques sont courants quand les programmeurs commencent à utiliser des applications CGI ou Web. Si les fichiers ne se trouvent pas dans la bibliothèque CGI, il faut utiliser le mot-clé EXTFILE ou mettre à jour manuellement la liste des bibliothèques dans la liste de bibliothèques du job serveur Web, pour être certain de trouver les fichiers.
• Les prototypes et variables pour CGIDEV2 sont amenés avec un ou plusieurs membres copie.
• Ces deux variables de travail sont les seules à définir pour l’application.
• Ce code efface le contenu du buffer CGIDEV2 et amène les formulaires HTML que nous avons créés. Consi—dérez l’appel GetHtmlifsMult comme un appel ouvert vers de multiples fichiers écran. La sous-procédure Get—HtmlifsMult charge en mémoire – moyennant un seul appel – les multiples fichiers IFS HTML définis en externe (c’est-à-dire, des fichiers stream).
• Cette étape est particulièrement importante. Si le serveur Web n’a rien à renvoyer à mon programme dans le champ du formulaire de requête, je peux extraire la valeur. Si la requête n’extrait rien, je sais que c’est la première requête pour l’application et que je devrais afficher le formulaire initial que montre la figure 1. Une fois que le formulaire est montré dans le navigateur, on observe la présence d’un fichier caché appelé Request avec la valeur « lookup » (B en figure 5). Quand l’utilisateur entre le numéro d’article et clique sur Find It !, le champ Request contient la valeur « lookup », que mon application extrait dans cette étape – et maintenant je sais que je dois essayer de consulter un numéro dans le fichier ITEMS1, le fichier base de données maître article.
• Quand je suis dans cette partie de la logique SELECT, je sais, d’après la valeur du champ Request, que j’ai besoin de faire une consultation. Pour cela, j’utilise l’appel ZhbGetVar pour extraire ce que l’utilisateur a mis dans l’entrée numéro d’article dans le formulaire Web. Le résultat est placé dans le champ Number de ITEMS1. J’enchaîne vers le fichier puis je décide de l’action à mener selon que la chaîne a trouvé quelque chose ou non.
• Le numéro d’article a été trouvé. J’utilise maintenant la procédure up dHTMLVar pour construire la valeur de la variable HTML écrite en retour vers le navigateur. Par exemple, updHTML var(‘desc’ : descript); prend la valeur de descript et met à jour (c’est-à-dire, remplace) toute référence à /%desc%/ dans le formulaire sortant. Au terme du processus, j’utilise la procédure Wrt Section avec le nom du formulaire provenant du source HTML pour écrire le formulaire en retour vers le navigateur. Facile !
• Le numéro d’article n’est pas trouvé. J’utilise la procédure updHTM LVar pour mettre à jour /%number%/ dans le formulaire des messages d’erreur puis pour écrire le formulaire d’erreur avec la procédure WrtSection.
• Si le champ Request a n’importe quelle valeur autre que lookup, je vais montrer le formulaire initial pour l’entrée du numéro d’article (figure 1).
• Et voila. Le WrtSection(‘*fini’) est utilisé dans CGIDEV2 pour indiquer que tout le travail courant est effectué et que toute la sortie devrait être renvoyée au navigateur. Pour finir, un peu de ménage : on ferme tous les fichiers.

En examinant le code source, vous constaterez qu’il est facile d’amener une application à utiliser une UI navigateur. Et, bien que cet exemple soit plutôt simple, chez KOA, nous avons utilisé CGIDEV2 pour développer des applications semblables à une application d’entrée/sortie de sousfichier. Je suis sûr que dès que vous aurez fait fonctionner votre première application CGIDEV2, vous trouverez d’autres usages intéressants pour cet outil commode et gratuit ! N’oubliez pas de consulter le site Web CGIDEV2 d’IBM (www-922.ibm.com/easy400/framer1. html?url=/cgidev2/ start) et d’analyser les exemples. C’est comme cela que nous avons appris rapidement à utiliser CGIDEV2.