Discussion :

[R&B]

Bonjour,
J'ai un problème avec ce sujet et la manière de le traiter dans un projet d'envergure.
J'ai besoin de spécifier un projet sur plusieurs niveaux dont le métier des clients cibles. Le projet comporte un socle de fonctionnalités communes.
Ainsi, des fonctionnalités ne devrait apparaitre que pour certain métiers... et d'autre devraient avoir un comportement qui s'adapte.

j'ai étudié cette discussion ainsi que cette solution mais les deux entrent en conflit avec la documentation ou ce cours.

J'imaginais utiliser les configurations, les composants internes, le code cible et un bon pilotage de la compilation pour faciliter le travail de développement...
Mais plus j'étudie, plus l'approche "spécification par le composant interne" est remise en question.
Les configurations ne sont pas gérées par le code cible, les composants internes ne voient pas le contenu du projet (c'est le contraire) ni les autres composants. La compilation intègre systématiquement les analyse et collections de procédure globales de composants non prévus.

J'ai donc l'impression que mon approche est juste inversée par rapport à celle de PCSoft : C'est le composant qui délivre une fonctionnalité du socle de base au projet. Un bon exemple est le composant groupware utilisateur qui s'intègre aux projets par un composant interne.

Cela remet en cause pas mal de choses dans la conception des spécialisations. Au lieu d'avoir un projet et des composant qui le spécifient, on aurait autant de projets que de métier avec des composants définissant le socle. Bref, on est très éloigné du besoin de base.

J'en suis un peu perdu.

[DelphiManiac]

Je n'ai pas vraiment cerné ta question, par contre j'ai compris la conclusion : tu es perdu !! Essaye de te poser des questions simples et de nous les poser aussi

Personnellement, j'ai laissé tomber les solutions modulaires, la plus grosse limite, pour ma part, étant la limite d'une analyse par projet ou par composant, peut être que je n'ai pas cerner comme toi, la bonne solution.

Actuellement j'ai un gros projet qui contient l'ensemble des différentes configurations. Pour chaque configuration, tu peux exclure des modules, et tu peux connaître, lors de l'exécution, quelle est la configuration en cours.

[R&B]

Ha ha ! Tellement perdu en effet que j'en ai oublié la question. désolé !

Peut-on vraiment spécialiser les fonctionnalités d'une configuration de projet par sa structure même ?

En visualisant séparément les configurations, composants internes, code cible et compilation on est tenté d'y croire.
Mais la doc PCSoft et la présentation qui limite les composants juste comme un moyen d'assurer le portage de fonctionnalités de socle entre projets me font déchanter sur cette idée.

Je souhaite donc précisément éviter :
- de dire aux développeurs qu'ils doivent gérer les spécialisations dans tous leurs développements.
- de livrer à un client une fonctionnalité dont je suis sûr qu'il n'aura besoin.
- de maintenir dans un même endroit des fonctionnalités parfois contradictoires que des erreurs de configuration peuvent activer... et provoquer des dégâts.

Pour chaque configuration, tu peux exclure des modules, et tu peux connaître, lors de l'exécution, quelle est la configuration en cours.

Fais-tu l'exclusion par programmation ? par compilation (en respectant un nommage) ?

Merci en tout cas de ta sollicitude sur un sujet épineux.

[DelphiManiac]

Oui par programmation; sans règle de nommage pour ma part, mon projet n'étant pas sujet à gérer des configurations complexes.

[R&B]

Ok merci Eric.
je laisse la discussion ouverte un moment, des fois que d'autres aient abouti sur le sujet ou que je trouve un moyen.