Projets
Pages enfant
  • 1.6 Organisation des fichiers

Vous regardez une version antérieure (v. /wiki/spaces/PROJ/pages/100663462/1.6+Organisation+des+fichiers) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 4) afficher la version suivante »

A completer

Du point de vue du développeur, une application est composée de plusieurs projets Eclipse :

  • A DEFINIR

Du point de vue de l'exploitant, une application est composée d'une hiérarchie unique de fichiers, issue de la décompression d'une archive WAR.

Nous allons dans un premier temps décrire les chemins spécifiques à chaque type d'utilisateurs, puis nous décrirons les arborescence communes.

Les arborescences communes sont présentées avec des chemins relatifs. Les chemins sont a adapter en fonction du contexte de l'utilisateur : exploitant ou développeur.

Arborescence développeur

Arborescence exploitant

/docs : la documentation

Toute la documentation du projet est située dans le répertoire /docs, le sous-répertoire /docs/api contient le Javadoc généré.

properties : les fichiers de configuration

Les fichiers de configuration sont en général fournis sous forme de fichiers d'exemple (xxx-example.xml).

La bonne gestion des fichiers de configuration

Les exploitants peuvent renommer ces fichiers (en xxx.xml), mais les développeurs doivent copier les fichiers d'exemple sous leur nom final (en laissant les fichiers d'exemple en place car ceux-ci sont liés au dépôt SVN).

Le fichier applicationContext.xml importe tous les fichiers de configuration Spring. Il peut également être utilisé pour définir des beans.

properties/auth : l'authentification

Le fichier de configuration Spring auth-example.xml définit le bean authenticationService, qui sert à l'application à récupérer l'identifiant de l'utilisateur connecté. Il doit être copié en auth.xml.

properties/cache : le cache

Le fichier de configuration Spring cache-example.xml définit le bean cacheManager, qui sert à l'application à s'appuyer sur un gestionnaire de cache. Il doit être copié en cache.xml.

Le fichier de configuration EhCache ehcache-example.xml définit la configuration de la bibliothèque EhCache.

properties/dao : l'accès aux données

Le fichier de configuration Spring dao-example.xml définit la manière dont l'application récupère les données de la base de données, par exemple avec Hibernate.
Il doit être copié en dao.xml.
Le fichier de configuration Hibernate hibernate/hibernate.cfg-example.xml définit la manière dont Hibernate se connecte à la base de données. Il doit être copié en hibernate.cfg.xml. Il est référencé par le bean abstractHibernateSessionFactory de dao.xml.

Les fichiers de configuration Hibernate hibernate/mapping/.hbm* décrivent le mappingentre les classes Java et les tables de la base de données. Ils sont également référencés par le bean abstractHibernateSessionFactory de dao.xml. Il n'est en général pas nécessaire pour les administrateurs de modifier ces fichiers, ils ne sont pas fournis sous forme d'exemples.

properties/deepLinking : la gestion des liens

Le fichier de configuration Spring deepLinking-example.xml définit le bean deepLinkingRedirector, qui indique comment l'application gère les liens (hypertextes) directs. Il doit être copié en deepLinking.xml.

Le fichier de configuration Spring urlGeneration-example.xml définit le bean urlGenerator, qui génère les liens hypertextes vers l'application (avec prise en compte de l'authentification, des paramètres de liens directs, ...). Il doit être copié en urlGeneration.xml.

properties/exceptionHandling : la gestion des exceptions

Le fichier de configuration Spring exceptionHandling-example.xml définit le bean exceptionServiceFactory, qui indique comment l'application gère les exceptions. Il doit être copié en exceptionHandling.xml.

properties/i18n : la gestion de l'internationalisation

Le fichier de configuration Spring i18n-example.xml définit le bean i18nService, qui indique comment l'application récupère les chaînes de caractères utilisés dans l'application. Il doit être copié en i18n.xml. Les fichiers bundles/_.properties contiennent les chaînes de caractères proprement dites.

