Rapport de Stage de deuxième année Réalisation - Libre

Transcription

UNIVERSITE F RANCOIS R ABELAIS TOURS
P OLYTECH ’ TOURS -D ÉPARTEMENT I NFORMATIQUE
64,Avenue Jean Portalis
37200 TOURS
Rapport de Stage de deuxième année
Réalisation et intégration du module projet
dans l’E . R . P. OfBiz/N ÉOGIA
E.P.U.-D.I.2
Septembre 2005
Société NÉRÉIDE
3bis les Isles
37270 Veretz
Encadré par
M. Olivier H EINTZ
Étudiant
E L I DRISSI M AJID
DI 2 année scolaire 2004/2005
2
Remerciements.
– à Olivier H EINTZ qui a su être patient, car je comprends vite si on m’explique
longtemps
– à toute l’équipe Néréide qui a offert un environnement de travail convivial, qu’il
doit être difficile de trouver ailleurs
3
Convention.
– les fichiers, chemins sont notés avec ce jeu de police
/etc/apt/sources.list
– les noms de balise X . M . L . ou d’attributs sont notés avec ce jeu de police
set
– Les entités, ou nom de classe avec celui-ci
T IME S HEET
Avertissement.
Pour pouvoir profiter de ce rapport, il est nécessaire d’avoir au préalable quelques
connaissances sur le HTML, de savoir lire une D . T. D . et d’avoir l’habitude de parcourir des
fichiers X . M . L ..
Table des matières
Chapitre 1. Présentation générale
1.1. L’entreprise : N ÉRÉIDE
1.2. Le framework
5
5
6
Chapitre 2. Le travail réalisé
2.1. Website
2.2. Projet
2.3. Les feuilles de temps
2.4. Les tâches de sous-traitance
2.5. Avancement d’un Ordre de Fabrication
2.6. Saisie rapide de tâche et de feuille de temps
8
8
11
11
12
18
19
Chapitre 3. Documentation produite
3.1. Vue d’ensemble du traitement d’une requête
3.2. Les widgets/screens widgets
3.3. Us et coutumes des widgets OfBiz/Néogia
3.4. Les « Form », ou formulaires
20
20
22
28
33
Conclusion
36
4
CHAPITRE 1
Présentation générale
1.1. L’entreprise : N ÉRÉIDE
N ÉRÉIDE est une S . S . L . L., Solutions et Services en Logiciels Libres, spécialisée dans
l’intégration d’E . R . P. Libre pour les P. M . E . :
– gestion comptable
– gestion de stock, gestion de production
– gestion commerciale et vente par internet
– gestion de projet, gestion de prestation de service
et fournit en conséquence des services tels que :
– la formation à destination :
– des utilisateurs du framework OfBiz/N ÉOGIA
– des développeurs
– le conseil
N ÉRÉIDE a choisi comme P. G . I ., Progiciel de Gestion Intégré, ou E . R . P. en anglais, le
progiciel OfBiz qui est un logiciel libre1.
De par sa structure très modulaire, il peut être mis en œuvre très facilement et très
rapidement dans des environnements techniques très hétérogènes.
Sa licence n’implique aucun paiement lié à son utilisation ou à sa copie. De plus, il est
possible à tout moment, de développer des fonctions ou des modules supplémentaires et
de les voir intégrés dans la version standard du progiciel. Le développement de nouvelles
fonctionnalités est donc, avant tout, dirigé par les usages et les besoins des utilisateurs.
Ce progiciel est entièrement écrit en JAVA dans une architecture J .2 E . E .. Il est conforme
aux standards actuels (X . M . L ., S . O . A . P., ...) afin de garantir son évolutivité en fonction des
changements du monde informatique. Bien qu’ayant déjà de très nombreuses fonctionnalités, il continue à se développer de manière très rapide.
Néréide est très fortement impliquée dans le développement et le support du progiciel
OFBiz. Elle a, par exemple, participé à son internationalisation, à la réalisation du module
Gestion de production, puis, a entièrement traduit en français le progiciel.
Néréide a été créée en 1995, avec pour activité, tous les services Post-implémentation
d’un PGI du marché.
La société s’est spécialisée dans l’intégration de PGI en logiciel libre. Ce choix correspond à la philosophie de toute son équipe, convaincue de l’efficacité du partage de
l’information et du travail collaboratif.
De plus, Néréide est membre du réseau Libre-entreprise pour ainsi participer au vivier
de compétences et d’expertises très étendues qui le compose.
1ou plus précisément un logiciel sous license M . I . T.
5
1.2. LE FRAMEWORK
6
Tout ce que nous venons de dire sur N ÉRÉIDE concerne en fait son cœur de métier,
mais pas toute son activité. En effet, N ÉRÉIDE a du faire un petit écart du côté du développement afin d’adapter OfBiz à ses besoins, ou plus précisement aux besoins de ses clients,
mais l’entreprise espère bien revenir à son premier métier : le conseil.
N ÉRÉIDE, c’est aussi une petite équipe :
Oliver HEINTZ
Directeur de projet
Yannick HEBAULT Directeur technique
Eric BARBIER
Gérant
Jean-Luc MALET
Directeur de projet
Catherine HEINTZ Directeur administratif et financier
Sophie BENAROCH Responsable communication
Pierre GAUDIN
Responsable fonctionnel gestion de stock
Nicolas MALIN
Responsable fonctionnel comptabilité
et pendant toute la durée de mon stage, j’ai eu pour co-stagiaire :
Peter GORON
Géraud BUXEROLLES
alors tous deux étudiants au D ÉPARTEMENT I NFORMATIQUE de l’É COLE P OLYTECHNIQUE de Tours, et effectuant leur stage de troisième année.
1.2. Le framework
1.2.1. OfBiz.
OfBiz est un progiciel de gestion intégré, ou P. G . I .2, ce qui désigne ici les fonctions
suivantes :
– ERP, ou Enterprise Resource Planning
– CRM, ou Customer Relationship Management
– E-Business / E-Commerce,
– SCM, ou Supply Chain Management
– MRP, ou Manufacturing Resource Planning
– CMMS/EAM, ou Computerized Maintenance Management System
Il est également sous license M . I . T. ce qui autorise N ÉRÉIDE à utiliser le programme3 à ses
fins.
OfBiz est une application client/serveur, suivant le modèle trois-tiers :
– les clients, dans le cas de N ÉRÉIDE des clients légers disposant d’un navigateur
internet
– un serveur exécutant Ofbiz
– et une ou plusieurs bases de données
1.2.2. N ÉOGIA.
N ÉOGIA est partie du besoin simple d’ajouter des fonctionnalités à OfBiz, mais OfBiz
est, par conception, orienté fonction, tous ses modèles étant de la forme entité-relation, or
il a semblé plus judicieux d’avoir une approche orientée objet, et ainsi exploiter tous les
avantages de la programmation orientée objet. Cet objectif n’a été à mon goût que partiellement atteint du fait du fonctionnement entité-relation d’OfBiz, le mélange des genres
m’ayant par ailleurs beaucoup handicapé dans la maîtrise du framework.
Les concepteurs d’OfBiz n’ayant pas désiré adopter une telle approche objet, le projet
N ÉOGIA voyait donc le jour.
2OfBiz dit plutôt enterprise automation software
3la seule contrainte imposée par la license étant de respecter le droit d’auteur
1.2. LE FRAMEWORK
7
Avec cette approche objet, s’est vu ajouter toutes les facilités annexes fournies par la
génération de code à partir de diagrammes. L’équipe s’est donc mis à utiliser conjointement
outils de modélisation U . M . L . et outils de génération de code. L’aspect génération de code
a d’ailleurs permis le travail avec une autre équipe, les « Codes Lutins », spécialisée dans
le JAVA et ses outils, et leur collaboration a permis l’élaboration de générateurs de code
pour N ÉOGIA.
CHAPITRE 2
Le travail réalisé
2.1. Website
C’est l’endroit où il y a eu le plus de conception. En effet, même si OfBiz dispose
d’une C . M . S . (un système de gestion de contenu), personne dans l’équipe ne s’était encore
penché dessus, et dans le cadre de la formation au framework, il m’a été demandé de
réaliser un tout petit C . M . S .1 :
j’avais pour tâche, tout en réutilisant le framework OfBiz/N ÉOGIA (sans toutefois utiliser le C . M . S . inclus), d’une part de fournir une interface utilisateur permettant la gestion
des articles, d’autre part de réaliser de manière dynamique la création du site web à partir
des articles stockés. Le projet s’est vu adjoindre par la suite une gestion multilingues des
articles.
2.1.1. La modélisation.
Sur cette phase Peter G ORON , Géraud B UXEROLLES et moi-même avons travaillé sur
la modélisation, Peter en tant que superviseur.
Il fallait donc faire en sorte d’avoir une arborescence d’articles, arborescence qui serait utilisée directement pour la navigation sur le website, et dont chaque noeud, ou section/heading, aurait une description et pourrait contenir une liste d’articles. De plus chaque
article se voit attribué une ou plusieurs langues, un auteur, ainsi que quelques informations
qui règlent son accès sur le website :
– un statut
ce statut permet de savoir où en est l’article dans sa conception
– une cible
c’est à dire ceux à qui est destiné l’article
La modélisation UML qui découla de ces besoins est on ne peut plus prévisible :
– la liste des articles d’une section est représentée par une entité d’association
– la liste des langues est aussi une entité d’association
– un article, une section sont des entités
– il y a une association 1 − 1 entre un article et un auteur
– il y a une association 0 ... 1 − n entre article et la cible
– il y a une association 1 − n entre un article et un statut
– l’arborescence des sections est représentée par une relation 1 − n d’une section sur
elle-même
Quelques attributs furent ajoutés afin de prendre en compte certains cas particuliers :
– urlOnly
lorsqu’il ne s’agit pas d’un article mais en fait d’un lien sur un autre document,
un autre site, etc
1les stagiaires Peter/Géraud ont également participé à la construction du website, mais leur participation a
été relativement courte
8
2.1. WEBSITE
9
– sequenceNum
cet attribut permet de régler l’ordre d’affichage des sections dans le site internet,
et sur l’interface utilisateur de saisie d’articles.
On aboutit au diagramme de la figure 2.1.1
F IG . 2.1.1. Modélisation U . M . L . du Website
2.1.2. Le code généré.
Le diagramme U . M . L . produit est alors passé à la moulinette d’un générateur de code,
spécifique à N ÉOGIA, qui a produit tous les widgets permettant de réaliser les affichages
suivants (tous les affichages ne figurent pas ici, seul un exemplaire de chaque type de
widget est présent) :
2.1. WEBSITE
10
création de section
recherche de section
résultat de recherche
associer des langues à un article
2.1.3. La partie développée.
Même si une grande partie du travail est ainsi réalisée, il reste toutefois le website
lui-même qui ne peut pas être généré de la sorte, ainsi qu’une « feature » non gérée en
automatique à l’heure qu’il est :
permettre l’ajout de section existante, et la création d’une section dans le même écran
d’association, la capture de la figure 2.1.2 est plus parlante. Ce fut l’une de mes premières
tâches et aussi celle qui m’apprit le fonctionnement des widgets.
F IG . 2.1.2. Dialogue cumulant l’ajout et la création de section
2.3. LES FEUILLES DE TEMPS
11
2.2. Projet
Le cadre de travail diffère ici de deux manières. D’une part le composant existait déjà
et permettait la création de projet et l’association à ce projet d’acteurs, de ressources, de
périodes ; d’autre part, je n’avais plus que mon encadrant de stage pour réaliser le travail,
les autres stagiaires s’étant vu affecter des tâches.
La tâche était simple puisqu’il fallait faire en sorte que l’on puisse créer des projets
et des sous-projets, d’associer des compte-rendus à un projet, des feuilles de temps à un
compte-rendu, d’associer des périodes typées à une période (en fait il s’agit de spécifier à
quelle période comptable doit être rattachée une période quelconque).
L’essentiel du travail était de la répétition de technique utilisée dans la tâche website.
2.3. Les feuilles de temps
2.3.1. Modélisation.
Les feuilles de temps font partie d’un tissu de relation qu’il faut expliciter car j’y
reviendrai plus tard lors d’une description d’une autre tâche accomplie chez N ÉRÉIDE. Sur
la figure 2.3.1 est disponible la modélisation U . M . L ..
F IG . 2.3.1. Modélisation des feuilles de temps
Une feuille de temps c’est en premier lieu une durée de travail réalisée par quelqu’un,
à une date donnée. Ce qui se trouve traduit par une relation entre T IME S HEET et PARTYM AN R ESOURCE (dans le frameWork OfBiz/N ÉOGIA un PARTY désigne une personne et
un PARTY M AN R ESOURCE désigne une personne considérée comme ressource ou main
d’œuvre de l’entreprise), et les attributs workDate et hourAmount.
2.4. LES TÂCHES DE SOUS-TRAITANCE
12
Dans un second temps, il faut penser qu’il existe différentes manières de gérer des
tâches (à la tâche, au volume, etc), et la modélisation voulant être large :
– il faut donc tenir compte des situations où le travail d’une personne peut être facturée ou non, attribut par association, T IME S HEET B ILLING (évidemment dans une
entreprise, où les employés travaillent à la chaîne, il peut paraître inutile d’avoir une
telle modélisation)
– il faut savoir si une feuille de temps a tel ou tel statut, attribut TimeSheetStatus
– il faut savoir si l’on a des frais, entité R ECEIPT, à ajouter à une feuille de temps,
par exemple un commercial ayant des frais d’hôtel à déclarer
– il faut raccrocher une feuille de temps à une période de report ; en remarque, nous
pouvons indiquer que les périodes de report ne correspondent pas forcément aux
périodes comptables, tout dépendant de la personne gérant les équipes, les projets,
ou les Ordres de Fabrication
– et il faut que la feuille de temps soit associée à une réalisation de tâche
2.3.2. Écran réalisé.
Ce fut sans doute l’un des écrans parmi lesquels j’ai passé le plus de temps, car non
générable par générateurs, comme le montre la capture de la figure 2.3.2 page suivante, et
impossible à créer, encore à l’heure actuelle, avec les formulaires OfBiz/N ÉOGIA .
Les raisons sont multiples :
– la référence d’acteur devait être remplie automatiquement,
pour l’heure il n’y a rien d’automatique concernant les références d’acteurs, il a
donc fallu chercher les données disponibles après l’authentification de l’utilisateur
lui permettant d’accéder à cet écran
– la zone de saisie du projet ne peut pas être générée car il n’y a pas de relation entre
une T IME S HEET et un P ROJECT
– il a aussi fallu créer une recherche de toute pièce pour faire en sorte que celle-ci
tienne compte de l’identité présente dans le formulaire
– les compétences pouvant être multiples pour un acteur au sein d’un même projet, il
a fallu rajouter cette boîte et le javascript qui rempli le champs immédiatement en
dessous, i.e. « À partir de », car cette date fait partie de la clef primaire dans la table
PARTY M AN R ESOURCE
– il fallait faire en sorte que la recherche d’un Ordre de Fabrication tiennent lui aussi
compte des données précédemment reçues
– il en est de même pour la référence d’opération, ou tâche, à ceci près qu’il a fallu
réaliser une « vue » afin de pouvoir tenir compte des informations fournies précédemment. Les créateurs d’OfBiz n’ont pas créé d’interface SQL permettant de faire
les requêtes du même nom (leur justification étant que toutes les bases de données
n’implémentent pas le SQL de la même manière), et une vue est en quelque sorte
une vision de la base de donnée avec des relations visibles ou pas, etc. C’est ce qui
se rapproche le plus du SQL, même si pour y parvenir une syntaxe pénible est à
utiliser
2.4. Les tâches de sous-traitance
2.4.1. Présentation des tâches.
Dans la modélisation de l’équipe N ÉRÉIDE des tâches, on discerne deux types de
tâches très différentes :
13
– les tâches théoriques, qui correspondent à ce qui est prévu de faire, par exemple
dans un Ordre de Fabrication, on peut avoir une tâche qui consistera à visser quelque
chose
– la réalisation d’une tâche, qui correspond à une tâche qui sera à réaliser, en une
certaine date et heure, et qui n’est plus théorique (il est ainsi possible de lancer un
Ordre de Fabrication avec un certain nombre de tâches, puis de modifier le modèle
théorique d’un Ordre de Fabrication, c’est à dire la liste de ses tâches, sans que cela
affecte les Ordres de Fabrication déjà lancés)
F IG . 2.3.2. Saisie d’une feuille de temps
14
Nous avons donc la modélisation visible sur la figure 2.4.1.
F IG . 2.4.1. Modélisation U . M . L . initiale
Nous en arrivons donc à notre sous-traitance. D’une part une sous-traitance sera facturée, d’autre part une sous-traitance correspondra à un service et à une circulation de
pièce (on peut sous traiter le nettoyage d’une pièce métallique, ce qui impose que la pièce
présente dans nos stocks soit sortie et expédiée).
Jusqu’alors, la sous-traitance était modélisée comme une tâche, au même titre que les
autres tâches, mais dans un souci de conception, il a été décidé de créer une entité soustraitance séparée.
2.4.2. La modélisation.
15
2.4.2.1. Modélisation des tâches de sous-traitance sous leur aspect théorique.
Tout d’abord une tâche de sous-traitance est une tâche comme les autres, comme le
suggère l’ancienne modélisation, mais il s’agit d’une tâche avec quelques particularités, il
paraît alors évident qu’une tâche de sous-traitance hérite d’une tâche, voir figure 2.4.2
F IG . 2.4.2. Modélisation U . M . L . finale
À la différence de la modélisation précédente, notre tâche de sous-traitance est associée directement avec un produit, mais cela n’a été réalisé que par soucis de commodité.
2.4.2.2. Modélisation des tâches de sous-traitance sous leur aspect réalisation.
Il reste encore la réalisation concrète d’une tâche. Comme indiqué précédemment,
c’était la tâche normale qui servait comme tâche de sous-traitance (voir figure 2.4.3).
Comme on peut le voir sur la modélisation initiale, une tâche était utilisable comme tâche
de sous-traitance, car sa réalisation était reliée aux tables concernant les ordres d’achat
F IG . 2.4.3. Modélisation
tâche de sous-traitance
U.M.L.
initiale de l’accomplissement d’une
16
Il va donc y avoir quelques modifications. Tout d’abord, il faut ajouter la tâche de
sous-traitance et l’associer avec les entités Q UOTE I TEM et O RDER I TEM, puis en conséquence modifier la tâche normale, qui ne doit avoir, par rapport au diagramme 2.4.3 page
précédente, de liaison qu’avec le WRUN, ou Ordre de Fabrication. Ceci est réalisé par la
création d’une entité nommée TASK F ULFIL S UBCTR qui sera la réalisation d’une tâche
de sous-traitance, au même titre qu’un TASK F ULFILMENT est la réalisation d’une tâche
normale.
Il faut ensuite associer la tâche de sous-traitance, ou TASK F ULFIL S UBCTR, directement avec l’entité P ROPOSED O RDER, cette table correspondant aux propositions d’achats,
association qui semble correcte car la sous-traitance est un service qu’il faudra payer auprès d’un tiers.
Nous en arrivons donc à la modélisation de la figure 2.4.4.
F IG . 2.4.4. Modélisation
sous-traitance
U.M.L.
finale de l’accomplissement d’une
2.4.3. La partie développée.
Toutes les modifications apportées se répercutent sous forme d’accesseurs supplémentaires et quelques ré-aménagements dans le code, mais ne nous assurent pas les tâches
suivantes :
– il faut pouvoir associer des tâches de sous-traitance à une gamme, ou autrement dit
modèle théorique
– lors de la création d’un Ordre de Fabrication et donc lors de la création des TASK F ULFILMENTs, i.e. la réalisation concrète d’une tâche, il faut que la gamme, soit
parcourue et que les bons TASK F ULFILMENTs soient créés :
– un TASK F ULFIL S UBCTR pour une tâche de sous-traitance
– un TASK F ULFILMENT pour une tâche normale
2.4.3.1. Écran réalisé.
Il faut pouvoir créer une tâche de sous-traitance, ce qui est maintenant possible via
l’écran de la figure 2.4.5 page suivante.
17
F IG . 2.4.5. Écran de création de tâche de sous-traitance
2.4.3.2. Génération des réalisations de sous-traitance.
Jusqu’alors lorsque l’utilisateur utilisait le widget de la figure pour créer un Ordre de
Fabrication, il fallait parcourir la liste des tâches de la gamme associée, puis pour chacune
de ces tâches créer une réalisation de tâche, ou TASK F ULFILMENT. Puis l’ensemble des
tâches était planifié par rapport aux stocks et à la durée d’acquisition/de fabrication des
pièces.
F IG . 2.4.6. Écran de création d’un Ordre de Farbrication
Dans un premier temps, il fallait donc que l’on crée toujours des TASK F ULFILMENT
lorsqu’il s’agissait de tâches normales, mais aussi, à l’instar des tâches normales, créer
pour les tâches de sous-traitance des TASK F ULFIL S UBCTR, i.e. des réalisations de tâches
de sous-traitance. Ceci fut une tâche aisée du fait même de la modélisation et du choix
du langage pour l’implémenter. Une TASK F ULFIL S UBCTR n’était qu’une classe fille de
TASK F ULFILMENT et le langage était le JAVA, i.e. un langage orienté objet.
Dans un second temps, il fallut modifier la planification des tâches de sorte qu’elle
tienne compte des tâches de sous-traitance. En effet, un service n’est pas géré de la même
2.5. AVANCEMENT D’UN ORDRE DE FABRICATION
18
manière qu’un mouvement de stocks, et il fallut donc exclure de la planification les tâches
de sous-traitance.
2.5. Avancement d’un Ordre de Fabrication
Il s’agissait ici de permettre l’avancement de tâche par l’utilisateur, c’est à dire lui
permettre de donner une date de début réel et de fin réelle, de tâche.
La figure 2.5.1 montre l’écran finalement obtenu, et une fois encore l’image cache le
travail qui a été fait derrière.
F IG . 2.5.1. Avancement d’un Ordre de Fabrication
2.5.2. Le code développé.
Outre les vérifications d’usages :
– dates valides, date de fin après celle de début, etc
– être sûr que l’on n’essaie pas de changer une date de début (le positionnement de
ces dates, est une section critique car un autre écran, montré plus bas, peut lui aussi
poser des dates)
il a fallut se poser les questions de planification. Lors de la première planification, c’est
à dire lors de la création de l’Ordre de Fabrication, toutes les dates estimées (le modèle
prévoyant des dates réelles et des dates estimées), sont fixées, mais il ne s’agit que de dates
estimées. Si une tâche a pris un retard non dissimulable (i.e. un retard suffisant pour que le
responsable juge nécessaire de faire figurer les vrais dates), doit-on replanifier ? Si oui comment ? Étant donné que la modélisation permet d’avoir des tâches qui commencent dans
le désordre (pour tenir compte, par exemple, de commandes impromptues et impératives),
comment refaire une planification ? De plus les algorithmes entrant dans la planification
n’avaient pas été conçus pour permettre une replanification.
Il fut décidé, avec avis de Peter G ORON (car concepteur des algorithmes de planification) et de mon encadrant de stage, qu’il y aurait planification systématique lorsque les
2.6. SAISIE RAPIDE DE TÂCHE ET DE FEUILLE DE TEMPS
19
tâches suivantes n’étaient pas lancées. Pour ce qui était du moment de replanification dans
l’Ordre de Fabrication :
– lorsque l’on entrait une date de début et de fin, on replanifiait sur les tâches suivantes
– lorsque l’on entrait seulement une date de début, on replanifiait à partir de la tâche
donnée, puis on changeait la date de début de la tâche précédemment planifiée
2.6. Saisie rapide de tâche et de feuille de temps
Il s’agissait ici de permettre une saisie rapide (par exemple via lecteur code barre,
lorsqu’il n’y a aucune ambiguïté), d’une tâche, et de générer automatiquement la feuille de
temps associée.
Il s’agit en quelque sorte d’une interface à tiroirs :
l’utilisateur doit saisir les informations nécessaires désignant la tâche
si il y a ambiguïté, et
donc là s’arrêterait la saisie rapide, on demande sur
quelles tâches précisément il
travaille ainsi que la compétence utilisée, ceci étant impératif pour saisir une feuille
de temps
la tâche ne peut que commencer, donc on fournit une
date de début réel. En effet il
n’est pas prévu qu’une saisie
rapide permette de fournir à
la fois une date de début réel
et une date de fin réelle
la tâche ne peut que finir,
donc on fournit une date de
fin réelle
c’est cet écran qui a révélé la section critique, puisque l’on avait avec ce nouvel écran,
la possibilité qu’un utilisateur tente de positionner une date de fin alors qu’un autre aurait,
par ailleurs, posé entre temps une date de début.
CHAPITRE 3
Documentation produite
3.1. Vue d’ensemble du traitement d’une requête
Supposons que nous ayons un utilisateur qui clique sur le lien « Sélection de coordonnées » de la figure 3.1.1
F IG . 3.1.1. Sélection de coordonnées
Remarque : pour parvenir ici, il vous faut avoir sélectionné l’onglet manufacturing/fabrication, puis
choisi dans la barre d’application « stock » puis emplacement, puis choisi un « emplacement » et finalement cliqué sur coordonnées
La requête serait alors de cette forme :
https ://[...] :8443/facility/control/EditAssocNFacility ?[...]
3.1.1. Orientation.
Après des traitements préliminaires, OfBiz interprète comme suit : le composant est
facility, puis il faut chercher dans le contrôleur une map nommée EditAssocNFacility.
On peut alors trouver dans ce contrôleur :
20
3.1. VUE D’ENSEMBLE DU TRAITEMENT D’UNE REQUÊTE
21
1 [...]
2 <request-map uri="EditAssocNFacility">
3
<security https="true" auth="true"/>
4
<response name="success" type="view"
value="EditAssocNFacility"/>
5
<event type="service" invoke="addOrderShipmentToShipment"/>ò
6
<response name="error" type="view" value="EditAssocNFacility"/>
7 </request-map>
8 [...]
9 <view-map name="EditAssocNFacility" page="component :
10
//facility/widget/facility/locationScreens.xml#EditAssocNFacility"
11 type="screen"/>
12 [...]
F IG . 3.1.2. Vue d’ensemble du contrôleur
Remarque : la ligne 5 n’existe pas dans la réalité, elle n’est là que pour permettre d’avoir une vue plus
large, il n’y a donc aucun sens à chercher derrière cet appel de service
qu’il faut lire comme suit :
numéro de ligne
2
pour l’uri EditAssocNFacility
3
il faut une connexion sécurisée et un utilisateur authentifié
4
en cas de succès du service, il faut aller sur la vue EditAssocNFacility
en cas d’échec du service, il faut aller sur la vue EditAssocNFacility
5
OfBiz sait donc maintenant ce qu’il doit faire pour traiter la requête :
– exécuter le service addOrderShipmentToShipment (un « service » n’est qu’un type
d’« event » particulier)
– si celui-ci renvoie « success » alors on va sur la vue EditAssocNFacility, qui s’occupera de l’affichage d’information
– sinon, dans cet exemple, on va sur la vue EditAssocNFacility
nous retrouvons donc notre vue, que nous pouvons interpréter comme suit :
pour la vue EditAssocNFacility, on cherchera dans le fichier widget/facility/locationScreens.xml
du composant facility le screenWidget EditAssocNFacility, du fait des lignes 9 à 11 de la
figure 3.1.2.
3.1.2. Traitement du service.
Le framework OfBiz permet au développeur de faire précéder ou suivre ce service,
editNFacilityType, par d’autres services, par l’entremise de « seca »s, OfBiz va donc maintenant aller vérifier dans le fichier secas.xml présent dans facility/servicedef1. Nous y
trouvons alors le bloc suivant :
1il est possible de régler ce chemin ainsi que d’autres dans le fichier ofbiz-component.xml présent à la
racine du composant
3.2. LES WIDGETS/SCREENS WIDGETS
22
1 <eca service="addOrderShipmentToShipment" event="return">
2
<action
service="updateOrderStockEventPlannedAfterCreateShipmentItem"
3 mode="sync"/>
4 </eca>
F IG . 3.1.3. Extrait d’un fichier « seca »
qu’il faut lire comme ceci :
numéro de ligne
1
au retour du service addOrderShipmentToShipment
2
on exécutera, en mode synchrone, le service updateOrder[...]ShipmentItem
updateOrder[...]ShipmentItem étant un service, ofbiz repasse dans ce même fichier à
la recherche de « seca »s pour ce service et ainsi de suite.
Une fois que tout ce qui concernait les services a été réalisé, et que tout s’est fini avec
« success »2, nous revenons à notre contrôleur.
Puisqu’il y était spécifié qu’en cas de succès, nous devions aller voir le screenWidget
EditAssocNFacility, nous y allons.
Remarque : Il est possible d’avoir plusieurs blocs de ce type ne s’exécutant que sous certaines conditions, intervenant à d’autres moments, etc
3.2. Les widgets/screens widgets
3.2.1. Présentation générale.
Après moult péripéties, OfBiz est parvenu au widget suivant :3
F IG . 3.2.1. Exemple général de screen widget
1 <screen name="EditAssocNFacility">
2
<section>
3
<actions>
4
<set field="descriptionMain" value="NFacility"/>
5
<set field="headerItem" value="NFacility"/>
6
<set field="subComponent" value="nFacility"/>
7
<set field="possibleAdd" value="N"/>
8
<script location="component :
9
//facility/script/widgetActions/location/generated/EditAssocNFacility
10
.bsh"/>
11
12
//facility/script/widgetActions/location/developed/ViewContactMechs.
13
bsh"/>
14
<set field="titleProperty" value="PageTitleEdit${association}
15
AssocToNFacility"/>
16
<set field="descriptionListAssoc" value="NFacility${association}
17
List"/>
18
<set field="addItem" value="NFacilityAdd${association}"/>
19
<set field="selectionItem" value="Selection${association}"></set>
2c’est un cas de figure que nous choisissons
3pour nous et dans la continuation, il s’agit du widget EditAssocNFacility, du fichier locationScreens.xml
du composant facility
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
<set field="editAssocAddLink"
value="/EditAssocNFacilityContactMechAdding ?association=${
association}&amp ;actionForm=add&amp ;${assocPkParametersD}"/>
<set field="editAssocSelectLink"
value="/EditAssocNFacility ?association=${association}&amp ;
actionForm=selection&amp ;${assocPkParameters}"/>
</actions>
<widgets>
<section>
<condition>
<if-compare field-name="association" operator="equals"
value="stockItem"/>
</condition>
<actions>
<set field="tabButtonItem" value="nFacilityStockItem"/>
</actions>
<widgets>
<decorator-screen name="CommonEditAssocDecorator"
location="component ://facility/widget/facility/CommonScreens.
xml">
<decorator-section name="showMain">
<include-form name="showNFacility" location="component :
//facility/webapp/facility/location/generated/FormsNFacility.
xml"/>
</decorator-section>
<decorator-section name="subEdit">
<include-form name="subEditStockItemNFacility"
location="component :
//facility/webapp/facility/location/generated/FormsStockItem.
xml"/>
<decorator-section name="subList">
<include-form name="subListStockItemNFacilityD"
//facility/webapp/facility/location/developed/FormsStockItem.
xml"/>
</decorator-screen>
</widgets>
</section>
<section>
<condition><if-compare field-name="association" operator="equals"
value="product"/></condition>
<actions>
<set field="tabButtonItem" value="nFacilityproduct"/>
</actions>
<widgets>
xml">
<decorator-section name="showMain"><include-form
name="showNFacility" location="component :
xml"/></decorator-section>
<decorator-section name="subEdit"><include-form
name="subEditProductNFacilityNFacility" location="component :
//facility/webapp/facility/location/generated/FormsProductNFaci
lity.xml"/></decorator-section>
23
78
<decorator-section name="subList"><include-form
79
name="subListProductNFacilityNFacility" location="component :
80
//facility/webapp/facility/location/generated/FormsProductNFaci
81
lity.xml"/></decorator-section>
82
</decorator-screen>
83
</widgets>
84
</section>
85
<section>
86
<condition><if-compare field-name="association" operator="equals"
87
value="contactMech"/></condition>
88
<actions>
89
<set field="tabButtonItem" value="nFacilitycontactMech"/>
90
<set field="possibleSelect" value="Y"/>
91
<set field="possibleAdd" value="Y"/>
92
</actions>
93
<widgets>
94
95
96
xml">
97
<decorator-section name="showMain"><include-form
98
name="showNFacility" location="component :
99
100
xml"/></decorator-section>
101
<decorator-section name="subEdit">
102
<section>
103
<actions>
104
105
//facility/script/widgetActions/location/developed/EditAsso
106
ciationNFacilityContactMechSelectionTimeSheetTimeSheetRepor
107
t.bsh"/>
108
</actions>
109
<widgets>
110
<include-form name="subEditNFacilityContactMechNFacility"
111
112
//facility/webapp/facility/location/developed/FormsNFacilit
113
yContactMech.xml"/>
114
</widgets>
115
</section>
116
117
<decorator-section name="subList">
118
<platform-specific>
119
<html>
120
<html-template location="component :
121
//facility/webapp/facility/location/developed/ViewContact
122
Mechs.ftl"/>
123
</html>
124
</platform-specific>
125
126
</decorator-screen>
127
</widgets>
128
</section>
129
</widgets>
130
</section>
131 </screen>
24
25
Un screen widget est un objet relativement souple, et puissant. Il est en mesure de
réaliser des tests, d’appeler des scripts BeanShell, de modifier directement le contexte du
serveur, d’inclure d’autres widgets, d’inclure des formulaires, des fichiers ftl, etc. Pour
décrire les widgets, nous allons sagement suivre l’ordre dans lequel les différents blocs
apparaissent normalement.
Un screen widget peut contenir une section et une seule, mais une section peut contenir
d’autres sections (voir ??) dans ses widgets. La section est la pierre angulaire d’un screen,
car il est possible d’y réaliser des tests (voir 3.2.1.1), des actions (voir 3.2.1.2) et d’y placer
des widgets (voir 3.2.1.3 page suivante) ou des fail-widgets.
Il faut bien garder à l’esprit que les widgets/screens widgets sont conçus pour l’affichage.
3.2.1.1. Les tests.
L’utilisation de ces tests permet de tenir compte de ce qui s’est passé avant l’appel du
widget, par exemple après le traitement effectué par un service. Dans le code du widget
de la figure 3.2.1 page 22, aux lignes 86 − 87, on teste la valeur de la variable association
afin de savoir s’il l’on est en train d’associer ce NFacility à un contactMech (pour comprendre la sémantique de ce test voir les « Us et coutumes des widgets OfBiz/Néogia » de
la section 3.3 page 28).
Encadrés par la balise condition, et directement inclus dans une section, les tests permettent de réaliser les opérations booléennes de base (ou, et, négation) ainsi que la différence symétrique (xor) sur les traitements exemples suivants (d’autres traitements sont
possibles voir la D . T. D .) :
– une variable est-elle présente dans le contexte :
<if-empty field-name="VARIABLE"/>
– une variable du contexte a-t-elle une valeur particulière :
<if-compare value="VALEUR" field-name="VARIABLE" operator="equals"/>
Remarque : Ces tests conditionnent évidemment le reste du traitement de la section considérée. Si la
valeur booléenne resultant de l’évaluation est vrai alors la suite de la section est traitée.
Dans le cas contraire, le reste de la section est ignoré à l’exception d’un bloc fail-widgets,
bloc qui est un widget comme un autre (voir 3.2.1.4 page 28). Un exemple détaillé est
présenté plus loin, voir la section 3.3.2.3 page 30
3.2.1.2. Les actions.
Elles sont nombreuses et permettent de faire à peu près tout ce que l’on veut :
– modifier ou créer des variables dans le contexte
<set field="VARIABLE" value="VALEUR"/>
– associer/ajouter une ressource à une map
<property-map resource="RESSOURCE" map-name="MAP" global="true"/>
– appeller un service
26
<service service-name="SERVICE"><field-map env-name="ENTREE"/></service>
– appeller un script BeanShell
<script location="component ://<composant>/<chemin>/<nom du fichier>.bsh"/>
– recherche simple avec clef primaire
1 <entity-one entity-name="ENTITY" value-name="CLEF">
2 <field-map env-name=""/>
3 <select-field field-name=""/>
4 </entity-one>
5
qu’il faut lire comme ceci :
numéro de ligne
1
cherche un enregistrement dans l’entité ENTITY, avec la clef CLEF
résultats à stocker dans
2
3
on sélectionne les attributs de la liste
– gérer des fichiers properties4
<property-map resource="NOMdeFichier" map-name="" global=""/>
3.2.1.3. Les widgets.
Même s’il a des possibilités très larges (puisqu’il put inclure des sections), le widget
est spécialisé dans l’affichage d’information. Pour ce faire, il est en mesure de :
– définir des conténaires :
<container style="contentarea" id=""></container>
<content content-id=""></content>
ces conténaires peuvent être vu comme des boîtes div en HTML, et en conséquence, l’attribut style définirait la classe de la boîte et l’attribut id définirait l’id.
Remarque : Même s’ils sont utilisés de cette manière, i.e. génération de code HTML, rien n’empêche
que ces conténaires soient interprétés différemment par un autre moteur d’affichage
– Les ancres :
définition de l’ancre :
<decorator-section-include name=""/>
4fichier properties (dans classpath) mécanisme standard JAVA
27
utilisation de l’ancre : <decorator-screen name="">
<decorator-section name=""></decorator-section>
</decorator-screen>
Les ancres permettent de définir un endroit où un autre widget peut être inséré.
Ce mécanisme est particulièrement utilisé par les décorateurs, qui fournissent des
points d’ancrage aux widgets. Par exemple, la portion de code du widget CommonEditAssocDecorator de la figure 3.2.2.
1 <container style="column-right-fix">
2
<section>
3
< !– Sub Edit –>
4
<condition>
5
<not><if-empty field-name="actionForm"/></not>
6
</condition>
7
<actions>
8
<property-map resource="WidgetUiLabel"
map-name="uiLabelMap"/>
9
<set field="uiLabelButton"
value="${uiLabelMap.Widget${actionForm}
10
Button}" global="true"/>
11
</actions>
12
<widgets>
13
<container style="boxoutside">
14
<container style="boxtop">
15
<label style="boxhead"> ${uiLabelMap.Manufacturing${
16
actionFormLabel}}
17
</label>
18
</container>
19
<decorator-section-include name="subEdit"/>
20
</container>
21
</widgets>
22
</section>
23 </container>
F IG . 3.2.2. extrait d’un décorateur
Ce code définit à la ligne 19 la possibilité d’inclure un widget. Vous remarquerez l’utilisation des conténaires, ligne 1, 13, 14, qui permettent de contrôler l’affichage. Il n’y a plus alors qu’à indiquer que vous utilisez l’ancre subedit (ligne 101
de la figure 3.2.1 page 22) du widget CommonEditAssocDecorator (ligne 94 de la
même figure).
– inclure des formulaires (voir 3.4 page 33 pour plus d’information concernant les
formulaires) :
<include-form location="" name=""></include-form>
3.3. US ET COUTUMES DES WIDGETS OFBIZ/NÉOGIA
28
– inclure d’autres screens widgets :
<include-screen name=""></include-screen>
Remarque : les widgets ne sont lus que si le bloc de test présent dans la même section qu’eux rend
vrai après évaluation (voir 3.2.1.1 page 25), sinon c’est le bloc fail-widget qui est lu
(voir 3.2.1.4)
3.2.1.4. Les fail-widgets.
il s’agit de widgets parfaitement classiques (donc voir 3.2.1.3 page 26), mais ils ne
seront utilisés que si le bloc de test, présent dans la même section qu’eux, a rendu faux
après évaluation.
3.3. Us et coutumes des widgets OfBiz/Néogia
3.3.1. Préambule.
3.3.1.1. Sémantique.
Étant donné que tout le travail effectué par l’équipe N ÉRÉIDE est orienté modélisation,
il est nécessaire de prendre quelques lignes pour présenter quelques concepts.
L’entité, ou classe si l’on pense U . M . L ., ou table si l’on pense base de donnée est la
sémantique cachée derrière les écrans classiques qui vont suivre. La figure ?? page ?? sera
donc référencée dans la suite de cette section pour bien fixer les liens entre modélisation et
implémentation.
AD
D
A
AB2
AB1
B
F IG . 3.3.1. Associations multiples
3.3.1.2. Des us et coutumes ?
Il y a deux raisons différentes qui justifient cette section. La première est que le framework N ÉOGIA s’appuie sur des générateurs de code, qui outre la génération de code
29
JAVA , génèrent aussi les interfaces utilisateurs, pour peu que la modélisation l’ait spécifié.
Or l’ensemble des interfaces générées respectent certaines règles qu’il est nécessaire de
comprendre afin de pouvoir les modifier de façon cohérente et compréhensible pour tous.
La deuxième raison est, celle commune à tout développement : ces conventions guident
le développeur lors de la conception de dialogue et permettent le travail ultérieur d’autres
développeurs.
3.3.2. Les écrans types.
Il existe différents types d’écrans classiques dans le framework N ÉOGIA, qui répondent
à des besoins spécifiques, et nous allons les présenter, en nous appuyant sur un diagramme
U . M . L ., présentant quelques cas de figures. Pour tout ce qui est commun à l’ensemble des
widgets (i.e. des variables positionnées dans le contexte, etc, il faut aller voir 3.3.3 page 32),
puisque dans les paragraphes suivants l’on ne présente que les utilisations types des widgets et leurs spécificités.
De plus dans le cadre de cette rédaction, nous allons désigner certaines parties de
l’écran selon la figure 3.3.2.
F IG . 3.3.2. Les différents types de boîtes
3.3.2.1. Écran type "création/édition".
F IG . 3.3.3. écran type "création/édition"
Il s’agit de tous les screens widgets ayant un nom commençant par Edit puis suivis
par le nom d’une entité. Ces screens widgets sont très simples puisqu’ils ne comportent
30
qu’un seul formulaire (pour information sur les formulaires voir 3.4 page 33), avec comme
décorateur « CommonEditDecorator ». Ils servent à créer un exemplaire d’une entité, ainsi
le screen widget « EditProject » permet de créer un projet.
D’un point de vue modélisation U . M . L ., la création d’un projet correspond à l’instantiation des classes A ou B.
3.3.2.2. Écran type "visualisation".
Il s’agit d’une copie de l’écran précédent, et diffère en ce qu’il est impossible de
modifier l’enregistrement
3.3.2.3. Écran type "list/recherche".
F IG . 3.3.4. Écran type "list/recherche" : recherche
F IG . 3.3.5. Écran type "list/recherche" : résultat
il s’agit d’un écran permettant de faire des recherches sur une entité5. L’affichage
tantôt liste tantôt recherche est réalisé par le « CommonListDecorator », celui n’affichant
que les formulaires associés aux variables showList et hideSearch du contexte. Il
s’agit là d’un excellent exemple d’affichage conditionnel, les variables étant positionnées
par le formulaire find. Voici dans l’ordre ce qui se passe :
– le décorateur, ici « CommonListDecorator », positionne dans les variables showList
et hideSearch du contexte des valeurs présentes dans la requête ou des valeurs
par défaut :
5il n’est donc pas possible, sans modification évidemment, de réaliser des recherches sur plusieurs entités
différentes
31
<set field="hideSearch" from-field="parameters.hideSearch" default-value="N"/>
<set field="showList" from-field="parameters.showList" default-value="N"/>
– le formulaire find est alors le seul affiché, car leur affichage respectif est conditionné
par les tests suivants :
<if-compare field-name="hideSearch" operator="equals" value="N"/>
<if-compare field-name="showList" operator="equals" value="N"/>
– puis finalement, le formulaire positionne dans la future requête, après que l’utilisateur ait validé le formulaire, les variables hideSearch et showList, de la
manière suivante :
<field name="hideSearch"><hidden value="Y"/></field>
<field name="showList"><hidden value="Y"/></field>
Ce qui aura pour effet, d’afficher la liste et non pas la recherche
Remarque : pour plus d’information concernant les formulaires voir la section 3.4 page 33.
D’un point de vue modélisation U . M . L ., une recherche revient à chercher les intantiations, suivant différents critères, des classes A ou B.
3.3.2.4. Écran type "lookup".
Bien que traités différemment des autres screens, dans le sens où les lookup ont
droit à leurs propres fichiers (voir aussi 2 page 35), ils n’ont rien de différents, leur seule
particularité étant d’être affichée dans une fenêtre à part.
3.3.2.5. Écran type "édition d’association".
F IG . 3.3.6. écran type "édition d’association"
il s’agit de tous les screens widgets ayant un nom comportant le mot « EditAssociation
». Ces écrans sont beaucoup plus complexes que les précédents du fait qu’un même widget
puisse servir pour plusieurs associations, en conséquence de quoi il est nécessaire de disposer d’un discriminateur, et il s’agira d’une variable qui doit être placée dans la requête :
association. Par exemple dans la section 3.1 page 20, le traitement d’une requête est
expliqué, et la requête exemple contenait la chaîne suivante « association=contactMech »,
ce qu’il faut traduire par « nous allons traiter la relation avec un contectMech ».
Pour généraliser, prenons le diagramme U . M . L . de la figure 3.3.1 page 28. Si l’on
désire ajouter un doublet A/D, et que l’on parte de l’entité A, nous obtiendrions alors la
requête suivante :
32
[...]EditAssocA ?association=contactMech&actionForm=selection&aIdName=[...]
Le meilleur exemple est le code disponible dans la figure 3.2.1 page 22, qui est celui
d’un tel widget. Les lignes 30/31, 61/62, 86/87 sont les tests effectués afin de déterminer
l’association qui devra être traitée.
3.3.3. Les variables.
Tout ce que nous avons vu jusqu’ici l’a été sous un oeil strictement technique, ce qui
n’est pas le cas de ce qui va suivre. En effet, la description du fonctionnement des widgets
ne permet pas de comprendre le contenu des différents fichiers présents dans le projet (par
exemple : <set field="tabButtonItem" value="nFacilitycontactMech"/>
vous seriez bien dans l’embarras, ne sachant par où commencer, et quoi faire.
Prenons tout d’abord, la figure 3.2.1 page 22, vu plus tôt.
Parlons ensuite des variables positionnées dans le contexte (nous parlons des « set »,
donc du bloc action) :
– descriptionMain (ligne 4)
cette variable permet, dans le cas d’une utilisation d’un « CommonEditAssocDecorator », de fabriquer un UiLabel (voir le screen « CommonEditAssocDecorator
» du fichier CommonScreens.xml pour avoir l’UiLabel créé exact) qui sera utilisé
comme titre de la boîte type 1
– headerItem (ligne 5)
cette variable sert dans la désignation du fichier qui définit la barre de menu
pour un composant sélectionné (via l’onglet donc)
– subComponent (ligne 6)
cette variable indique, par un jeu de feuille de style, quel bouton de la barre de
menu doit être allumé
– possibleAdd (ligne 7)
cette variable permet de dire si pour ce widget, l’affichage de la boîte de type 2
doit être réalisé
– titleProperty (lignes 14/15)
cette variable participe au titre de la fenêtre du navigateur
– descriptionListAssoc (ligne 16)
fonctionne comme descriptionMain et rempli le même rôle, mais concerne
la boîte de type 2
– addItem et value="NFacilityAdd${association}" (ligne 18)
définit l’UiLabel qui sert de description au lien d’ajout dans la boîte de type 2
(voir le screen « CommonEditAssocDecorator » pour avoir l’UiLabel exacte créé)
– selectionItem et value="Selection${association}" (ligne 19)
identique à addItem à ceci près qu’il concerne le lien de selection dans la
boîte de type 2
– Les liens (lignes 20 à 25) :
editAssocAddLink et value=[...]
editAssocSelectLink et value=[...]
il s’agit des liens qui seront affichés pour permettre l’ajout dans la boîte de type
3
3.4. LES « FORM », OU FORMULAIRES
33
3.4. Les « Form », ou formulaires
Les "form" désignent des mécanismes de créations automatiques de formulaires. Ils
ressemblent quelque peu à leur cousin (la famille quoi), mais diffèrent en ce qu’ils ne
disposent pas de la possibilité de bloc conditionnel, et peuvent afficher des formulaires
évidemment.
La figure 3.4.1montre un exemple de formulaire.
1 <form name="subListWRunProjectD" type="list"
list-name="entityList"
2
extends="subListWRunProject"
3
extends-resource="component :
4
//manufacturing/webapp/manufacturing/jobshopmgt/generated/FormsWRun.
5
xml">
6
<actions>
7
<service service-name="performFind" result-map-name="result"
result8
map-list-iterator-name="listIt">
9
<field-map field-name="inputFields"
env-name="mainPKeyValues"/>
10
</service>
11
</actions>
12
<field name="deleteLink" ><hidden/></field>
13
<field name="submitButton" ><hidden/></field>
14 </form>
F IG . 3.4.1. Exemple de formulaire
3.4.1. Le cadre d’utilisation.
Ils servent évidemment lorsqu’il s’agit de récupérer des informations de l’utilisateur,
mais même si l’on utilise le mot de formulaire, ceux-ci peuvent avoir des usages qui
semblent éloignés des formulaires :
dans une liste d’éléments comme présent sur la capture de la figure 3.3.5 page 30, chaque
ligne correspond à un formulaire, au sens du html, et la liste elle-même est inclue dans un
formulaire, au sens widget.
3.4.2. Notion d’héritage.
Les formulaires peuvent utiliser une sorte d’héritage, qui leur offre de la souplesse
d’utilisation :
un formulaire hérité d’un autre dispose de tous les champs de celui-ci, il est alors ainsi
possible de changer l’ordre d’affichage des éléments, d’en cacher certains, d’appeler des
services différents, etc.
3.4.3. Les attributs de la balise form elle-même. Vous vous rendrez compte que
cette balise est une de celle qui a le plus d’attributs, et ce sera aussi, malheureusement la
moins détaillée, et ce pour trois raisons :
– dans le cadre de développement N ÉOGIA, très peu d’éléments de l’ensemble des
possibilités des formulaires sont utilisés ou modifiés
34
– à l’heure où sont écrites ces lignes, il y a du travail en cours de réalisation/finition
sur les formulaires par l’équipe OfBiz (certaines choses ne fonctionnent pas, etc)
– une documentation absente et un nombre d’options très important
Nous allons donc présenter les attributs les plus usités :
– name : le nom du formulaire
– type : [list|single]
– list
les données seront affichées sous forme d’une liste, ou plus précisément la
destination de cette forme est d’afficher une liste d’objet (par exemple tous
les prix d’un article), qui doit être disponible via un itérateur ou une map,
etc, et les champs spécifiés dans le formulaire seront alors remplis automatiquement
– single, affichage généraliste
– target
cible du formulaire, c’est à dire l’url à laquelle doivent être envoyées les données du formulaire
– default-map-name, default-entity-name, default-service-name
permet de préciser le nom de map/entité/service par défaut, ceux-ci servant à
économiser la répétition d’information
– list-iterator-name
précise le nom de l’itérateur qui sera utilisé pour le parcours d’une liste
3.4.4. Ce que peut contenir un formulaire (i.e. les éléments qui peuvent être imbriqués dans le formulaire).
3.4.4.1. Les éléments simples.
– alt-target
permet de changer la cible par défaut du formulaire dans certaines conditions
prévues à l’avance, et il dispose donc d’un attribut use-when
– action
ce bloc permet l’appel de services, de scripts, etc pour information voir la section 3.2.1.2 page 25. Ce bloc est utilisé de manière classique pour réaliser le «
performFind », c’est à dire l’appel d’un service dans un lookup qui effectue la recherche
– field
vous rencontrerez très souvent celui-là puisque c’est lui qui crée les « input »
du document HTML qui sera généré, les informations qui seront affichées, en bref
c’est cet élément qui affiche. Le field a droit à son propre paragraphe voir 3.4.4.2
– sort-order
permet de changer l’ordre d’affichage dans un formulaire hérité, l’ordre étant
alors celui dans lequel les sous éléments sort-field sont placés
3.4.4.2. Le field.
Le field est donc un élément central dans un formulaire, puisque c’est lui qui est utilisé
pour placer des informations dans la page.
(1) Nous allons donc présenter les attributs les plus usités :
– name
le nom du champs, il sera utilisé pour nommer l’« input » correspondant,
dans le cas d’un formulaire « single »
– title
35
chaîne décrivant le champs, il sera utilisé pour nommer le champs de saisie correspondant, dans le cas d’une d’un formulaire « single »
– use-when
permet de spécifier quant sera utilisé ce champs
Remarque : à l’heure actuelle, l’équipe d’OfBiz travaille à l’amélioration
de cet élément, pour plus d’information, il faut consulter les
sources d’OfBiz, ou une hypothétique documentation
(2) Ce que peut contenir un field (i.e. les éléments qui peuvent être imbriqués dans
le field)
– display
permet l’affichage d’information à destination de l’utilisateur, mais ne servira pas pour la requête ultérieure
– hidden
permet de cacher des informations dans le formulaire, par exemple identité de l’utilisateur, informations qui serviront à la requête
– drop-down
permet d’afficher une combo, qu’il faudra évidemment alimenter avec des
données, données pouvant provenir de scripts personnels, ou d’entités
– date-time
permet l’affichage d’une boîte de saisie de date
– lookup
permet l’exécution d’une requête à un widget qui sera fait dans une fenêtre
à part, et de laquelle reviendront des informations. Il est généralement utilisé pour permettre à l’utilisateur de sélectionner facilement une référence
dans une liste
Conclusion
Le stage m’a été profitable à plus d’un titre :
– en premier lieu quitter le contexte de l’école. En effet, le travail n’a rien à voir
avec celui que l’on peut avoir à l’école, les relations aux collègues sont aussi très
différentes
– découverte du travail collaboratif. Même si j’avais touché par ailleurs à des outils
tels que Subversion et d’autres, je n’avais jamais travaillé sérieusement en équipe
– découverte du travail de développeur. J’ai réellement appréhendé le travail de développeur car le contexte de l’entreprise, n’a rien à voir avec celui de l’école ; le
développement à l’école ressemble à de minuscules tâches dans le sens où le travail
fourni n’est généralement pas utilisé, ce qui fait que les approximations quant au
travail sont permises, il n’y a pas de vision à moyen ou long terme de la vie d’un
logiciel, etc. Ma décision est arrêtée, je ne ferais pas de développement : pas assez
stimulant, car répétitif.
Concernant la génération de code, mon opinion reste mitigé, car si l’on est dans le cas d’une
gestion bien définie à l’avance de l’interface utilisateur (type de dialogue, etc), elle pourrait être intéressante6, dans le framework N ÉOGIA, elle n’est guère utile car elle produit
des interfaces très pauvres, peu réactives, et il est sans arrêt nécessaire de développer des
fenêtres spécifiques pour réaliser de vraies interfaces, au sens I . H . M .. Qui plus est pendant
toute la durée de stage, du fait de la complexité de conception de générateurs, beaucoup
d’erreurs dans la génération faisaient perdre bien du temps au lieu d’en économiser, mais
gageons que ce ne sont que des défauts de jeunesse.
En conclusion, je suis satisfait de mon stage, pas nécessairement du travail que j’ai
effectué (petites tâches à gauche et à droite, qualité générale de mon travail moyenne,
travail dépendant du contexte de l’entreprise), qui m’a permis de voir la petite entreprise7,
et permis de me fixer quant à ma spécialisation ultérieure.
6je ne tiens pas compte de la génération de code JAVA qui elle est toujours profitable à mon goût
7au sens P. M . E .
36
Résumé : Réalisation et intégration du module projet dans l’E . R . P. OfBiz/N ÉOGIA
Abstract : Realisation and integration of project managment in the OfBiz/N ÉOGIA E . R . P.
Société NÉRÉIDE
3bis les Isles
37270 Veretz
Encadré par
M. Olivier H EINTZ
Étudiant
E L I DRISSI M AJID
DI 2 année scolaire 2004/2005

Rapport de Stage de deuxième année Réalisation - Libre

Transcription

Documents pareils

Fiche Cours PDF - Ociensa Technologies

Book widgets

Tutoriel 2

LA GESTION DU BLOG PAR L`ADMINISTRATEUR

Tutoriel n°2 : Gestion des widgets de la sidebar sous WordPress

Thèmes Utilisation des widgets

Vérifiez l`heure exacte, consultez la météo, suivez un vol

c`est quoi? en quoi c`est nouveau? ça coûte combien? tabbee dans

Les widgets - WordPress.com

Facility Manager Contexte du recrutement et définition