HOWTO développement Sashipa
Vous souhaitez répartir les composants de l'IHM en plusieurs modules, pour gérer des droits d'accès par modules. Ou pour éviter de charger à chaque lancement l'intégralité d'une grosse application.
L'élément graphicalUserInterface peut contenir un ensemble de guiModules :
<graphicalUserInterface>
... guiStarting ...
<guiModule name='modDemoContact'>
... optional element screenSet ...
... optional element formSet ...
... optional element printReportSet ...
</guiModule>
<guiModule name='modOther'>
... optional element screenSet ...
... optional element formSet ...
... optional element printReportSet ...
</guiModule>
... defaultParameterSet ...
</graphicalUserInterface>
|
Chaque screen, form, ou printReport déclaré dans le module 'modOther' sera généré dans le module 'modOther'...
... sauf dans un cas : un form peut être créé dans un screen tout en appartenant à un autre module que celui du screen. Exemple :
<guiModule name='modDemoContact'>
<screenSet>
<screen name='SMMain'>
<menuForm belongsToGuiModule='modOther' ...
...
</screen>
...
</screenSet>
</guiModule>
<guiModule name='modOther'>
</guiModule>
|
... ce code est équivalent à :
<guiModule name='modDemoContact'>
<screenSet>
<screen name='SMMain'>
<menuFormRef module='modOther' menuForm='FMproofOfConcept' />
...
</screen>
...
</screenSet>
</guiModule>
<guiModule name='modOther'>
<formSet>
<menuForm name='FMproofOfConcept' ...
</formSet>
</guiModule>
|
Il existe un attribut 'module' pour chaque référence vers un screen, form et printReport. Si la valeur de cet attribut n'est pas définie, elle prendra par défaut celle du module parent.
Dans une guiInstance, les guiModules qui seront générés sont référencés depuis les éléments des unités binaires (guiBinaryUnit ou guiLoaderBinaryUnit).
<guiInstance name='guiDemoContact' type='application'>
... used servers ...
<guiLoaderBinaryUnit>
<binaryUnitResourceName>GuiDemoContact</binaryUnitResourceName>
<usedGuiStarting guiStarting='startingMain' default='yes' />
</guiLoaderBinaryUnit>
<guiBinaryUnit containsGuiCommon='yes' copySourceOfApplication='yes'>
<binaryUnitResourceName>GuiDemoContact_Common</binaryUnitResourceName>
<usedGuiModule guiModule='modDemoContact' />
<usedGuiModule guiModule='modOther' />
</guiBinaryUnit>
</guiInstance>
|
Notez qu'un guiModule peut ne pas être référencé dans une guiInstance. Dans ce cas aucun code ne sera généré pour ce module et toutes les références des autres modules vers ses composants seront ignorées.
Les droits d'accès par défaut des guiModules sont définis dans le serveur de configuration :
<server name='srvDemoContact_Total' type='embeddedInGui'>
<defaultAccessRight guiModule='modMain' type='using' />
<defaultAccessRight guiModule='modOther' type='readOnly' />
... element dbConnection ...
|
Remarque : si le droit d'accès par défaut pour un guiModule n'est pas spécifié ici, la valeur utilisée sera 'using'. (accès en lecture-écriture)
Les droits d'accès peuvent aussi être définis au cas par cas par utilisateur : cf la howto qui va bien
Quand le logiciel démarre, il commence par demander un login et un password (ou essaye de se connecter en anonyme). Puis le profil de l'utilisateur est chargé depuis le serveur de configuration. Dans ce profil sont décris les droits d'accès aux guiModules. Aussi le chargeur de l'application essaiera de charger uniquement les modules sur lesquels l'utilisateur à des droits 'using' ou 'readOnly'.
Un guiModule peut être généré dans une unité binaire séparée qui produira donc un fichier Jar séparé. Quand le logiciel démarre, il essaye de charger tous les guiModules ausquels à droit l'utilisateur. Si le fichier jar d'un guiModule autorisé est absent, le chargeur continue sans ce module.
© Copyright 2004 Sashipa-Melba Team. Ce document de la technologie Sashipa-Melba est sous licence GNU FDL Vous pouvez le copier et modifier librement les copies tant que cette mention apparaît clairement.