properties/init : l'initialisation et la mise à jour

Le fichier de configuration Spring init-example.xml définit le bean versionningService, qui indique la manière dont est initialisée la base de données. On y trouvera par exemple l'uid du premier administrateur de l'application qui sera créé automatiquement en même temps que la base de données. Il doit être copié en init.xml.

properties/ldap : l'accès à l'annuaire LDAP

Le fichier de configuration Spring ldap-example.xml définit le bean ldapService, qui indique comment sont faits les accès à l'annuaire LDAP. Il doit être copié en ldap.xml.

properties/log4j.properties : les traces de l'application

Le fichier log4j-example.properties configure log4j (la bibliothèque utilisée pour les traces).

properties/misc : des choses qu'on a pas su mettre autre part (clin d'œil)

Le fichier de configuration Spring application.xml définit le bean applicationService, qui indique à l'application son numéro de version, copyright, ... Ce fichier n'est pas fourni sous forme d'exemple, il ne doit normalement pas être modifié par les exploitants.

Le fichier de configuration Spring abstractBeans.xml définit des beansabstraits utilisés par héritage (notamment dans * /src/main/resources/properties/web/controllers.xml*). Ce fichier n'est pas fourni sous forme d'exemple, il ne doit normalement pas être modifié par les exploitants.

properties/smtp : l'envoi de courriers électroniques

Le fichier de configuration Spring smtp-example.xml définit le bean smtpService, qui indique à l'application comment envoyer les courriers électroniques. Il doit être copié en smtp.xml.

properties/tags : le rendu des tags esup-commons

Le fichier de configuration Spring tags-example.xml définit le bean tagsConfigurator, qui configure dynamiquement les balises de la taglib esup-commons. Il doit être copié en tags.xml.

properties/web : l'interface utilisateur

Le fichier de configuration Spring controlers.xml définit les contrôleurs de l'application, qui réagissent aux actions de l'utilisateur.

Le fichier de configuration Spring converters.xml définit les convertisseurs de l'application, qui convertissent des objets en chaînes (vice-versa) lors des interactions utilisateur.

****************************************

/webapp : l'application web et les bibliothèques

media : les fichiers statiques

On trouvera dans ce répertoire tous les fichiers délivrés de manière statique par l'application web aux clients :

  • Les images,
  • Les feuilles de style (*.css),
  • Les scripts Javascript
  • ...

L'intérêt de ce regroupement est de pouvoir shunter Tomcat par un frontal Apache, plus efficace pour le délivrement de ressources statiques.

/webapp/META-INF : le manifest

Le fichier /webapp/META-INF/MANIFEST.MF est produit automatiquement par la tâche ant _dist.

/webapp/stylesheets : les pages JSF

Toutes les pages JSF doivent être situées à cet endroit pour pouvoir être protégées d'un accès direct de manière globale.

/webapp/WEB-INF : la configuration de l'application web

Le fichier portlet-example.xml indique à Pluto comment configurer la portlet, il n'est utilisé qu'en mode portlet. Il doit être copié en portlet.xml.

Les fichiers web-portlet-example.xml (resp. web-servlet-example.xml) est un exemple de configuration du contexte Tomcat associé à l'application. En mode portlet (resp. servlet), il doit être copié en web.xml.

Les fichiers esup-commons.tld et fck-faces.tld sont les fichiers de définition des taglibs de esup-commons et FckEditor.

/webapp/WEB-INF/lib : les bibliothèques de l'application

Même les applications en mode batch seulement doivent utiliser /webapp/WEB-INF/lib pour déposer leurs bibliothèques, même si dans ce cas le nommage n'est pas très approprié.

/website : la construction du site web

Le répertoire /website est utilisé de manière temporaire par la tâche ant doc pour générer la documentation du projet avant de la transférer sur le site web du projet, les fichiers s'y trouvant ne doivent pas être modifiés même par les développeurs.

  • Aucune étiquette