1. Introduction > 2. Mon premier projet > 3. Modèle > 4. Vue > 5. Liste de données > 6. Mapping objet/relationnel > 7. Contrôleurs > 8. Application > 9. Personnalisation

Chapitre 8. Application

Une application est le logiciel avec lequel que l'utilisateur final interagit. Jusqu'ici, le guide de référence a défini les pièces qui composent une application (principalement les composants et les actions). A présent, voyons comment assembler ces pièces pour créer une application. La définition d'une application OpenXava est contenue dans le fichier application.xml qui se trouve dans le dossier xava de votre projet.
La syntaxe du fichier est comme suit :
<application
    name="name"                   <!-- 1 -->
    label="label"                 <!-- 2 -->
>
    <default-module ... /> ...    <!-- 3  New in v2.2.2 -->
    <module ... /> ...            <!-- 4 -->
</application>
  1. name (obligatoire) : Le nom de l'application
  2. label (optionnel) : Utilisez plutôt les fichiers i18n
  3. default-module (un, optionnel) : Nouveau depuis v2.2.2. Les contrôleur pour les modules par défaut (généré automatiquement pour chaque composant)
  4. module (plusieurs, optionnel) : Chaque module exécutable par l'utilisateur final
Bref, une application est un ensemble de modules. Voici comment déclarer un module :
<module
    name="name"                    <!--  1 -->
    folder="folder"                <!--  2 -->
    label="label"                  <!--  3 -->
    description="description"      <!--  4 -->
>
    <env-var ... /> ...            <!--  5 -->
    <model ... />                  <!--  6 -->
    <view ... />                   <!--  7 -->
    <web-view ... />               <!--  8 -->
    <tab ... />                    <!--  9 -->
    <controller ... /> ...         <!-- 10 -->
    <mode-controller ... />        <!-- 11 -->
    <doc ... />                    <!-- 12 -->
</module>
  1. name (obligatoire) : Le nom du module unique au sein de cette application
  2. folder (optionnel) : Dossier dans lequel réside le module. Une astuce est de classer les modules. Pour l'instant, cet attribut est utilisé pour générer une structure de dossiers pour le portail JetSpeed2 mais son utilisation pourra être étendue dans le futur. Il est possible d'utiliser des "/" ou des "." pour identifier les sous-dossiers (par exemple facturation/rapports ou facturation.rapports)
  3. label (optionnel) : Nom court affiché à l'utilisateur. Utilisez plutôt les fichiers i18n
  4. description (optionnel) : Description longue affichée à l'utilisateur. Utilisez plutôt les fichiers i18n
  5. env-var (plusieurs, optionnel) : Définition d'une variable et de sa valeur, accessible par les actions. Ainsi, vous pouvez avoir des actions configurées par module
  6. model (un, optionnel) : Nom du composant utilisé dans ce module. S'il n'est pas défini, il est obligatoire de déclarer web-view
  7. view (un, optionnel) : Nom de la vue qui doit être utilisée dans l'édition de détail. S'il est absent, la vue par défaut est utilisée
  8. web-view (un, optionnel) : Page JSP utilisée comme vue
  9. tab (un, optionnel) : L'affichage utilisé en mode liste. S'il n'est pas spécifié, celui par défaut est utilisé
  10. controller (plusieurs, optionnel) : Les contrôleurs avec les actions utilisées initialement
  11. mode-controller (un, optionnel) : Comportement lors du passage de l'affichage des liste à l'affichage de détail et vice-versa. De même, il est possible de définir un module avec uniquement un affichage de liste ou de détail. Please, translate the next sentence to French: New in v4m5: There is a new mode, split. Since v4m5 the available mode controllers are Mode (detail - list - split), DetailList, DetailOnly, ListOnly and SplitOnly.
  12. doc (un, optionnel) : Mutuellement exclusif avec tous les autres éléments. Déclaration d'un module qui ne contient que de la documentation et aucune logique. Utile pour générer des portlets informationnels pour votre application

Un exemple de module typique

Un module typique peut ressembler à ceci :
<application name="Management">
    <module name="Warehouse" folder="warehousing">
        <model name="Warehouse"/>
        <controller name="Typical"/>
        <controller name="Warehouse"/>
    </module>
    ...
</application>
Dans ce cas, vous avez défini un module qui permet à l'utilisateur de créer, rechercher, modifier et supprimer des objets, de générer des rapports PDF ou d'exporter des données des entrepôts (Warehouse) vers Excel grâce au contrôleur Typical. En outre, il définit des actions propres à la gestion des entrepôts grâce au contrôleur Warehouse. Notez aussi que, si le système génère une structure de module, comme dans JetSspeed2, ce module sera placé dans le dossier warehousing.
Afin d'accéder à ce module, il faudra que votre navigateur point sur l'adresse suivante :
http://localhost:8080/Management/xava/module.jsp?application=Management&module=Warehouse
Une portlet est également générée afin de pouvoir la déployer dans un portail compatible JSR-168.

Modules par défaut (depuis v2.2.2)

OpenXava assume un module par défaut pour chaque composant de l'application, même si le module n'est pas explicitement déclaré dans le fichier application.xml. Cela signifie que, si vous déclarez un composant Facture, vous pouvez aller directement à l'adresse suivante :
http://localhost:8080/Management/xava/module.jsp?application=Management&module=Facture
Et également le déployer comme portlet JSR-168 dans un portail. Et tout ceci sans le définir dans le fichier application.xml.
Le contrôleur pour les modules par défaut est Typical, mais vous pouvez modifier cette valeur par défaut en utilisant l'élément default-module dans le fichier application.xml, ainsi :
<application name="Management">
 
    <default-module>
        <controller name="ManagementCRUD"/>
    </default-module>
 
