Pages enfant
  • 1.2 Méthodologie de développement

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.
Balise Wiki
{note:title=A compléter}Schémas et fonctionnement en modules{note}

h4. Sommaire :
{toc:maxLevel=3}
----
h2. Ce que permet (ou permettra) _esup-commons_

... des applications web
{HTMLcomment}
|| Type d'application || Spring-MVC || JSF 1.2 || JSF 2.0 ||
| *Servlet desktop* | x | x | (x) |
| *Mixte (Mobile Portlet WAI Servlet)* | (x) | (x) | |
| *Servlet Mobile* | x | x | (x) |
| *WAI* | (-) | ? | (-) |
{HTMLcomment}

Quel module pour quel type de projet :
* Une application portail :
** Un projet qui ne doit figurer que dans le portail : \*petits projets\* \-> mixte JSF ou Spring MVC
** Un projet que l'on souhaite pouvoir déployer en portlet et en servlet de manière identique : \*petits et moyen projet\* \-> Mixte JSF 1.2
** Un projet que l'on souhaite pouvoir déployer en portlet et en servlet de manière différente (ex: Une petite application d'accroche dans le portail qui redirige ensuite l'utilisateur vers une application hors portail) : \*moyen et gros projet\* \->
* Une application hors portail :
** Un site web complètement externe au portail \-> Serlvet desktop ou mixte => JSF 1.2 ou JSF 2.0 pour des application lourdes qui nécéssiterait de l'ajax etc... car Portlet Bridge (myFaces) supporte JSF 1.2 et JSF 2.0.


h2. Les notions de _blank_ et _example_

Dans sa deuxième version, _esup-commons_ adopte un méthodologie complètement différente de la première.
Auparavant, le développement d'un projet passait par le checkout SVN d'un projet "blank" qui devait dépendre du projet _esup-commons,_ lui-même récupéré par un checkout SVN. Voir ([PROJCOMMONS:03 Méthodologie de développement])

*Désormais, un projet* *{_}esup-commons{_}* *se base sur Maven et la notion d'archetype.*

Pour démarrer un nouveau projet, on partira sur la base d'un archétype _blank_ qui, grâce au mécanisme de dépendance Maven, intégrera _esup-commons_ sous forme de jar.

{note}Mettre un ecran structure vide{note}

La notion de projet d'exemple (_example_) existe toujours. Cette application a pour but de présenter une implémentation simple d'un projet _esup-commons_ et quelques fonctionnalités incontournables d'une application. Cette dernière sera récupérée par un checkout SVN.

*Attention : les projets* *{_}esup-commons{_}* *et* *{_}esup-blank{_}* *disponibles sur le SVN ne sont utilisés que par les contributeurs du projet* *{_}esup-commons{_}*


!schema-maven-svn.png|border=1!


h2. Le fonctionnement en _modules_

Un projet _esup-common_ se décompose en sous-projets à part entière appelés "modules" au sens Maven et dépendants les uns des autres .

!principeGeneraux.png|border=0!

Au packaging, chaque module sera proposé sous forme soit d'un fichier jar pour les couches basses, soit d'un fichier war pour la présentation.

* WEB-JSF-SERVLET *war*
* WEB-JSF-PORTLET *war*
* WEB-JSF-MOBILE *war*

* WEB-JSF-SHARED *jar* => Controllers

* DOMAIN-SERVICES *jar* => Les services métiers (authenticator, accès au WS, exposition de WS)
* DOMAIN-BEANS *jar* => Les objets métiers
* DAO *jar* => Accès aux données
* UTILS *jar* => Utilitaires transverses à toute 
Remarque
titleA compléter

Schémas et fonctionnement en modules

Sommaire :

Sommaire
maxLevel3

Ce que permet (ou permettra) esup-commons

... des applications web

Type d'application

Spring-MVC

JSF 1.2

JSF 2.0

Servlet desktop

x

x

(erreur)

Mixte (Mobile Portlet WAI Servlet)

(erreur)

(erreur)

 

Servlet Mobile

x

x

(erreur)

WAI

(moins)

?

(moins)

Quel module pour quel type de projet :

  • Une application portail :
    • Un projet qui ne doit figurer que dans le portail : *petits projets* -> mixte JSF ou Spring MVC
    • Un projet que l'on souhaite pouvoir déployer en portlet et en servlet de manière identique : *petits et moyen projet* -> Mixte JSF 1.2
    • Un projet que l'on souhaite pouvoir déployer en portlet et en servlet de manière différente (ex: Une petite application d'accroche dans le portail qui redirige ensuite l'utilisateur vers une application hors portail) : *moyen et gros projet* ->
  • Une application hors portail :
    • Un site web complètement externe au portail -> Serlvet desktop ou mixte => JSF 1.2 ou JSF 2.0 pour des application lourdes qui nécéssiterait de l'ajax etc... car Portlet Bridge (myFaces) supporte JSF 1.2 et JSF 2.0.

Les notions de blank et example

Dans sa deuxième version, esup-commons adopte un méthodologie complètement différente de la première.
Auparavant, le développement d'un projet passait par le checkout SVN d'un projet "blank" qui devait dépendre du projet esup-commons, lui-même récupéré par un checkout SVN. Voir (03 Méthodologie de développement)

Désormais, un projet esup-commons se base sur Maven et la notion d'archetype.

Pour démarrer un nouveau projet, on partira sur la base d'un archétype blank qui, grâce au mécanisme de dépendance Maven, intégrera esup-commons sous forme de jar.

Remarque

Mettre un ecran structure vide

La notion de projet d'exemple (example) existe toujours. Cette application a pour but de présenter une implémentation simple d'un projet esup-commons et quelques fonctionnalités incontournables d'une application. Cette dernière sera récupérée par un checkout SVN.

Attention : les projets esup-commons et esup-blank disponibles sur le SVN ne sont utilisés que par les contributeurs du projet esup-commons

Image Removed

Le fonctionnement en modules

Un projet esup-common se décompose en sous-projets à part entière appelés "modules" au sens Maven et dépendants les uns des autres .

Image Removed

Au packaging, chaque module sera proposé sous forme soit d'un fichier jar pour les couches basses, soit d'un fichier war pour la présentation.

  • WEB-JSF-SERVLET war
  • WEB-JSF-PORTLET war
  • WEB-JSF-MOBILE war
  • WEB-JSF-SHARED jar => Controllers

...

l'application