Programmation RPG pour le Web

renvoyée au navigateur.

A ce moment-là, il n’y a plus de connexion entre le navigateur et le job serveur. La requête suivante provenant du navigateur pourrait aller à un job serveur différent. Cela signifie aussi que le même job serveur pourrait être en train de communiquer avec de multiples navigateurs, chacun effectuant la même fonction (par exemple, cinq personnes pourraient saisir des commandes, mais un seul job s’occuperait des cinq).

Par conséquent, il faut maintenir l’information d’état pour chaque client demandeur. Cette exigence rappellera des souvenirs à ceux d’entre vous qui ont programmé sur System/34 et System/36 – qui se souvient des programmes MRT ? La deuxième considération est que le navigateur se charge de la conversation.

Dans des applications 5250, le programme contrôle l’entrée et sortie des écrans et nous avons l’habitude d’écrire une logique qui effectue une boucle dans l’affichage et l’entrée d’un écran, jusqu’à ce qu’une touche de fonction soit actionnée ou qu’une certaine condition soit remplie. Tel n’est pas le cas avec des programmes CGI : un programme CGI reçoit une requête et envoie une page (entrée et affichage), mais il n’y a pas de boucle. La page Web détermine quel programme est appelé et le programme (si nécessaire) doit trouver quelle page a envoyé la requête.

La troisième considération est que toutes les données d’une page Web sont de type caractère : toutes les données envoyées à une page Web et toutes celles qu’on en reçoit. Tout va bien quand on envoie des données à un navigateur, mais c’est une autre histoire dans l’autre sens. Vous pouvez utiliser des routines JavaScript pour valider l’entrée sur le navigateur, mais comme tout utilisateur peut désactiver JavaScript dans un navigateur, vous devez aussi le valider dans votre programme.