</application>
Dans ce cas, tous les modules par défaut de l'application Management se verront assigné le contrôleur ManagementCRUD.
Si vous ne souhaitez pas que certains modules utilisent ces contrôleurs par défaut, vous avez deux options :
  1. Définir un contrôleur dans controllers.xml avec le même nom que le composant
  2. Définir explicitement le module dans application.xml comme expliqué ci-dessus
Pour résumer, si vous définissez un composant, par exemple Client, vous avez un module Client et également une portlet. Ce module sera défini selon l'une de ces méthodes :
  1. Si vous définissez un module Client dans application.xml, c'est ce module qui sera celui utilisé, sinon,
  2. Si vous définissez un contrôleur Client dans controllers.xml, un module sera généré avec le contrôleur Client comme contrôleur et le composant Client comme modèle, sinon,
  3. Si vous définissez un élément default-module dans application.xml, un module sera généré en utilisant les contrôleurs du default-module et le composant Client comme modèle, sinon,
  4. Finalement, un module avec le contrôleur Typical comme seul contrôleur et le composant Client comme modèle.

Module de détail

Un module avec uniquement une vue de détail, sans affichage de liste est défini ainsi (new in v4m5):
<module name="InvoiceNoList">
    <model name="Invoice"/>
    <controller name="Typical"/>
    <mode-controller name="DetailOnly"/>        <!-- 1 -->
</module>
Le mode de contrôle DetailOnly (1) est utilisé pour supprimer l'affichage du lien "Détail - Liste". Dans ce cas, par défaut, le module utilise la vue de détail uniquement.
Un module avec uniquement une vue de détail, sans affichage de liste est défini ainsi (prior to v4m5):
<module name="InvoiceNoList">
    <model name="Invoice"/>
    <controller name="Typical"/>
    <mode-controller name="Void"/>        <!-- 1 -->
</module>
Le mode de contrôle Void (1) est utilisé pour supprimer l'affichage du lien "Détail - Liste". Dans ce cas, par défaut, le module utilise la vue de détail uniquement.

Module de liste

Un module avec uniquement un vue de liste, sans affichage de détail est défini ainsi (new in v4m5):
<module name="FamilyListOnly">
    <env-var name="XAVA_LIST_ACTION" value=""/>     <!-- 1  New in v2.0.4 -->
    <model name="Family"/>
    <controller name="Typical"/>
    <mode-controller name="ListOnly"/>              <!-- 2 -->
</module>
Tout d'abord, le mode de contrôle ListOnly (2) est utilisé pour supprimer l'affichage du lien "Détail - Liste", puis, Liste lors de l'initialisation. Finalement, en attribuant une valeur vide à la variable XAVA_LIST_ACTION (1) enlèvera le lien Détail de chaque ligne de la liste (nouveau depuis v2.0.4).
Un module avec uniquement un vue de liste, sans affichage de détail est défini ainsi (prior to v4m5):
<module name="FamilyListOnly">
    <env-var name="XAVA_LIST_ACTION" value=""/>     <!-- 1  New in v2.0.4 -->
    <model name="Family"/>
    <controller name="Typical"/>
    <controller name="ListOnly"/>                   <!-- 2 -->
    <mode-controller name="Void"/>                  <!-- 3 -->
</module>
Tout d'abord, le mode de contrôle Void (3) est utilisé pour supprimer l'affichage du lien "Détail - Liste", puis, le contrôleur ListOnly est chargé pour spécifier le mode Liste lors de l'initialisation. Finalement, en attribuant une valeur vide à la variable XAVA_LIST_ACTION (1) enlèvera le lien Détail de chaque ligne de la liste (nouveau depuis v2.0.4).

Module de documentation

Un module de documentation ne peut afficher que des pages HTML. Sa définition est toute simple :
<module name="Description">
    <doc url="doc/description" languages="en,es"/>
</module>
Ce module affiche le document web/doc/description_en.html ou web/doc/description_es.html suivant le langage du navigateur. Si le langage du navigateur n'est ni anglais ni espagnol, la valeur par défaut est l'anglais (la première langue spécifiée). Si vous ne spécifiez pas de langue, ce sera le document web/doc/description.html qui sera affiché.
Ce type de module est utile pour les portlets d'information. D'autre part, il n'a aucun effet en dehors d'un environnement de portail.

Module de lecture seule

Un module de lecture seule, c'est-à-dire de consultation de données uniquement, sans modifications possibles, est déclaré ainsi :
<module name="CustomerReadOnly">
    <env-var name="XAVA_SEARCH_ACTION" value="CRUD.searchReadOnly"/>  <!-- 1 -->
    <model name="Customer"/>
    <controller name="Print"/>                                        <!-- 2 -->
</module>
En utilisant le contrôleur CRUD.searchReadOnly (1), l'utilisateur ne peut modifier aucune donnée. Avec le contrôleur Print (please, translate this to French: or ExtendedPrint since v4.6), sans CRUD ou Typical, l'utilisateur peut générer des rapports PDF sans pour autant pouvoir sauvegarder, supprimer, etc... car les actions ne sont pas disponibles. C'est un module de consultation uniquement.
La syntaxe du fichier application.xml n'est pas difficile. Vous pouvez voir plus d'exemples dans le fichier OpenXavaTest/xava/application.xml.