Look and Feel des applications

La figure ci-dessous montre l’allure classique de l’écran, et l’information, les logos et les boutons de contrôle apparaissent dans la partie supérieure.

(((IMG6419)))

Le menu et autres widgets figurent sur le côté droit (escamotable). Les widgets latéraux peuvent être placés dans un ordre différent par glisser/déposer et escamotés ou agrandis. A la prochaine connexion, vous retrouverez l’état et la position de chaque widget.

Le reste de la page représente le viewport où la majorité des programmeurs CGI placeront leur contenu. Cet écran en particulier montre un exemple de ce que l’interface utilisateur jqGrid permet d’accomplir.

La présentation est entièrement contrôlée par CSS et il est donc possible de la personnaliser, mais la plupart des utilisateurs s’accommodent de la présentation par défaut.

La topologie d’une application basée sur Renaissance

Une application RNS classique peut être divisée en quatre parties ou niveaux :

•    Le navigateur
•    Apache sur l’IBM i
•    Les programmes CGI
•    Le(s) serveur(s) d’arrière-plan

Le programme CGI est chargé de créer l’UI en utilisant les procédures et programmes de service fournis par le framework. Normalement, il ne connaît rien de l’environnement de base de données ou de la logique de gestion, mais il le peut si vous le souhaitez. Il communique avec les serveurs d’arrière-plan via des files d’attente de données.

Les serveurs d’arrière-plan ont un accès complet à la base de données et sont capables de traiter la logique de gestion (validation, CRUD, etc.). Ils peuvent aussi, en option, communiquer avec d’anciennes applications via des API, ou bien communiquer avec des systèmes tiers par des services web (Renaissance a des procédures de service intégrées qui lui permettent de consommer et de servir des services web).

Vous pouvez aussi insérer un niveau supplémentaire quand vous voulez utiliser le serveur Apache dans une DMZ mais garder les niveaux d’application sur une machine séparée derrière un pare-feu. Il suffit pour cela d’un simple changement de configuration qui dit à RNS d’utiliser sa propre fonctionnalité de dispatcheur de requêtes sur des files d’attente de données DDM. C’est le même principe qu’une installation reverse-proxy Apache mais sans nécessiter deux instances de serveurs Apache.