Discussion :

[Pico51]

Bonjour,

Je développe une application J2EE mais comportant des fichiers xml, java, groovy et ftl principalement et j'aimerais mettre au point un système d'addons permettant à n'importe quel utilisateur d'y ajouter les fonctionnalités souhaités.

Pour le moment, un système est déjà mis en place ; un addon est constitué d'un ensemble de fichiers .patch qui s'appliquent sur les fichiers correspondant lors de l'installation.
Le problème est que, lorsqu'il y a une modification de l'existant, beaucoup d'addons ne peuvent plus fonctionner étant donné que l'on a modifié le code correspondant à leur patch.

J'ai regardé le fonctionnement du gestionnaire d'addon de Firefox mais il ne correspond pas à mon besoin. En effet, si je modifie une partie d'un fichier .groovy par exemple, la méthode overlay (injection) que propose Firefox ne fonctionne pas.

Auriez-vous des idées pour mettre en place ce genre de système au sein d'une application ? Ce qui m'intéresse principalement est la forme de l'addon (quels sont les fichiers qu'il contiendra et quels sont leurs buts) ; l'implémentation du gestionnaire d'addons ne posera pas de problème ensuite.

Je vous remercie pour toutes les suggestions que vous pourrez me fournir.

[souviron34]

euh...

J'avoue que la manière dont tu poses ton problème me laisse perplexe...

Quand tu parles de addon, parles-tu de choses qui sont une boîte noire, ou de choses pour lesquelles tu veux contrôler l'entrée et/ou la sortie ???


Parce que les solutions sont différentes suivant les cas ...

[Pico51]

Un addon serait en quelque sorte un patch à appliquer à un projet déjà existant. De cette manière, quiconque peut ajouter des fonctionnalités sans que le projet initial soit modifié.

Pourquoi utiliser un patch ? Simplement parce que le projet initial ne possède pas de système d'extensions.

Pour le moment, le "gestionnaire de patchs" qui a été ajouté au projet utilise uniquement des fichiers patch mais, comme expliqué précédemment, ces techniques connait ses limites.

J'aimerais savoir s'il est possible de gérer différemment ce système.

[souviron34]

tu n'as pas répondu à ma question

[Richard_35]

Bonjour Pico51,

Je partage la perplexité de Souviron34 (que je salue aussi).

Dans ce forum, nous pouvons t'aider à mettre au point un système de gestion des addon et non pas t'aider à développer des ajouts d'addon, comme il me semble l'avoir compris à la lecture de ta phrase :

J'ai regardé le fonctionnement du gestionnaire d'addon de Firefox mais il ne correspond pas à mon besoin. En effet, si je modifie une partie d'un fichier .groovy par exemple, la méthode overlay (injection) que propose Firefox ne fonctionne pas.

mais, je peux me tromper.


En bref, nous pourrons te dire quelles sont les tables que tu devras prévoir pour te permettre de lister, par exemple, l'ensemble des addon pour un soft, le développeur de l'addon, etc...

Je ne sais pas si j'ai été bien clair, sur ce coup là...

[Pico51]

Je ne m'attends pas du tout à ce que vous développiez ce que je cherche, loin de là. Je veux simplement des idées.

Quand tu parles de addon, parles-tu de choses qui sont une boîte noire, ou de choses pour lesquelles tu veux contrôler l'entrée et/ou la sortie ???

Un addon n'est ni une boite noire (bien que je ne vois pas vraiment de quoi tu veux parler) ni une "chose" pour laquelle je veux contrôler quoi que ce soit.
Un addon est un ensemble de fichiers qui permettent de modifier un projet existant à l'aide d'un gestionnaire d'addons.

Par exemple, dans un projet déjà existant, j'ai un fichier original.xml que je veux modifier afin d'y apporter des fonctionnalités. Pour cela, j'effectue mes modifications dans ledit fichier original.xml et le gestionnaire d'addons est capable de me générer un addon. Dans cet exemple, l'addon ne contiendra qu'un fichier : original.patch. Ensuite, pour que toutes les personnes qui le souhaite puissent bénéficier de cette fonctionnalité, elles n'auront qu'à appliquer le patch à l'aide du gestionnaire d'addons.

J'espère avoir été plus clair sur ce point.

Pour le moment, le gestionnaire d'addons fonctionne de cette manière, c'est à dire avec des fichiers patch, mais cela provoque souvent des problèmes lorsque l'existant est souvent modifié.

