1 Application, N version

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

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/

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.

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.

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 :

Citation:

---

Envoyé par config.xml

<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.

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)

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 :D) 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.

g0up1l, il manque quelque chose à ta 1ère solution. Comment fait-il pour, suivant le client, lancer FenetrePrincipaleClient ou FenetrePrincipale ?

Il faut bien indiquer à un endroit quelle classe instancier. Il faudrait alors pour chaque classe spécifique, à chaque instanciation, gérer cela dans une fabrique (design pattern Factory) de composants. J'ai déjà eu à faire ce genre de fabrique pour personnaliser toute une interface et j'ai trouvé cela assez imbuvable. (dans mon projet je devais pour un client, supprimer 1-2 boutons sur environ 50 écrans...)

Maintenant si tu n'as pas le choix, c'est peut-être le mieux à faire, mais si tu as le choix, je te conseille de limiter la personnalisation à l'extrême des ihm. Retirer une fonctionnalité (un onglet par exemple) c'est facile, mais je dirai changer des libellés ou les emplacements de boutons non merci, c'est pour tout le monde pareil. (c'est sûr que c'est plus facile à faire accepter si tu as la maitrise de ton application, que si tu es juste prestataire de service et que tu dois satisfaire à toutes les exigences du client.)

ps : je ne fais que donner mon avis, je n'ai pas non plus 10 ans d'expérience ;)

Citation:

---

Envoyé par CheryBen

g0up1l, il manque quelque chose à ta 1ère solution. Comment fait-il pour, suivant le client, lancer FenetrePrincipaleClient ou FenetrePrincipale ?

Il faut bien indiquer à un endroit quelle classe instancier. Il faudrait alors pour chaque classe spécifique, à chaque instanciation, gérer cela dans une fabrique (design pattern Factory) de composants.

---

Tout à fait.


Avec XUL, on peut bien séparer la couche de présentation, du fonctionnement des widgets. De nombreux produits sont en XUL, comme Firefox, ce qui permet de plaquer les skins que l'on veut.

Salut,

Citation:

---

Envoyé par CheryBen

mais je dirai changer des libellés ou les emplacements de boutons non merci, c'est pour tout le monde pareil.

---

Ce n'est pas simple à mettre en oeuvre... sauf si c'est pensé dès le début du développement !

• Pour les libellés il suffit de mettre en place un mécanisme de localisation.
• Pour la disposition c'est peut-être un peu plus complexe surtout du fait qu'il n'y a pas vraiment de solution "standard, mais c'est tout à fait faisable.

Maintenant c'est clair que lorsqu'il s'agit de modifier une application existante, c'est déjà plus compliqué :aie:

a++

Oui c'est possible, mais le gain est vraiment mineur.

Tout client sensé devrait comprendre que c'est dans son intérêt d'accepter un libellé Rechercher (au lieu de Valider) plutôt que de payer du développement, intégration, validation, management en plus.

Bon après du moment que le client paye la facture... ;)

Citation:

---

Envoyé par CheryBen

Tout client sensé devrait comprendre que c'est dans son intérêt d'accepter un libellé Rechercher (au lieu de Valider) plutôt que de payer du développement, intégration, validation, management en plus.

---

C'est pour cela qu'il faut le penser dès le début de l'application.

Afin un système de localisation le changement de libellé aurait été tout simple, simplement en fournissant un fichier supplémentaire propre au client. Et franchement ce n'est pas très complexe à mettre en oeuvre...



Maintenant le problème que tu peux avoir, c'est que le client ne comprenne pas qu'il soit si compliqué de changer un simple libellé... surtout qu'avec un peu de chance les commerciaux ont vendus une applications 100% configurables :aie:


Les clients peuvent parfois donner un grande importance à de petits détails...

a++

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 ?

Citation:

---

Envoyé par imhotep_zr7s

Qu'en pensez-vous ?

---

Que tu n'as pas le choix, il faut autant d'instance que de spécificité demandé par client. Dans ton cas, tu as 3 éléments duplicables : les css, les js et les jsp.
Les 3 sont considérées comme des ressources, et sont facilement gérable pour la préparation d'une livraison client.

