NetWeaver Developer Studio et Web DynPro

Projet Web DynPro avec NWDS

Model View Controller

Le framework WebDyn Pro, comme je le disais précédemment, possède sa propre structure qui est un dérivé du design pattern MVC.

L'encadré n°1 dans l'image ci-dessous, représente les diffférentes vues qui ont été créées par le developpeur, l'encadré n°2 les différents Controllers et enfin l'encadré n°3 les Modèles importés.

Il suffit donc ensuite de linker les différentes vues avec le controller souhaité et faire de même avec les controllers et le modèle souhaité.

Notons que le rôle du modèle (encadré n°3) est bien différent de celui du design pattern MVC. En effet le modèle du framework WebDyn Pro sert uniquement à importer les données système du progiciel SAP (retour des programmes ABAP). Il n'est donc pas obligatoire pour faire fonctionner une vue dont les données système sont inutiles.
Le rôle de modèle du design pattern MVC est rempli par les propriétés d'un élément, partie que nous verrons ultérieurement dans la partie Développement normal.

View Controller/Custom Controller

View Controller et Custom Controller voici deux notions qu'il ne faut pas mélanger.

Chaques vues possèdent son propre controller (View Controller), ce controller sert pour des données qui sont locales à une seule vue.
Mais lorsque qu'une donnée est commune à plusieurs vues il faut la déclarer dans le Custom Controller et ensuite la linker avec les differentes View Controller qui l'utiliseront. Cela permetra de répercuter les changements de valeur de cette donnée sur toutes les vues l'utilisant.

