Discussion :

[imhotep_zr7s]

Bonjour,

Bon le titre n'est pas très parlant je sais mais vous verez en lisant que ce n'est pas forcément simple à synthétiser.

J'explique ma problèmatique :
J'ai fini le développement d'une application JAVA / Hibernate / Oracle.
Super vous me direz, effectivement.

J'ai installé un CVS pour suivre les évolutions de l'appli, normal en somme.
J'ai livré l'application à mon premier client qui s'en trouve content.

Maintenant je propose mon application à d'autres clients. Ils trouvent tous l'appli sympa et ultile mais souhaite y apporter des petits aménagements.

Un affichage des champs de recherche différents ou encore un bouton valider qui ne s'appelle pas valider mais rechercher.

Mon souci est de réussir à maintenir une seule version mais de pouvoir adapter lors du packaging de l'application ces petites modifications.

Plusieurs idées me sont venus :
1. Créer autant de projet CVS que j'ai de client.
a. un peu lourd mais très rapide et efficace
b. si une modification générique, il faut multiplier les modifs sur tous
les environnements.
2. Dupliquer les pages / classes adaptés pour chaque client.
a. peut devenir très vite ingérable car il faut tenir à jour un catalogue
des adaptations.

Voilà le début de ma réflexion. Merci de me dire ce que vous en pensez.
J'ai surement pas encore une vision complète.
Merci de me donner vos points de vus.

@+

Imhotep

[avtonio]

Bonjour,
beaucoup d'applications permettent ce genre de chose tout en restant sur une seule branche.
ton application doit etre "parametrable":
1/ definir ce qui doit etre parametrable
2/ externaliser ce parametrage
3/ en faire 1 par client

Pour etre + concret il faut d'abord faire le 1/

[CheryBen]

IL pourrait y avoir une façon assez simple de voir la chose : tu es le fournisseur d'un produit, donc c'est toi qui en choisit les orientations. De ce fait, si un client demande une évolution, tu peux choisir de l'imposer à tout tes clients.

Pour des modifications très spécifiques, tu peux choisir d'activer ou non certaines fonctionnalités en fonction d'un fichier de configuration. Et dans CVS, tu devras avoir une version de ce fichier de configuration par client.

Dans le projet sur lequel je travaille actuellement, il y a un cœur de l'application et une multitude de plugins. Suivant le client, on enlève/ajoute les plugins nécessaires.

[imhotep_zr7s]

Effectivement ton idée me plait bien mais est uniquement applicable si tu considères la mise à disposition d'un panel de fonctionnalité au sein d'une même application. Mais pour faire du paramétrable dans une fonctionnalité c'est plus compliqué par exemple si on considère un placement de zone dans une jsp.
Qu'en pensez-vous ?

Merci de nourir ce sujet qui je pense pourrais intéresser pas mal de monde.

[CheryBen]

Que veux-tu dire par placement de zone dans une JSP?

Je ne suis pas sûr de comprendre, est-ce que le placement ne pourrait pas être enregistré dans un fichier de configuration comme ceci :

<AppliConfiguration>
<pageToto>
<zone1 placement='haut' />
</pageToto>
</AppliConfiguration>

Je ne fais pas de jsp, peut-être que je me trompe totalement sur ce que tu veux dire.
Mais ce que je veux expliquer c'est que même à l'intérieur d'une fonctionnalité, tu peux faire un réglage en fonction d'une valeur en fichier de conf.

[avtonio]

Je crois deviner ce que tu souhaiterais:
avoir une application dans laquelle tu code des spécificités pour un certain client sans aucun mécanisme de paramétrage ou plugins

mais si on souhaite maintenir une seule application on est bien obligé d'avoir un code unique.
et donc de définir ce qui sera paramétrable (ici tu donne un placement de zone).
Ceci étant, tu n'est pas obligé de définir tout les paramétrage possibles dés le début

t'ai je convaincu sur l'obligation d'avoir un mécanisme de parametrage ? ^^
(ou alors il faut accepter d'avoir un "code" par client)

pour le concret, un mecanisme de parametrage est souvent tres simple a mettre en place (cf l'exemple de CheryBen)

[g0up1l]

1ere solution avec recompilation de code :

Un langage objet comme Java permet de répondre à ton problème.
Il faut que (mais je suppose que c'est déjà fait ) tu encapsules au maximum tes concepts dans des classes que tu pourra dériver en fonction de tes clients.

Exemple (volontairement très basique) :

tu as une classe 'FenetrePrincipale' qui affiche des widgets (bouton, textField,...). Prévoit donc une méthode "positionnement()" pour placer tes widgets. Si un client souhaite un aspect différent, construit une classe "FenetrePrincipaleClient" qui hérite de 'FenetrePrincipale' et qui redéfinit la méthode "positionnement()" afin de coller à son souhait.

2eme solution sans recompilation :

Il faut que tu décorèles complètement l'aspect de tes formulaires et widgets de leur fonctionnements. Ainsi, tu pourra proposer des "skins" différents suivant les clients.

[imhotep_zr7s]

D'une manière générale je suis tout à fait d'accord avec vous dans le sens ou une application ne peut pas être / ne doit pas être 100% configurable au risque d'engendrer un monstre.

Je dispose tout de même d'un avantage en ce sens que un seul client à l'application pour le moment donc, il est encore possible de tirer des grandes lignes de paramétrage possible ou non. L'exemple exact est en fait que j'ai pasge de recherche avec un champ Nom et un champ Nom de Jeune Fille. Je trouvais logique de séparer les deux. Mon client à préférer laisser un seul champ Nom et m'a fait rajouté une case à cocher pour dire si la recherche s'effectue sur le Nom uniquement ou aussi sur le Nom de Jeune Fille. Je lui ai dit pourquoi pas. Cela m'a fait une petite modification ergonomique un peu de javascript et hop le tour est joué. Maintenant je ne suis pas à l'abri de devoir remettre les deux champs avec un autre client. la seule solution que je vois pour çà c'est d'avoir deux versions de la même page pour faire plus simple.
Cela dit avant de mettre cela en place, je préférai avoir un regard le plus large possible pour éviter de prendre cette décision et de m'apercevoir que cette solution n'est pas la plus judicieuse pour l'ensemble du projet.

je suis 100% d'accord avec le fait de paramétrer certains points mais j'ai derrière moi quelques mauvais exemples de paramétrage à outrance créant ainsi un nombre énorme de paramétre entrainant des plantages en les combinants. Il faut donc trouver le juste milieu.

Qu'en pensez-vous ?