J'ai actuellement une application qui est connecté à une base de données et
qui effectue divers traitement.
J'ai dans cette application deux états de sortie (qui ne sont pas des états
Crystal report mais du code)
J'aimerais pouvoir rajouter des états de sortie à volontée. En fait,
j'aimerais que mon utilisateur puisse choisir dans une liste d'état ceux
qu'il veux intégrer à l'application. Je voudrais donc que le code de chaque
état soit externe à mon application mais ke le code de mon application
puisse les inégrer dans ce choix de possibilité de sortie.
Ce serait en fait une sorte de classe avec des propriétés mais totalement
externe à mon application (sauf sa structure) et que mon application
appellerait.
Je pense que cela doit exister mais je ne vois pas du tout comment faire?
Quelqu'un pourrait-il m'aider... J'espère avoir été assez claire
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Arnaud Debaene
microsoft wrote:
Bonjour,
J'ai actuellement une application qui est connecté à une base de données et qui effectue divers traitement. J'ai dans cette application deux états de sortie (qui ne sont pas des états Crystal report mais du code)
J'aimerais pouvoir rajouter des états de sortie à volontée. En fait, j'aimerais que mon utilisateur puisse choisir dans une liste d'état ceux qu'il veux intégrer à l'application. Je voudrais donc que le code de chaque état soit externe à mon application mais ke le code de mon application puisse les inégrer dans ce choix de possibilité de sortie.
Ce serait en fait une sorte de classe avec des propriétés mais totalement externe à mon application (sauf sa structure) et que mon application appellerait.
Je pense que cela doit exister mais je ne vois pas du tout comment faire?
C'est un système de plugin qu'il te faut plugin en clair...
Commences par définir une interface que tous les états devons implémenter et que ton application utilisera pour communiquer avec eux. Appelons cette interface IEtat. Elle est définie dans ton programme principal ou bien dans une assembly spécifique qui ne contient que çà.
Chaque plugin sera dans une assembly (dll) séparée. Il faudra un mécanisme pour localiser ces assemblies. Une solution simple est de mettre tous les plugins dans un sous-répertoire spécifique de l'application, mais d'autres options sont envisageables (plugins listés dans un fichier de configuration, etc...)
Supposons que toutes les assemblies de plugin soient dans un répertoire spécifique. Pour les charges, les opérations à effectuer sont : - lister toutes les dlls dans le répertoire (System.IO.DirectoryInfo.GetFiles). - pour chaque dll, essayer de la charger - ca ne marchera que s'il s'agit effectivement d'une assembly (System.AppDomain.Load). - Pour chaque assembly chargée, vérifier tous les types exportés par l'assembly (Assembly.GetExportedTypes) et cherche un type qui implémente IEtat (Type.FindInterface ou bien Type.IsSubclassOf). - Créer un objet du type en question (Type.GetConstructors puis invocation par réflection). - caster l'objet retourné en IEtat, puis manipuler le plugin via cette interface.
Arnaud MVP - VC
microsoft wrote:
Bonjour,
J'ai actuellement une application qui est connecté à une base de
données et qui effectue divers traitement.
J'ai dans cette application deux états de sortie (qui ne sont pas des
états Crystal report mais du code)
J'aimerais pouvoir rajouter des états de sortie à volontée. En fait,
j'aimerais que mon utilisateur puisse choisir dans une liste d'état
ceux qu'il veux intégrer à l'application. Je voudrais donc que le
code de chaque état soit externe à mon application mais ke le code de
mon application puisse les inégrer dans ce choix de possibilité de
sortie.
Ce serait en fait une sorte de classe avec des propriétés mais
totalement externe à mon application (sauf sa structure) et que mon
application appellerait.
Je pense que cela doit exister mais je ne vois pas du tout comment
faire?
C'est un système de plugin qu'il te faut plugin en clair...
Commences par définir une interface que tous les états devons implémenter et
que ton application utilisera pour communiquer avec eux. Appelons cette
interface IEtat. Elle est définie dans ton programme principal ou bien dans
une assembly spécifique qui ne contient que çà.
Chaque plugin sera dans une assembly (dll) séparée. Il faudra un mécanisme
pour localiser ces assemblies. Une solution simple est de mettre tous les
plugins dans un sous-répertoire spécifique de l'application, mais d'autres
options sont envisageables (plugins listés dans un fichier de configuration,
etc...)
Supposons que toutes les assemblies de plugin soient dans un répertoire
spécifique. Pour les charges, les opérations à effectuer sont :
- lister toutes les dlls dans le répertoire
(System.IO.DirectoryInfo.GetFiles).
- pour chaque dll, essayer de la charger - ca ne marchera que s'il s'agit
effectivement d'une assembly (System.AppDomain.Load).
- Pour chaque assembly chargée, vérifier tous les types exportés par
l'assembly (Assembly.GetExportedTypes) et cherche un type qui implémente
IEtat (Type.FindInterface ou bien Type.IsSubclassOf).
- Créer un objet du type en question (Type.GetConstructors puis invocation
par réflection).
- caster l'objet retourné en IEtat, puis manipuler le plugin via cette
interface.
J'ai actuellement une application qui est connecté à une base de données et qui effectue divers traitement. J'ai dans cette application deux états de sortie (qui ne sont pas des états Crystal report mais du code)
J'aimerais pouvoir rajouter des états de sortie à volontée. En fait, j'aimerais que mon utilisateur puisse choisir dans une liste d'état ceux qu'il veux intégrer à l'application. Je voudrais donc que le code de chaque état soit externe à mon application mais ke le code de mon application puisse les inégrer dans ce choix de possibilité de sortie.
Ce serait en fait une sorte de classe avec des propriétés mais totalement externe à mon application (sauf sa structure) et que mon application appellerait.
Je pense que cela doit exister mais je ne vois pas du tout comment faire?
C'est un système de plugin qu'il te faut plugin en clair...
Commences par définir une interface que tous les états devons implémenter et que ton application utilisera pour communiquer avec eux. Appelons cette interface IEtat. Elle est définie dans ton programme principal ou bien dans une assembly spécifique qui ne contient que çà.
Chaque plugin sera dans une assembly (dll) séparée. Il faudra un mécanisme pour localiser ces assemblies. Une solution simple est de mettre tous les plugins dans un sous-répertoire spécifique de l'application, mais d'autres options sont envisageables (plugins listés dans un fichier de configuration, etc...)
Supposons que toutes les assemblies de plugin soient dans un répertoire spécifique. Pour les charges, les opérations à effectuer sont : - lister toutes les dlls dans le répertoire (System.IO.DirectoryInfo.GetFiles). - pour chaque dll, essayer de la charger - ca ne marchera que s'il s'agit effectivement d'une assembly (System.AppDomain.Load). - Pour chaque assembly chargée, vérifier tous les types exportés par l'assembly (Assembly.GetExportedTypes) et cherche un type qui implémente IEtat (Type.FindInterface ou bien Type.IsSubclassOf). - Créer un objet du type en question (Type.GetConstructors puis invocation par réflection). - caster l'objet retourné en IEtat, puis manipuler le plugin via cette interface.
Arnaud MVP - VC
Bismark Prods
Hello,
Tu as un lien qui explique ca encore + en détail ?
"Arnaud Debaene" a écrit dans le message de news:%
microsoft wrote: > Bonjour, > > J'ai actuellement une application qui est connecté à une base de > données et qui effectue divers traitement. > J'ai dans cette application deux états de sortie (qui ne sont pas des > états Crystal report mais du code) > > J'aimerais pouvoir rajouter des états de sortie à volontée. En fait, > j'aimerais que mon utilisateur puisse choisir dans une liste d'état > ceux qu'il veux intégrer à l'application. Je voudrais donc que le > code de chaque état soit externe à mon application mais ke le code de > mon application puisse les inégrer dans ce choix de possibilité de > sortie. > > Ce serait en fait une sorte de classe avec des propriétés mais > totalement externe à mon application (sauf sa structure) et que mon > application appellerait. > > Je pense que cela doit exister mais je ne vois pas du tout comment > faire?
C'est un système de plugin qu'il te faut plugin en clair...
Commences par définir une interface que tous les états devons implémenter
et
que ton application utilisera pour communiquer avec eux. Appelons cette interface IEtat. Elle est définie dans ton programme principal ou bien
dans
une assembly spécifique qui ne contient que çà.
Chaque plugin sera dans une assembly (dll) séparée. Il faudra un mécanisme pour localiser ces assemblies. Une solution simple est de mettre tous les plugins dans un sous-répertoire spécifique de l'application, mais d'autres options sont envisageables (plugins listés dans un fichier de
configuration,
etc...)
Supposons que toutes les assemblies de plugin soient dans un répertoire spécifique. Pour les charges, les opérations à effectuer sont : - lister toutes les dlls dans le répertoire (System.IO.DirectoryInfo.GetFiles). - pour chaque dll, essayer de la charger - ca ne marchera que s'il s'agit effectivement d'une assembly (System.AppDomain.Load). - Pour chaque assembly chargée, vérifier tous les types exportés par l'assembly (Assembly.GetExportedTypes) et cherche un type qui implémente IEtat (Type.FindInterface ou bien Type.IsSubclassOf). - Créer un objet du type en question (Type.GetConstructors puis invocation par réflection). - caster l'objet retourné en IEtat, puis manipuler le plugin via cette interface.
Arnaud MVP - VC
Hello,
Tu as un lien qui explique ca encore + en détail ?
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message de
news:%23WzqadvVEHA.2928@tk2msftngp13.phx.gbl...
microsoft wrote:
> Bonjour,
>
> J'ai actuellement une application qui est connecté à une base de
> données et qui effectue divers traitement.
> J'ai dans cette application deux états de sortie (qui ne sont pas des
> états Crystal report mais du code)
>
> J'aimerais pouvoir rajouter des états de sortie à volontée. En fait,
> j'aimerais que mon utilisateur puisse choisir dans une liste d'état
> ceux qu'il veux intégrer à l'application. Je voudrais donc que le
> code de chaque état soit externe à mon application mais ke le code de
> mon application puisse les inégrer dans ce choix de possibilité de
> sortie.
>
> Ce serait en fait une sorte de classe avec des propriétés mais
> totalement externe à mon application (sauf sa structure) et que mon
> application appellerait.
>
> Je pense que cela doit exister mais je ne vois pas du tout comment
> faire?
C'est un système de plugin qu'il te faut plugin en clair...
Commences par définir une interface que tous les états devons implémenter
et
que ton application utilisera pour communiquer avec eux. Appelons cette
interface IEtat. Elle est définie dans ton programme principal ou bien
dans
une assembly spécifique qui ne contient que çà.
Chaque plugin sera dans une assembly (dll) séparée. Il faudra un mécanisme
pour localiser ces assemblies. Une solution simple est de mettre tous les
plugins dans un sous-répertoire spécifique de l'application, mais d'autres
options sont envisageables (plugins listés dans un fichier de
configuration,
etc...)
Supposons que toutes les assemblies de plugin soient dans un répertoire
spécifique. Pour les charges, les opérations à effectuer sont :
- lister toutes les dlls dans le répertoire
(System.IO.DirectoryInfo.GetFiles).
- pour chaque dll, essayer de la charger - ca ne marchera que s'il s'agit
effectivement d'une assembly (System.AppDomain.Load).
- Pour chaque assembly chargée, vérifier tous les types exportés par
l'assembly (Assembly.GetExportedTypes) et cherche un type qui implémente
IEtat (Type.FindInterface ou bien Type.IsSubclassOf).
- Créer un objet du type en question (Type.GetConstructors puis invocation
par réflection).
- caster l'objet retourné en IEtat, puis manipuler le plugin via cette
interface.
Tu as un lien qui explique ca encore + en détail ?
"Arnaud Debaene" a écrit dans le message de news:%
microsoft wrote: > Bonjour, > > J'ai actuellement une application qui est connecté à une base de > données et qui effectue divers traitement. > J'ai dans cette application deux états de sortie (qui ne sont pas des > états Crystal report mais du code) > > J'aimerais pouvoir rajouter des états de sortie à volontée. En fait, > j'aimerais que mon utilisateur puisse choisir dans une liste d'état > ceux qu'il veux intégrer à l'application. Je voudrais donc que le > code de chaque état soit externe à mon application mais ke le code de > mon application puisse les inégrer dans ce choix de possibilité de > sortie. > > Ce serait en fait une sorte de classe avec des propriétés mais > totalement externe à mon application (sauf sa structure) et que mon > application appellerait. > > Je pense que cela doit exister mais je ne vois pas du tout comment > faire?
C'est un système de plugin qu'il te faut plugin en clair...
Commences par définir une interface que tous les états devons implémenter
et
que ton application utilisera pour communiquer avec eux. Appelons cette interface IEtat. Elle est définie dans ton programme principal ou bien
dans
une assembly spécifique qui ne contient que çà.
Chaque plugin sera dans une assembly (dll) séparée. Il faudra un mécanisme pour localiser ces assemblies. Une solution simple est de mettre tous les plugins dans un sous-répertoire spécifique de l'application, mais d'autres options sont envisageables (plugins listés dans un fichier de
configuration,
etc...)
Supposons que toutes les assemblies de plugin soient dans un répertoire spécifique. Pour les charges, les opérations à effectuer sont : - lister toutes les dlls dans le répertoire (System.IO.DirectoryInfo.GetFiles). - pour chaque dll, essayer de la charger - ca ne marchera que s'il s'agit effectivement d'une assembly (System.AppDomain.Load). - Pour chaque assembly chargée, vérifier tous les types exportés par l'assembly (Assembly.GetExportedTypes) et cherche un type qui implémente IEtat (Type.FindInterface ou bien Type.IsSubclassOf). - Créer un objet du type en question (Type.GetConstructors puis invocation par réflection). - caster l'objet retourné en IEtat, puis manipuler le plugin via cette interface.
Arnaud MVP - VC
adebaene
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message news:...
Hello,
Tu as un lien qui explique ca encore + en détail ?
Comme çà, non, mais c'est vraiement simple une foie que tu as compris le principe de l'interface implémentée par les différents plugins. Le reste, c'est du bricolage assez basique.
Arnaud MVP - VC
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message news:<OPS49bwVEHA.1036@TK2MSFTNGP12.phx.gbl>...
Hello,
Tu as un lien qui explique ca encore + en détail ?
Comme çà, non, mais c'est vraiement simple une foie que tu as compris
le principe de l'interface implémentée par les différents plugins. Le
reste, c'est du bricolage assez basique.
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message news:...
Hello,
Tu as un lien qui explique ca encore + en détail ?
Comme çà, non, mais c'est vraiement simple une foie que tu as compris le principe de l'interface implémentée par les différents plugins. Le reste, c'est du bricolage assez basique.
Arnaud MVP - VC
Sylo
Ok merci... c vrai ke cela à l'air logique... Si je te dit ke c'est l'équivalent d'un active xX (user control) extern
Pour ces user control externe, on crée un nouveau projet user control, et on cré le controle et on le génère.. Ensuite, dans le projet applicatif, on intégre une référence à la DLL du user control généré et il est intégré en tant ke classe
Mais la, dans ce cas, le user control est connue et intégré avant...
Mais est ce ke je suis pas loin ????
Sylvain
"Arnaud Debaene" a écrit dans le message de news:
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message
news:...
> Hello, > > Tu as un lien qui explique ca encore + en détail ?
Comme çà, non, mais c'est vraiement simple une foie que tu as compris le principe de l'interface implémentée par les différents plugins. Le reste, c'est du bricolage assez basique.
Arnaud MVP - VC
Ok merci... c vrai ke cela à l'air logique...
Si je te dit ke c'est l'équivalent d'un active xX (user control) extern
Pour ces user control externe, on crée un nouveau projet user control, et on
cré le controle et on le génère..
Ensuite, dans le projet applicatif, on intégre une référence à la DLL du
user control généré et il est intégré en tant ke classe
Mais la, dans ce cas, le user control est connue et intégré avant...
Mais est ce ke je suis pas loin ????
Sylvain
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message de
news:16a4a8c7.0406210119.7d80fcae@posting.google.com...
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message
news:<OPS49bwVEHA.1036@TK2MSFTNGP12.phx.gbl>...
> Hello,
>
> Tu as un lien qui explique ca encore + en détail ?
Comme çà, non, mais c'est vraiement simple une foie que tu as compris
le principe de l'interface implémentée par les différents plugins. Le
reste, c'est du bricolage assez basique.
Ok merci... c vrai ke cela à l'air logique... Si je te dit ke c'est l'équivalent d'un active xX (user control) extern
Pour ces user control externe, on crée un nouveau projet user control, et on cré le controle et on le génère.. Ensuite, dans le projet applicatif, on intégre une référence à la DLL du user control généré et il est intégré en tant ke classe
Mais la, dans ce cas, le user control est connue et intégré avant...
Mais est ce ke je suis pas loin ????
Sylvain
"Arnaud Debaene" a écrit dans le message de news:
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message
news:...
> Hello, > > Tu as un lien qui explique ca encore + en détail ?
Comme çà, non, mais c'est vraiement simple une foie que tu as compris le principe de l'interface implémentée par les différents plugins. Le reste, c'est du bricolage assez basique.
Arnaud MVP - VC
Sylo
Arnaud, vraimment, merci pour ton aide... Encore une petite question, peux tu me dire si ce ke tu m'explique correspond bien au lien suivant:
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message
news:...
> Hello, > > Tu as un lien qui explique ca encore + en détail ?
Comme çà, non, mais c'est vraiement simple une foie que tu as compris le principe de l'interface implémentée par les différents plugins. Le reste, c'est du bricolage assez basique.
Arnaud MVP - VC
Arnaud, vraimment, merci pour ton aide... Encore une petite question, peux
tu me dire si ce ke tu m'explique correspond bien au lien suivant:
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message de
news:16a4a8c7.0406210119.7d80fcae@posting.google.com...
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message
news:<OPS49bwVEHA.1036@TK2MSFTNGP12.phx.gbl>...
> Hello,
>
> Tu as un lien qui explique ca encore + en détail ?
Comme çà, non, mais c'est vraiement simple une foie que tu as compris
le principe de l'interface implémentée par les différents plugins. Le
reste, c'est du bricolage assez basique.
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message
news:...
> Hello, > > Tu as un lien qui explique ca encore + en détail ?
Comme çà, non, mais c'est vraiement simple une foie que tu as compris le principe de l'interface implémentée par les différents plugins. Le reste, c'est du bricolage assez basique.
