HOWTO - Sashipa development
You wish to split up the gui components among several modules, for managing access rights by module. Or in order to avoid always loading all the software when you just need to print one little list.
The graphicalUserInterface element can contains several 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>
|
Now each screen, form, or printReport declared in the module 'modOther' will be generated in the module 'modOther'...
... except in a case: a form can be created in a screen but belong to another module than the screen one. Example:
<guiModule name='modDemoContact'>
<screenSet>
<screen name='SMMain'>
<menuForm belongsToGuiModule='modOther' ...
...
</screen>
...
</screenSet>
</guiModule>
<guiModule name='modOther'>
</guiModule>
|
... this code is equivalent to:
<guiModule name='modDemoContact'>
<screenSet>
<screen name='SMMain'>
<menuFormRef module='modOther' menuForm='FMproofOfConcept' />
...
</screen>
...
</screenSet>
</guiModule>
<guiModule name='modOther'>
<formSet>
<menuForm name='FMproofOfConcept' ...
</formSet>
</guiModule>
|
There is an attribute 'module' for each reference to screen, form and printReport. If a value hasn't been defined for an attribute 'module', the parent module is assumed.
In a guiInstance, guiModules that have to be generated are referenced in a binary unit.
<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>
|
Note that a guiModule can to not be referenced in a guiInstance. Then all the references to this guiModule from other modules will be ignored when generating the code of the guiInstance.
Default access rights for guiModules can be defined in the configuration server:
<server name='srvDemoContact_Total' type='embeddedInGui'>
<defaultAccessRight guiModule='modMain' type='using' />
<defaultAccessRight guiModule='modOther' type='readOnly' />
... element dbConnection ...
|
Remark: if a guiModule is not specified here, its default access right will be 'using'. (read-write acces)
Add to this, access rights can be defined for each user: cf this howto
When the software starts, first it asks for login and password (or tries to connect in anonymous). Then a user-profile is loaded from the configuration server. In this user-profile are described the access rights to guiModules. So the loader will try to load only the modules that the user is allowed to use or read.
A guiModule can be generated in a separate guiBinaryUnit (that product a jar file). When the software starts, it tries to load each authorized guiModule. If the jar file that contains an authorized guiModule is missing, the loader will continue starting without this module.
© Copyright 2004 Sashipa-Melba Team. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License as much as this note clearly appears.