HOWTO développement Sashipa
Lorsque l'on crée une application, le fichier source XML est inclus dans le fichier jar généré. C'est pratique : on ne risque plus de perdre le code source. Mais c'est aussi dangereux puisque ce fichier contient en clair les informations de connexion. Le mieux est donc d'externaliser les éléments sensibles, puis d'y faire référence depuis le fichier XML principal.
Cela se fait simplement en utilisant la technique des entités XML. On crée tout d'abord un fichier XML, appelons-le demo_connexion.xml. Voici son contenu :
<?xml version='1.0' encoding='ISO-8859-1' ?> <user>theLogin</user> <password>thePassword</password> |
Puis nous revenons à notre fichier source principal. En tête de fichier nous ajoutons le nouveau fichier comme une entité :
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE application SYSTEM 'resources/sashipa.dtd' [
<!ENTITY br '
'>
<!ENTITY nbsp ' '>
<!ENTITY frenchDefinition SYSTEM 'resources/SashipaFrench.xml'>
<!ENTITY englishDefinition SYSTEM 'resources/SashipaEnglish.xml'>
<!ENTITY germanDefinition SYSTEM 'resources/SashipaGerman.xml'>
<!ENTITY demoConnexion SYSTEM 'demo_connexion.xml'>
]>
|
Il ne nous reste plus qu'à utiliser cette entité dans notre élément dbConnection :
<dbConnection type='odbc' dbmsType='MySQL'>
<dbConnectionString>DsnDemo</dbConnectionString>
&demoConnexion;
</dbConnection>
|
Le mécanisme des entités XML est similaire à une inclusion par copier/coller au moment du parsing (de la lecture) du fichier XML.
Notez cependant que cette opération n'est qu'une forme de répartition du code source. Si vous changez les informations de connexion, ça ne vous dispense pas de recompiler.
De plus, il faut savoir que le login et le mot de passe sont aussi en clair dans le fichier compilé Java (.class) qui s'occupe des accès à la base de données. Dans le cas d'une architecture de type client-database on ne peut pas y faire grand chose. En revanche, avec une architecture client-servlet-database, vous pouvez dézipper le fichier jar, retirer les deux fichiers de la servlet (XXXServlet.class, XXXServletAnalyser.class), puis reconstruire le fichier jar (cf commande en ligne 'jar' dans le J2SDK).
On définit les paramètres par défaut des champs dans l'élément defaultParameterSet. Pour chaque type de paramètre, on définit une valeur applicable à tous (applyOn='field') et/ou à tous les fk-fields (applyOn='fkField'). De plus, on peut préciser une valeur pour chaque champ en particulier (exemple : applyOn='comboBoxFkField').
Lorsque un champ cherche sa valeur par défaut, il prend la valeur la plus précise qu'il puisse trouver. Par exemple, un comboBoxFkField qui cherche sa taille, (type='size') va prendre celle définie dans applyOn='comboBoxFkField'. Si elle n'existe pas, il prendra celle de applyOn='fkField' et à défaut, celle de applyOn='field'.
Les couleurs se définissent dans les paramètres par défaut, au format RGB (Rouge Vert Bleu) en hexadécimal. On définit une couleur par ses composantes dans ces trois couleurs, entre 0 et ff.
Le composant textAreaField (applyOn='textAreaField') supporte un paramètre qui lui est spécifique pour passer à la ligne automatiquement : wordWrap. La valeur est de type booléenne.
Il est possible de définir des fichiers journaux, qui seront mis à jour par la partie serveur de votre application. On les définit dans l'élément logStorage de la partie server du fichier source.
...
</dbConnection>
<logStorage>
<mainLog><logFileStorage>
<uri>Melba_DemoContact_Main.log</uri>
</logFileStorage></mainLog>
<updateLog><logFileStorage>
<uri>Melba_DemoContact_Update.log</uri>
</logFileStorage></updateLog>
<selectLog><logFileStorage>
<uri>Melba_DemoContact_Select.log</uri>
</logFileStorage></selectLog>
</logStorage>
|
Il y en a trois, chacun est facultatif :
Le log Main historise les informations d'ouverture et de fermeture de sessions (ie. de lancement/fermeture des applications clientes). Notez que dans le cas d'une configuration client-servlet-database, les informations journalisées dans ce fichier, le sont aussi dans le journal de votre container de servlets (Tomcat ou autre).
Le log Update historise les requêtes de mise à jour : les requêtes SQL de type INSERT, UPDATE et DELETE.
Le log Select historise les requêtes SQL de sélection (type SELECT). Ce log est très pratique - pour ceux qui maîtrisent le SQL - pour déboguer et vérifier que les requêtes générées sont correctes. En revanche, je ne recommande pas de le laisser en production.
Vous pouvez spécifier que votre application transforme (et affiche !) l'intégralité de son contenu en majuscules ou en minuscules. Cela se fait simplement en modifiant un paramètre par défaut :
<defaultParameter applyOn='textFormat' type='valueModifier'>upperCase</defaultParameter> |
Vous avez le choix entre les valeurs lowerCase, upperCase et nothing (par défaut).
En complément (ou indépendamment), vous pouvez aussi faire en sorte que les comparaisons pour les critères de recherche soient insensibles à la casse :
<defaultParameter applyOn='textSchemaColumn' type='criteriaCaseSensitive'>no</defaultParameter> |
Si l'application que vous développez est une application en lecture-seule, vous retirerez dans le source les boutons d'ajout dans les menus, les requêtes de mise à jour dans les cardForm (cardSchemaTableRef ... queries='s'), les boutons d'ajout des listForm (l'élément insertScreen) et ceux des fkFields.
Pas de problèmes...
En revanche, si vous avez développé une application complète, peut-être que vous apprécierez de pouvoir générer une version en lecture-seule, sans pour autant modifier tout le code source.
Cette opération se fait le plus simplement du monde en définissant une guiInstance comme étant en lecture-seule :
<architecture>
... vos guiInstance précédentes ...
<guiInstance name='guiConsultation' type='application' readOnly='yes'>
... le même contenu que les autres guiInstance ...
|
L'application générée pour cette guiInstance ne contiendra pas le code pour la mise à jour.
Notez qu'un attribut 'readOnly' est disponible aussi pour l'élément 'server'. De la même manière, cet attribut supprime du serveur tout code de mise à jour et la servlet n'acceptera que des requêtes en lecture.
Voilà un bout de code généré automatiquement par Database2Sashipa, mais ça n'empèche pas de le comprendre :
<screen name='SMMain'>
<title>Base Démo</title>
<formSet>
<menuForm>
<menuTitle height='70'>Base Démo</menuTitle>
<firstButtonLocation x='100' y='150' />
<buttonSize w='400' h='36' verticalGap='18' />
<menuButtonList>
...
</menuButtonList>
<menuComeBackButton />
</menuForm>
</formSet>
<screenComeBackButton enable='no' />
</screen>
|
Tout d'abord il faut savoir que chaque écran dispose d'un bouton comeBack, sauf lorsqu'on précise le contraire (comme ici : screenComeBackButton enable='no').
Le libellé du bouton est "Quitter" pour le premier écran de l'application et "Revenir" pour tous les autres. Ces deux libellés sont définis - comme tous les autres libellés - dans le fichier de langage (<melbalab-home>/src_xml/resources/SashipaXXX.xml).
Un menuForm peut afficher un bouton 'comeBack' en dernière position. Il suffit pour ce d'ajouter l'élément vide menuComeBackButton. Ce bouton prendra sa valeur selon le même principe que le bouton comeBack de l'écran.
Vous pouvez aisément ajouter un nouveau langage à la technologie Sashipa-Melba, sans développer quoi que ce soit.
1) Traduire un des fichier de langage.
Tous les messages et libellés sont définis dans un unique fichier de langage. Aussi, faîte une copie d'un des fichiers <melbalab>/src_xml/resources/SashipaXxx.xml puis éditez la copie. Prenez garde à l'encodage. Traduisez tous les contenus de balises dans le nouveau langage. Mais attention à ne pas modifier un nom de balise ou d'attribut, ni une valeur d'attribut ! Traduisez uniquement le contenu des balises.
Ensuite, il y a une (seule) valeur d'attribut à changer, il faut donner un nom au premier élément:
<languageDefinition name='yourNewLanguage'> |
2) Dans l'application Sashipa: ajouter le langage comme une entité.
Dans votre application Sashipa, en début de fichier, vous ajoutez votre nouveau fichier de langage :
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE application SYSTEM 'resources/sashipa.dtd' [
<!ENTITY br '
'>
<!ENTITY nbsp ' '>
<!ENTITY frenchDefinition SYSTEM 'resources/SashipaFrench.xml'>
<!ENTITY englishDefinition SYSTEM 'resources/SashipaEnglish.xml'>
<!ENTITY germanDefinition SYSTEM 'resources/SashipaGerman.xml'>
<!ENTITY yourNewLanguageDefinition SYSTEM 'resources/SashipaYourNewLanguage.xml'>
]>
|
2) Dans l'application Sashipa: utiliser le nouveau fichier de langage.
Dans votre application Sashipa, dans la partie architecture, vous pouvez maintenant utiliser la nouvelle entité:
<architecture>
...
<languageDefinitionSet mainLanguageDefinition='yourNewLanguage'>
&yourNewLanguageDefinition;
</languageDefinitionSet>
</architecture>
|
NB : Pour ajouter un nouveau langage au programme Database2Sashipa, il est encore nécessaire de modifier un fichier source Java (databasesashipa/Database2Sashipa.java) et de recompiler. Désolé...
Important : une fois que vous avez traduit le fichier de langage dans un nouveau langage, partagez votre travail pour les autres utilisateurs svp.
Certains SGBD définissent des types de données 'booléen'. Par défaut, lorsque vous spécifiez une colonne comme booléenne dans un source Sashipa, le formatteur associé essaiera de travailler avec le type booléen du SGBD. Si vous stockez vos booléens en base sous forme d'entiers, vous pouvez le spécifier dans le code comme ceci :
<database name='dbDemoContact'>
<physicalName>DemoContact</physicalName>
<singularName>Demo Contact</singularName>
<dbConfig booleanStoredAsInteger='yes' />
...
|
Vous pouvez rencontrer ce besoin si vous migrez une base de Oracle vers PostGreSQL par exemple.
© Copyright 2003 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.