Je souhaite gérer des briques applicatives un peu dans le genre d'un portail
à la iGoogle.
Pour cela je suis parti sur un concept de compo ascx implémentant une
interface de façon à gérer une description et des paramètres.
Mon problème se situe au niveau de l'initialisation lorsque je déclare un
sub New car en fait le constructeur est déjà créé automatiquement dans le
cadre d'un compo ascx !
Evidemment je ne suis pas sûr de la méthode et je souhaite au final lister
tous mes compos ascx et en les interrogeant savoir quel est leur nom, leur
description et les propriétés à remplir.
Pouvez vous me dire s'il y a une solution pour le problème de surcharge du
new vis-à-vis des compo ascx et plus largement avez vous des conseils pour
ce type de dev.
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
Patrice
Bonjour,
D'abord as tu regardé si les webparts 2.0 ferait l'affaire ? (http://humann.developpez.com/webpart/)
Sinon, à ma connaissance, la description des "gadgets" Google, Live ou autre est généralement mise dans un fichier XML qui décrit le composant ce qui évite d'avoir à instancier chaque composant pour y trouver le composant qui l'intéresse (et ces infos sont sans doute mises en base) ?
Cf System.Reflection pour inspecter les propriétés exposés par un type et les attributes (par exemple pour classer par catégorie les propriétés).
Encore une fois je regarderais d'abord si les webparts ne couvrirait pas ce besoin...
--- Patrice
"Tony" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
Je souhaite gérer des briques applicatives un peu dans le genre d'un portail à la iGoogle. Pour cela je suis parti sur un concept de compo ascx implémentant une interface de façon à gérer une description et des paramètres. Mon problème se situe au niveau de l'initialisation lorsque je déclare un sub New car en fait le constructeur est déjà créé automatiquement dans le cadre d'un compo ascx ! Evidemment je ne suis pas sûr de la méthode et je souhaite au final lister tous mes compos ascx et en les interrogeant savoir quel est leur nom, leur description et les propriétés à remplir.
Pouvez vous me dire s'il y a une solution pour le problème de surcharge du new vis-à-vis des compo ascx et plus largement avez vous des conseils pour ce type de dev.
Merci
Bonjour,
D'abord as tu regardé si les webparts 2.0 ferait l'affaire ?
(http://humann.developpez.com/webpart/)
Sinon, à ma connaissance, la description des "gadgets" Google, Live ou autre
est généralement mise dans un fichier XML qui décrit le composant ce qui
évite d'avoir à instancier chaque composant pour y trouver le composant qui
l'intéresse (et ces infos sont sans doute mises en base) ?
Cf System.Reflection pour inspecter les propriétés exposés par un type et
les attributes (par exemple pour classer par catégorie les propriétés).
Encore une fois je regarderais d'abord si les webparts ne couvrirait pas ce
besoin...
---
Patrice
"Tony" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
urfdXGilHHA.3280@TK2MSFTNGP05.phx.gbl...
Je souhaite gérer des briques applicatives un peu dans le genre d'un
portail à la iGoogle.
Pour cela je suis parti sur un concept de compo ascx implémentant une
interface de façon à gérer une description et des paramètres.
Mon problème se situe au niveau de l'initialisation lorsque je déclare un
sub New car en fait le constructeur est déjà créé automatiquement dans le
cadre d'un compo ascx !
Evidemment je ne suis pas sûr de la méthode et je souhaite au final lister
tous mes compos ascx et en les interrogeant savoir quel est leur nom, leur
description et les propriétés à remplir.
Pouvez vous me dire s'il y a une solution pour le problème de surcharge du
new vis-à-vis des compo ascx et plus largement avez vous des conseils pour
ce type de dev.
D'abord as tu regardé si les webparts 2.0 ferait l'affaire ? (http://humann.developpez.com/webpart/)
Sinon, à ma connaissance, la description des "gadgets" Google, Live ou autre est généralement mise dans un fichier XML qui décrit le composant ce qui évite d'avoir à instancier chaque composant pour y trouver le composant qui l'intéresse (et ces infos sont sans doute mises en base) ?
Cf System.Reflection pour inspecter les propriétés exposés par un type et les attributes (par exemple pour classer par catégorie les propriétés).
Encore une fois je regarderais d'abord si les webparts ne couvrirait pas ce besoin...
--- Patrice
"Tony" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
Je souhaite gérer des briques applicatives un peu dans le genre d'un portail à la iGoogle. Pour cela je suis parti sur un concept de compo ascx implémentant une interface de façon à gérer une description et des paramètres. Mon problème se situe au niveau de l'initialisation lorsque je déclare un sub New car en fait le constructeur est déjà créé automatiquement dans le cadre d'un compo ascx ! Evidemment je ne suis pas sûr de la méthode et je souhaite au final lister tous mes compos ascx et en les interrogeant savoir quel est leur nom, leur description et les propriétés à remplir.
Pouvez vous me dire s'il y a une solution pour le problème de surcharge du new vis-à-vis des compo ascx et plus largement avez vous des conseils pour ce type de dev.
Merci
Tony
Je vais jetter un oeil aux webparts pour voir si cela couvre mon besoin.
J'ai bien noté la reflexion sur le problème généré par l'obligation de créer un instance pour trouver le compo voulu et il est vrai que j'ai hésité entre une description xml et une implémentation dans les compos. J'ai fini par essayer une implémentation directement dans les compos pour éviter d'avoir à gérer une sorte de catalogue de compos à coté. J'ai aussi suivi la piste de system.reflection mais je souhaite plus que de parcourir les propriétés, avoir une description et une structure pour savoir comment remplir correctement les paramètres des compos.
Quel est votre avis sur le constructeur des ascx ? faut-il que je crée une classe normale pour avoir la main sur l'ensemble des méthodes ?
Merci
"Patrice" <http://www.chez.com/scribe/> a écrit dans le message de news:
Bonjour,
D'abord as tu regardé si les webparts 2.0 ferait l'affaire ? (http://humann.developpez.com/webpart/)
Sinon, à ma connaissance, la description des "gadgets" Google, Live ou autre est généralement mise dans un fichier XML qui décrit le composant ce qui évite d'avoir à instancier chaque composant pour y trouver le composant qui l'intéresse (et ces infos sont sans doute mises en base) ?
Cf System.Reflection pour inspecter les propriétés exposés par un type et les attributes (par exemple pour classer par catégorie les propriétés).
Encore une fois je regarderais d'abord si les webparts ne couvrirait pas ce besoin...
--- Patrice
"Tony" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
Je souhaite gérer des briques applicatives un peu dans le genre d'un portail à la iGoogle. Pour cela je suis parti sur un concept de compo ascx implémentant une interface de façon à gérer une description et des paramètres. Mon problème se situe au niveau de l'initialisation lorsque je déclare un sub New car en fait le constructeur est déjà créé automatiquement dans le cadre d'un compo ascx ! Evidemment je ne suis pas sûr de la méthode et je souhaite au final lister tous mes compos ascx et en les interrogeant savoir quel est leur nom, leur description et les propriétés à remplir.
Pouvez vous me dire s'il y a une solution pour le problème de surcharge du new vis-à-vis des compo ascx et plus largement avez vous des conseils pour ce type de dev.
Merci
Je vais jetter un oeil aux webparts pour voir si cela couvre mon besoin.
J'ai bien noté la reflexion sur le problème généré par l'obligation de créer
un instance pour trouver le compo voulu et il est vrai que j'ai hésité entre
une description xml et une implémentation dans les compos. J'ai fini par
essayer une implémentation directement dans les compos pour éviter d'avoir à
gérer une sorte de catalogue de compos à coté.
J'ai aussi suivi la piste de system.reflection mais je souhaite plus que de
parcourir les propriétés, avoir une description et une structure pour savoir
comment remplir correctement les paramètres des compos.
Quel est votre avis sur le constructeur des ascx ? faut-il que je crée une
classe normale pour avoir la main sur l'ensemble des méthodes ?
Merci
"Patrice" <http://www.chez.com/scribe/> a écrit dans le message de news:
Ow8lXeilHHA.1156@TK2MSFTNGP05.phx.gbl...
Bonjour,
D'abord as tu regardé si les webparts 2.0 ferait l'affaire ?
(http://humann.developpez.com/webpart/)
Sinon, à ma connaissance, la description des "gadgets" Google, Live ou
autre est généralement mise dans un fichier XML qui décrit le composant ce
qui évite d'avoir à instancier chaque composant pour y trouver le
composant qui l'intéresse (et ces infos sont sans doute mises en base) ?
Cf System.Reflection pour inspecter les propriétés exposés par un type et
les attributes (par exemple pour classer par catégorie les propriétés).
Encore une fois je regarderais d'abord si les webparts ne couvrirait pas
ce besoin...
---
Patrice
"Tony" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
urfdXGilHHA.3280@TK2MSFTNGP05.phx.gbl...
Je souhaite gérer des briques applicatives un peu dans le genre d'un
portail à la iGoogle.
Pour cela je suis parti sur un concept de compo ascx implémentant une
interface de façon à gérer une description et des paramètres.
Mon problème se situe au niveau de l'initialisation lorsque je déclare un
sub New car en fait le constructeur est déjà créé automatiquement dans le
cadre d'un compo ascx !
Evidemment je ne suis pas sûr de la méthode et je souhaite au final
lister tous mes compos ascx et en les interrogeant savoir quel est leur
nom, leur description et les propriétés à remplir.
Pouvez vous me dire s'il y a une solution pour le problème de surcharge
du new vis-à-vis des compo ascx et plus largement avez vous des conseils
pour ce type de dev.
Je vais jetter un oeil aux webparts pour voir si cela couvre mon besoin.
J'ai bien noté la reflexion sur le problème généré par l'obligation de créer un instance pour trouver le compo voulu et il est vrai que j'ai hésité entre une description xml et une implémentation dans les compos. J'ai fini par essayer une implémentation directement dans les compos pour éviter d'avoir à gérer une sorte de catalogue de compos à coté. J'ai aussi suivi la piste de system.reflection mais je souhaite plus que de parcourir les propriétés, avoir une description et une structure pour savoir comment remplir correctement les paramètres des compos.
Quel est votre avis sur le constructeur des ascx ? faut-il que je crée une classe normale pour avoir la main sur l'ensemble des méthodes ?
Merci
"Patrice" <http://www.chez.com/scribe/> a écrit dans le message de news:
Bonjour,
D'abord as tu regardé si les webparts 2.0 ferait l'affaire ? (http://humann.developpez.com/webpart/)
Sinon, à ma connaissance, la description des "gadgets" Google, Live ou autre est généralement mise dans un fichier XML qui décrit le composant ce qui évite d'avoir à instancier chaque composant pour y trouver le composant qui l'intéresse (et ces infos sont sans doute mises en base) ?
Cf System.Reflection pour inspecter les propriétés exposés par un type et les attributes (par exemple pour classer par catégorie les propriétés).
Encore une fois je regarderais d'abord si les webparts ne couvrirait pas ce besoin...
--- Patrice
"Tony" <tony_barret@(no_spam)hotmail.com> a écrit dans le message de news:
Je souhaite gérer des briques applicatives un peu dans le genre d'un portail à la iGoogle. Pour cela je suis parti sur un concept de compo ascx implémentant une interface de façon à gérer une description et des paramètres. Mon problème se situe au niveau de l'initialisation lorsque je déclare un sub New car en fait le constructeur est déjà créé automatiquement dans le cadre d'un compo ascx ! Evidemment je ne suis pas sûr de la méthode et je souhaite au final lister tous mes compos ascx et en les interrogeant savoir quel est leur nom, leur description et les propriétés à remplir.
Pouvez vous me dire s'il y a une solution pour le problème de surcharge du new vis-à-vis des compo ascx et plus largement avez vous des conseils pour ce type de dev.