Sachant que les données linker entre le Custom Controller et le View Controller peuvent être choisies (le View Controller n'est pas obligé de possèder toutes les données déclarées dans le Custom Controller), il est donc préférable de déclarer toutes les données dans le Custom Controller et de les linker ensuite vers les View Controller qui l'utilisent.
Car même si une donnée n'est utilisée que par une seule vue, un changement éventuel de l'application avec la création d'une autre vue utilisant cette donnée, engendrerait des changements minimes si cette dernière a deja été déclarée dans le Custom Controller.

Développement normal

Qu'est ce que le développement dit normal ? Comme je le disais précédemment le framework WebDyn Pro possède des méta-données que le développeur peut réutiliser celon ses besoins.
Les encadrés n°3 et 4 representent l'onglet "Layout" de la vue. Les utilités des autres onglets seront expliquées ultèrieurement comme l'onglet "Implementation" dans la section Développement dynamique
Ici les meta-données sont représentées dans l'encadré n°4, il suffit au développeur de faire glisser l'objet souhaité vers l'encadré n°3, qui représente la vue en elle même, afin d'y intégrer l'objet souhaité. Notons qu'il est possible de faire cette opération uniquement lorsque nous sommes sur l'onglet "Layout" de la vue.

L'encadré n°1 représente la liste des objets présents dans la vue séléctionnée (les objets présents dans une vue possèdent tous un ID différent pour les représenter) et l'encadré n°2 caractérise les propriétés de l'élément selectionné dans l'encadré n°1. C'est d'ailleurs ces propriétés qui jouent le rôle du Model du design pattern MVC, car c'est ici que l'on choisit les caractéristiques d'un élémént.
Dans l'exemple ci-dessus on peut voir dans l'encadré n°2 les propriétés de l'élément "RoorUIElementContainer" sélectionné dans l'encadré n°1. On peut y voir que le layout utilisé est un GridLayout avec 2 colonnes. C'est pour cette raison que le TextView et le bouton sont sur la même ligne dans l'encadré n°3.

Développement dynamique

Le développement dynamique sert à implémenter les tâches impossibles à réaliser depuis le développement normal. En effet, Il est parfois impossible de prévoir le nombre de lignes d'un tableau avant d'avoir éffectué certains calculs, il est donc important d'avoir la possibilité d'effectuer ce calcul et de prévenir ensuite dynamiquement l'objet tableau du nombre de ligne.

Pour faire du développement dynamique il faut aller dans l'onglet "Implementation" de la vue comme dans la capture ci-dessous :



A la création d'une vue il existe 3 méthodes : wdDoInit, wdDoExit et wdDoModifyView.

• La méthode wdDoInit permet d'initialiser un certain nombre de valeur avant le premier affichage de la vue.


• La méthode wdDoExit n'est éxecutée que lorsque l'on quitte la vue.


• Et enfin la méthode wdDoModifyView, qui est la plus importante, est éxécutée à chaque réaffichage de la vue. C'est la seule méthode ou les objets de la vue sont accessibles grace à l'argument "com.sap.tc.webdynpro.progmodel.api.IWDView view" que possède cette méthode. Pour récupérer un Objet il suffit de faire "view.getElement("IDElement"). On peut ensuite travailler sur l'objet comme par exemple lui indiquer ces propriétés.

Récupérer des fonctions BAPI (ABAP)

Les BAPIs (Business Application Programming Interface) sont des focntions ABAP dans SAP. Elles permettent à l'interface utilisateur de connaitre les données enregistrées dans le système. Mais elles permettent également de les maintenir à jour lors d'un changement éventuel fait par un utilisateur.

Pour récupérer ces fonctions voici les 4 étapes qu'ils faut impérativement réaliser :

• 1er Etape : importer un Model dans NWDS avec la BAPI que l'on souhaite utiliser.


• 2ième Etape : linker la BAPI du Model vers le Custom Controller.


• 3ième Etape : linker la BAPI entre le Custom Controller et le View Controller de la vue.


• 4ième Etape : Exécuter la bapi :
  wdContext.currentNomBAPI.modelObject().execute();

Notion de OnAction

Toutes les actions que l'on souhaite réaliser dans un tel projet doivent être définies ici car ce sont les actions enregistrées ici que l'on pourra associées à un bouton par exemple.

Pour déclarer une action il suffit d'aller dans l'onglet "Actions" de la vue (comme la capture ci-dessous) et de cliquer sur le bouton "New".



Une fois l'action enregistrée, quand on retourne dans l'onglet "Implementation", on peut y voir à la fin une nouvelle méthode (comme ci-dessous). On peut alors associer du code à cette action comme par exemple un "Fire" pour un changement de vue (voir la partie Gérer le passage d'une vue à une autre).



Et enfin, une fois que notre action est prête il est possible l'associer à un bouton dans les propriétés de ce dernier comme le montre l'exemple ci-dessous.

Gérer le passage d'une vue à une autre

Sur le Diagramme des vues de NWDS, il faut rajouter un "outbound plug" à la vue de départ, ajouter ensuite une "inbound plug" à la vue d'arrivée puis linker les deux plug.
Comme sur l'image si dessous :




Il faut ensuite indiquer dynamiquement à la vue de départ le moment où l’on bascule sur l’autre vue.
Généralement dans un OnAction comme ci-dessous :

Notons que c'est la création de l'outbound plug qui a créée la méthode wdFireNomOutBound(), et que le changement de vue est entierement géré par le framework WebDyn Pro.

Internationalisation

Pour gérer l'internationalisation, le framework WebDyn Pro possède un fichier qui associe à un ID un texte. Cela permet au developpeur de n'utiliser dans son code que des IDs et il suffit ensuite de traduire toutes les zones de texte du fichier en question pour un pays ayant une langue différente de celle prévue initialement.

Ce fichier se trouve à cet emplacement : src/packages/Nom_Packages/NomVueMessagePool.wdmessagepool.xlf
Voici un exemple de fichier :

L'ID associé à un texte est déclaré dans la colonne "Ressource Name", cet ID doit être encadré par "Message:" et "@content". Le texte associé à cet ID est lui déclaré dans la colonne "Text".

Comment utiliser ce fichier dans le code pour un développeur, c'est trés simple :
Il suffit de déclarer cet objet en debut de programme : "IWDTextAccessor textAccessor = wdThis.wdGetAPI().getComponent().getTextAccessor();"

Pour ensuite le réutiliser lors de l'affectation de texte à un objet en récupérant le texte associé à un ID comme ceci : "textAccessor.getText(«ID»);"