En solution tu peux pour les libellés te baser sur le système de localisation et permettre à tes utilisateurs de changer ça à la volé.

En ce qui concerne la disposition, il existe un certain nombre de moyen pour externaliser la disposition du layout dans des fichiers externes.

cf http://java.dzone.com/news/layout-pr...ing-part-1-xml

Sachant que certains layouts proposent déjà ce genre de fonctionnalités en interne (par exemple l'omnipotent MigLayout)

Il est dans une techno client léger, pas client lourd en swing.
C'est plus délicat pour le layout.

Citation:

---

Envoyé par Tommy31

Il est dans une techno client léger, pas client lourd en swing.
C'est plus délicat pour le layout.

---

Le principe reste le même : il y a moyen d'externaliser cela...

Maintenant c'est sûr que sans connaitre les mécanismes exact de son application on ne pourra pas donner de solution...

a++

J'avou que pour le moment il s'agit plus d'une réflexion au sens large puisque le problème ne s'est pas encore posé. J'ai installé l'application chez mon premier client qui m'a demandé 1 modification très mineure sur du visuel. Le second client test l'application et je n'ai pour le moment pas de retour.

Après re-lecture de l'ensemble de vos réponses, il apparait qu'il n'existe pas vraiment de solution. Comme j'ai du temps devant moi avant les premiers retours de mon second client, je vais continuer ma réflexion. Sachant que le fait de multiplier les environnements (autant de projets eclipse que de clients) ne semble pas être optimum et adéquat.

Ce que je vais peut-être faire c'est créer un projet qui contiendra tout le métier (objet, accès au bases de données, traitement métier). Ensuite un deuxième projet qui ne fera que l'affichage et l'appel des traitements.
Je pourrais ainsi créer n projet visuel et avoir 1 projet métier.
Cela dit je ne suis probablement pas à l'abri de devoir modifier des traitements métiers pour tel ou tel client.

Ce questionnement prouve bien que la réflexion n'est pas encore terminée !

Si je décide de garder un seul projet, il est peut-être simple avec un script ant de packager les bonnes ressources en fonction du client cibler !

Merci de nourrir encore la réflexion

Effectivement je suis dans une logique de client léger.
Mais je pense que la réflexion en doit pas forcément se reposer sur le type d'architecture utiliser. Elle doit se faire de manière plus globale et doit répondre aussi bien à une problématique d'application client lourd que client léger.

Je ne sais que trop bien qu'une solution n'est que rarement 100% compatible, mais cette réflexion est mené dans le but de tendre vers.

Je m'étonne toutefois de voir que peux d'entre vous semble avoir été confronté à ce type de problématique. Peut-être ais-je mal intitulé ce post et que de fait beaucoup on pensé ne pas devoir si intéresser.

non ?

Citation:

---

Envoyé par imhotep_zr7s

Mais je pense que la réflexion en doit pas forcément se reposer sur le type d'architecture utiliser.

---

Ben pour une application existante je dirais que oui... à moins que tu ne veuilles tout casser !


Maintenant les solutions ont été données, il faut juste les adapter :

• La localisation est parfaite pour la gestion des libellées, et permet la modification au cas par cas.
• Pour la modification du code métier et présentation, la redéfinition des classes ou un système de plugins via évènement, le tout configurable par un (ou plusieurs) fichiers de configuration.

Mais tout cela dépend bien du type d'application : ce ne sera pas forcément la même chose pour une application desktop et une application web... sans compter que les frameworks utilisées auront également leurs importances dans la décision...


a++

Effectivement tout cassé n'est pas forcément problématique puisque le projet n'est pas encore conséquent et je préfère tout casser au besoin maintenant plutôt que d'attendre d'avoir plus de client.
Pour le moment seule 2 clients donc pas trop d'impact.
En ce qui concerne les frameworks étant donné que le paramétrable ne portera que sur du visuel et non sur du métier je pense que l'impact est relativement contenu.