Ce que je demande alors, c'est quel système puis-je mettre en place pour éviter le problème que j'ai avec les fichiers patch ? Comment modifier la structure des addons (et le fonctionnement du gestionnaire) afin d'obtenir la même chose avec moins de problèmes lorsque l'existant est beaucoup modifié ? Je ne demande pas que l'on me fasse le boulot mais des idées.

J'espère avoir été un peu plus clair. Si vous avez toujours des questions, je suis prêt à y répondre.

[Richard_35]

Tu es sur le forum "Conception", dans le sens conception de bases de données pour fournir, en final, une analyse (liste de tables/relations) servant de base aux développeurs : dans ton cas, saisie des applications, des fichiers, des addon (en tant qu'entité, pas en tant que lignes de code).


Si c'est bien cela que tu souhaites, plusieurs questions (?) :

• 1 application comporte plusieurs fichiers (xml, java, groovy et ftl principalement) : OK ;
• 1 même fichier (xml, java, groovy et ftl principalement) peut-il être le composant de 2 applications différentes ?
• 1 addon comporte plusieurs fichiers (.patch ) : OK ;
• 1 fichier (.patch) peut-il être le patch de plusieurs addon ?

[Pico51]

D'accord ! Dans ce cas, je ne suis pas du tout dans le bon forum. Je parle de la conception de l'application dans le sens de l'architecture, du fonctionnement (relation entre fichiers, structure des fichiers, ...).

Apparemment, je me suis trompé. Dans quel forum mon topic serait plus approprié ?

[Richard_35]

Eh bien, à vrai dire, je n'en sais trop rien...

Si j'étais toi, bien que je ne connaisse pas ta partie, je commencerai par ce forum.

[Richard_35]

Bien que ton problème be soit pas résolu, pense au flag "Résolu" pour solder le dossier dans ce forum.

[souviron34]

Je partage la perplexité de Souviron34 (que je salue aussi).

Bonjour à toi

Un addon n'est ni une boite noire (bien que je ne vois pas vraiment de quoi tu veux parler)

Ce dont je veux parler est un truc comme un "plugin", c'est à dire que tout ce que tu sais c'est un type de fonctionalité, et c'est tout... Tu n'as à lui passer que par exemple un nom de fichier, et ce que cette "boite noire" en fait après tu t'en fiches..

ni une "chose" pour laquelle je veux contrôler quoi que ce soit.

Ce que je voulais demander c'est, par opposition au cas précédent (et ce qui a l'air d'être le cas par rapport à ton explication), c'est si tu avais des informations précises sur le contenu de ce qui sera manipulé par ce "plugin" en entrée et si tu souhaitais pouvoir avoir les modifications en sortie..

Exemples des différences : tu développes pour une appli une fonctionalité d'affichage de PDF.

• Soit tu souhaites un comportement "boite noire" : tu sais que tu feras appel à un outil extérieur (Adabe reader ou autre), mais du moment que cet outil fait le boulot tu te fiches pas mal du contenu. Dans ce cas tu as 2 champs à coonaître seulement : le nom de l'application de "plugin", et le nom du fichier que tu veux lui transmettre
  
  
• Soit tu souhaites un comportement "contrôlé" : tu veux vérifier par exemple si l'affichuer n'était pas en mode édition et que l'utilisateur n'aurait pas modif le document, auquel cas il faudra que tu puiisses contrôler les Entrées/sorties du "plugin"...

Un addon est un ensemble de fichiers qui permettent de modifier un projet existant à l'aide d'un gestionnaire d'addons.

Par exemple, dans un projet déjà existant, j'ai un fichier original.xml que je veux modifier afin d'y apporter des fonctionnalités. Pour cela, j'effectue mes modifications dans ledit fichier original.xml et le gestionnaire d'addons est capable de me générer un addon. Dans cet exemple, l'addon ne contiendra qu'un fichier : original.patch. Ensuite, pour que toutes les personnes qui le souhaite puissent bénéficier de cette fonctionnalité, elles n'auront qu'à appliquer le patch à l'aide du gestionnaire d'addons.

J'espère avoir été plus clair sur ce point.

OK. Tu es donc dans le second cas....


ça s'éclaire

Pour le moment, le gestionnaire d'addons fonctionne de cette manière, c'est à dire avec des fichiers patch, mais cela provoque souvent des problèmes lorsque l'existant est souvent modifié.

Ce que je demande alors, c'est quel système puis-je mettre en place pour éviter le problème que j'ai avec les fichiers patch ? Comment modifier la structure des addons (et le fonctionnement du gestionnaire) afin d'obtenir la même chose avec moins de problèmes lorsque l'existant est beaucoup modifié ? Je ne demande pas que l'on me fasse le boulot mais des idées.

J'espère avoir été un peu plus clair. Si vous avez toujours des questions, je suis prêt à y répondre.

Quel genre de problèmes as-tu ?

Est-ce lié au fait que les modifications ne sont pas vues en temps réel ? est-ce lié au fait qu'il faille explicitement faire une mise à jour ?


Tu ne crois pas que ce serait plus facile d'utiliser un gestionnaire tout fait, comme cvs, subversion ou autre ????





Sinon, la solution dépendra encore une fois de l'architecture dans laquelle cela s'insère.. Soit tu as une fonctionalité "update" spécifique, sur demande, qui va automatiquement demander la dernière version, soit tu as un système d'avertisement couplé, qui à chaque nouvelle entrée (version) dans la base, envoie à l'ensemble des utilisateurs se servant de ce fichier une message "ce fichier a été modifié. Voulez-vous le mettre à jour ?", qui, en cas de réponse positive, appelle l'update. Soit encore une mise à jour forcée automatique.

[wiztricks]

Salut,
Je vous suggère de regarder ce que font les "mercurial queues".
- W

[Pico51]

Je ne veux pas utiliser cvs & co. pour les raisons suivantes : il y a un projet qui évolue tous les jours mais qui ne contient pas toutes les fonctionnalités que l'on pourrait lui demander. Pour cette raison, je veux un système d'addons qui permettrait de modifier le code source de ce projet uniquement lorsque je veux les fonctionnalités apportées par un addon (que l'on aurait développé au préalable). Cet addon doit pouvoir s'appliquer aussi bien avec n'importe quelle version du projet de base.

Voilà l'objectif.

Le moyen est donc de mettre en place ce système d'addon.
Aujourd'hui, une application indépendante du projet initial se charge de vérifier si il y a eu des modifications sur le projet, et, si tel est le cas, génère des fichiers patch (générés à l'aide de la commande diff) qui constitueront l'addon.
Pour appliquer l'addon sur le projet existant, on a juste à appliquer les patchs.

Cependant, étant donné que le projet évolue constamment, il arrive souvent que ces patchs ne puissent plus s'appliquer. Je cherche donc une manière de contourner ce problème.

[souviron34]

Euh.....

Des outils comme cvs permettent de faire ceci, avec les notions de branches, de versions, de merge de branches ou de versions, de création de branches avec contraintes (telle version de tel module etc..) etc...


Maintenant, si c'est impossible à faire avec les outils existants, c'est que soit vous avez un problème de conception de l'architecture du logiciel, soit vous voulez réinventer la roue..

A part ce que j'ai expliqué ci-dessus, je ne vois rien d'autre...

[Pico51]

Tous les gestionnaires de versions du genre cvs (du moins tous ceux que je connais) sont basés sur la commande diff/patch.
Comme je l'ai déjà énoncé, cette commande pose des problèmes étant donné que les fichiers de base sont très souvent modifiés : les patchs ne peuvent plus s'appliquer et l'on est obligé de faire des merge manuellement assez fréquemment.

L'idée est de refaire une commande diff/patch pour les fichiers xml particulièrement mais se basant sur la sémantique du fichier au lieu de faire une comparaison ligne par ligne.

Après, je ne sais pas s'il existe déjà un outil tout fait pour cela où si d'autres logiciels déjà existant utilisent ce même système (afin de, éventuellement, s'en inspirer).

[wiztricks]

Après, je ne sais pas s'il existe déjà un outil tout fait pour cela où si d'autres logiciels déjà existant utilisent ce même système (afin de, éventuellement, s'en inspirer).

Automatiser certains changement est possible mais il y aura toujours des "conflits" qui devront être arbitrés: on peut réduire leur nombre, faciliter les arbitrages,... Mais il faudra toujours une mécanique humaine qui dise OK/KO dans certains cas.
Dit autrement, vous devez établir un processus de gestion du changement contrôlé par des humains et assisté par les machines et non espérer que les machines puissent tout régler - enfin, pas dans tous les domaines dans un avenir proche -.
- W

[Pico51]

J'en suis parfaitement conscient mais le but est de limiter au maximum les interventions humaines.

Voilà pourquoi je souhaite réaliser ce "type" de système.