Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement ASP.Net Q: Design de WebComponent.

Q: Design de WebComponent.

10 réponses
Avatar
S.Sigal
Bonjour:
(Et excuser mon francais ecrit terrible...)

Je cherche des reponse/verification au questions suivants sur le 'principe' de design de
CompositeControls complex...

Question A:
a) Comment faire des Components qui change de 'form'? Si vous avez un control qui contient un
SELECT, qui montre un enum [Semains, Mois, Annee], et son SelectIndexChanged determine quelle vue
montrer, la question est comment faire pour montrer cette vue intelligament. Les choix que je vois
sont :
a.1) Dans Render(), je change de layout (table 2 columns, 7 columns, ou 6, etc.). Le problem avec
cette methodology est que Render est apres OnLoad -- alors tout EventHandler attacher au cellule
sont trop tard. Tout ce que
j'ai reussi a faire etait de mettre du JS sur le Table.onclick...et passer ceci au server dans un
hidden field. Pas tres costaud...
a.2) Solutions vue dans un blog: faire dans OnLoad le layout de grid -- mais vide -- et racorder les
EventHandler la. Ensuite, plus tard dans Render, mettre les numero dans les casse... Ce method
marcherait pour peutetre un control de mois -- mais je vois mal faire tout ce travaille pour
jour/semaine/mois, etc...pour mettre a la poubelle 75%....
a.3) Faire les controls pour le Mois, Annee, etc. des autre control. (CalendarYear, CalendarMois,
etc.) qui sont ajouter a Calendar.Controls[] dans Calendar.PreRender() -- ce ci a l'avantage du fait
que meme si Calendar a deja passer OnLoad et est deja a OnPreRender/OnLoad -- les sousControls
(calendarMois) va vite se ratrepper...et passer a travers OnInit, OnLoad, [LesEventsHandlers!], et
finalement arriver a PreRender aussi.
Du EventHandler du souscontrol je appelle manualement le EventHandler dans Calendar -- (trop tard
pour BubbleEvent ou autre solution). Cette solution, a laire beucoup plus flexible...sauf un des
bouton. Sur le CalendarMonth, chaque row a un ShowWeek button -- qui devrait causer un changement de
vue. Mais si le parent control est deja a Render() -- le event est trop tard -- pas de chance a
changer de vue et sauvegarder dans ViewState. Alors on bouge le LoadSubViewControl() a PreRender
plutot que Render()....
a.4) et c'est possible que il ya d'autre que je ne connais pas encore?

Question B:
Vous me dite que 'ben alors...le problem est regler, non?'....pas si vite :-) J'ai tellement galerer
les derniers semaines en train de comprendres ces choix -- que j'aimerai -- si possible -- un peu de
verification que la logique est bonne/fiable...bref, le meilleur... Solution a.3 ma l'aire plus
modulaire est plus logique en temps de event handling...mais esque oui? J'arrive pas a 'voir'
comment je devrait ecrir la part DataBind() du parent pour attacher le data au controls child...?


Et je me suis trouver dans un colle avec le handling des properties qui vont avec ce structure:


Question C:
Dans le livre de microsoft "Developing Microsoft Asp.net Server Controls and Components" (tres tres
bien!) le demarche pour ecrire un control et ses Styles, etait un peu comme ceci:
b.1) Overload SaveViewState(){ object[] blobs = new object[2]; blobs[0] =
base.SaveViewState();blobs[1] = _InnerButton.SaveViewState();} et inverser ce process dans
LoadViewState()...
b.2) Puis que j'ai beaucoup de Style objects pour chaque view (environs 5 pars vue, fait 20 Styles
object total), j'ai fait des class comme ceci:
class CSS_Month : IStateHandler {}
class CSS_Year : IStateHandler {}
qui sont ensuit sauvegarder dans viewState de Calendar.

Mais la je me demande si c'est possible de 'economiser' les gestes et faire que au lieu de garder
tout les Properties dans Calendar, et les copier a CalendarMonth/CalendarYear quands ils sont
instantier (voir a.3...) que je offre
un instance de CalendarMonth comme property de Calendar... Huh?Quoi?!? Hum: je veut dire:

class Calendar (){
public CalendarDay Day {get {return _Day;}
CalendarDay _Day = new CalendarDay();
...
}

pour que le XML serialize est:

<CC:CALENDAR View="Day">
<MONTH ShowHeader=true>
<InnerHeaderStyle.....etc.>
</MONTH>
<DAY>
<InnerHeaderStyle.....etc.>
</DAY
</CC:CALENDAR>


Plutot que:

<CC:CALENDAR View="DAY">
<CSS>
<MONTH...>
<DAY...>
</CSS>
<SETTINGS>\
<MONTH...>
<DAY...
</SETTINGS>
<BEVAHIOUR>
<MONTH ShowHeader=true>
etc.
</BEHAVIOUR>
</CC:CALENDAR>

Vous voyer? Solution A est plus 'modulaire'...plus compact... (Il faut pas oublier de maitre
ExpandableObject TypeConverter sur les CalendarView et CalendarDay...pour que ils aparait dans le
PropertyPanel du IDE...)

Seul Hic -- ca marche ...presque. Bug? Le IDE se perde les pedals et quands je change un value Style
de CalendarMonth il inject le xml dans... Calendar -- et pas CalendarMonth! Je crois pas qu'il sait
quelle control est le control que ils est. Solution?



Question C: Control.Clone - ca existe ?

Avec le control decrit comme property on peut, au Calendar.OnPreRender() etre ultra simple:
this.Controls.Add(this.Month);... ben oui... ca marche!
Bien sure ca marche pas pour l'annee..
for (int i=0;i<12;i++){Controls.Add(this.Month)....}
Ya t'il quelque chose comme Clone?
for (int i=0;i<12;i++){Controls.Add(this.Month.Clone())....}




Question D: Attribute.Default Value -- et les styles...
Ce qui est bien avec DefaultValue() c'est qui ci c'est mis -- le Property n'est pas ecrit au xml si
il est egal au DefaultValue... ca marche tres biens pour les simple types (string, bool, etc..
Mais pas bien pour les Style (complex type):

[DefaultValue("")]
public Style SSS {get {if (_SSS ==null){SSS=new Style();_SSS.CssClass="MYDEFAULTCLASS";};return
_SSS;}}
private Style _SSS;

...qui mets dans le xml

<CC:MYCONTROL SSS-CONTROLSTYLE="MYDEFAULTCLASS"/>







Ouf! Je croit que j'ai reussi a mettre sur papier tout les question qui me nargait.... Je vous
remercie tous de l'avoir lu...(rester reveiller ?!) meme ci cetait vraiment long...Merci.
En esperant beaucoup de reponse
:-)
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
Avatar
YJLAMOTTE
OUUUUUUUUFFFFFFFFFFFF :)

Tu veux pas découper ton post en plusieurs questions ... ca donne pas envie
de te répondre.. Je l'imprime, je relie au calme.. et puis on va voir ce
qu'on peut faire...

YJLAMOTTE

"S.Sigal" wrote:


Bonjour:
(Et excuser mon francais ecrit terrible...)

Je cherche des reponse/verification au questions suivants sur le 'principe' de design de
CompositeControls complex...

Question A:
a) Comment faire des Components qui change de 'form'? Si vous avez un control qui contient un
SELECT, qui montre un enum [Semains, Mois, Annee], et son SelectIndexChanged determine quelle vue
montrer, la question est comment faire pour montrer cette vue intelligament. Les choix que je vois
sont :
a.1) Dans Render(), je change de layout (table 2 columns, 7 columns, ou 6, etc.). Le problem avec
cette methodology est que Render est apres OnLoad -- alors tout EventHandler attacher au cellule
sont trop tard. Tout ce que
j'ai reussi a faire etait de mettre du JS sur le Table.onclick...et passer ceci au server dans un
hidden field. Pas tres costaud...
a.2) Solutions vue dans un blog: faire dans OnLoad le layout de grid -- mais vide -- et racorder les
EventHandler la. Ensuite, plus tard dans Render, mettre les numero dans les casse... Ce method
marcherait pour peutetre un control de mois -- mais je vois mal faire tout ce travaille pour
jour/semaine/mois, etc...pour mettre a la poubelle 75%....
a.3) Faire les controls pour le Mois, Annee, etc. des autre control. (CalendarYear, CalendarMois,
etc.) qui sont ajouter a Calendar.Controls[] dans Calendar.PreRender() -- ce ci a l'avantage du fait
que meme si Calendar a deja passer OnLoad et est deja a OnPreRender/OnLoad -- les sousControls
(calendarMois) va vite se ratrepper...et passer a travers OnInit, OnLoad, [LesEventsHandlers!], et
finalement arriver a PreRender aussi.
Du EventHandler du souscontrol je appelle manualement le EventHandler dans Calendar -- (trop tard
pour BubbleEvent ou autre solution). Cette solution, a laire beucoup plus flexible...sauf un des
bouton. Sur le CalendarMonth, chaque row a un ShowWeek button -- qui devrait causer un changement de
vue. Mais si le parent control est deja a Render() -- le event est trop tard -- pas de chance a
changer de vue et sauvegarder dans ViewState. Alors on bouge le LoadSubViewControl() a PreRender
plutot que Render()....
a.4) et c'est possible que il ya d'autre que je ne connais pas encore?

Question B:
Vous me dite que 'ben alors...le problem est regler, non?'....pas si vite :-) J'ai tellement galerer
les derniers semaines en train de comprendres ces choix -- que j'aimerai -- si possible -- un peu de
verification que la logique est bonne/fiable...bref, le meilleur... Solution a.3 ma l'aire plus
modulaire est plus logique en temps de event handling...mais esque oui? J'arrive pas a 'voir'
comment je devrait ecrir la part DataBind() du parent pour attacher le data au controls child...?


Et je me suis trouver dans un colle avec le handling des properties qui vont avec ce structure:


Question C:
Dans le livre de microsoft "Developing Microsoft Asp.net Server Controls and Components" (tres tres
bien!) le demarche pour ecrire un control et ses Styles, etait un peu comme ceci:
b.1) Overload SaveViewState(){ object[] blobs = new object[2]; blobs[0] > base.SaveViewState();blobs[1] = _InnerButton.SaveViewState();} et inverser ce process dans
LoadViewState()...
b.2) Puis que j'ai beaucoup de Style objects pour chaque view (environs 5 pars vue, fait 20 Styles
object total), j'ai fait des class comme ceci:
class CSS_Month : IStateHandler {}
class CSS_Year : IStateHandler {}
qui sont ensuit sauvegarder dans viewState de Calendar.

Mais la je me demande si c'est possible de 'economiser' les gestes et faire que au lieu de garder
tout les Properties dans Calendar, et les copier a CalendarMonth/CalendarYear quands ils sont
instantier (voir a.3...) que je offre
un instance de CalendarMonth comme property de Calendar... Huh?Quoi?!? Hum: je veut dire:

class Calendar (){
public CalendarDay Day {get {return _Day;}
CalendarDay _Day = new CalendarDay();
....
}

pour que le XML serialize est:

<CC:CALENDAR View="Day">
<MONTH ShowHeader=true>
<InnerHeaderStyle.....etc.>
</MONTH>
<DAY>
<InnerHeaderStyle.....etc.>
</DAY
</CC:CALENDAR>


Plutot que:

<CC:CALENDAR View="DAY">
<CSS>
<MONTH...>
<DAY...>
</CSS>
<SETTINGS>
<MONTH...>
<DAY...
</SETTINGS>
<BEVAHIOUR>
<MONTH ShowHeader=true>
etc.
</BEHAVIOUR>
</CC:CALENDAR>

Vous voyer? Solution A est plus 'modulaire'...plus compact... (Il faut pas oublier de maitre
ExpandableObject TypeConverter sur les CalendarView et CalendarDay...pour que ils aparait dans le
PropertyPanel du IDE...)

Seul Hic -- ca marche ...presque. Bug? Le IDE se perde les pedals et quands je change un value Style
de CalendarMonth il inject le xml dans... Calendar -- et pas CalendarMonth! Je crois pas qu'il sait
quelle control est le control que ils est. Solution?



Question C: Control.Clone - ca existe ?

Avec le control decrit comme property on peut, au Calendar.OnPreRender() etre ultra simple:
this.Controls.Add(this.Month);... ben oui... ca marche!
Bien sure ca marche pas pour l'annee..
for (int i=0;i<12;i++){Controls.Add(this.Month)....}
Ya t'il quelque chose comme Clone?
for (int i=0;i<12;i++){Controls.Add(this.Month.Clone())....}




Question D: Attribute.Default Value -- et les styles...
Ce qui est bien avec DefaultValue() c'est qui ci c'est mis -- le Property n'est pas ecrit au xml si
il est egal au DefaultValue... ca marche tres biens pour les simple types (string, bool, etc..
Mais pas bien pour les Style (complex type):

[DefaultValue("")]
public Style SSS {get {if (_SSS ==null){SSS=new Style();_SSS.CssClass="MYDEFAULTCLASS";};return
_SSS;}}
private Style _SSS;

....qui mets dans le xml

<CC:MYCONTROL SSS-CONTROLSTYLE="MYDEFAULTCLASS"/>







Ouf! Je croit que j'ai reussi a mettre sur papier tout les question qui me nargait.... Je vous
remercie tous de l'avoir lu...(rester reveiller ?!) meme ci cetait vraiment long...Merci.
En esperant beaucoup de reponse
:-)







Avatar
YJLAMOTTE
Je crois que Control.Clone n'existe pas.. en tout cas j'ai pas trouvé dans
MSDN.
IL ya Control.Create mais c pour les winforms et ca n'a pas l'air d'avoir un
rapport avec ce que tu veux faire

IL va falloir que tu fasses une petite fonction du style

private Control CloneControl(Control MonControle)
{
Control ReturnControl = new Control();
ReturnControl.Propriété1 = MonControle..Propriété1;
etc etc

return ReturnControl
}

Pour la suite, ce sera un prochain post.

YJLAMOTTE

"S.Sigal" wrote:


Bonjour:
(Et excuser mon francais ecrit terrible...)

Je cherche des reponse/verification au questions suivants sur le 'principe' de design de
CompositeControls complex...

Question A:
a) Comment faire des Components qui change de 'form'? Si vous avez un control qui contient un
SELECT, qui montre un enum [Semains, Mois, Annee], et son SelectIndexChanged determine quelle vue
montrer, la question est comment faire pour montrer cette vue intelligament. Les choix que je vois
sont :
a.1) Dans Render(), je change de layout (table 2 columns, 7 columns, ou 6, etc.). Le problem avec
cette methodology est que Render est apres OnLoad -- alors tout EventHandler attacher au cellule
sont trop tard. Tout ce que
j'ai reussi a faire etait de mettre du JS sur le Table.onclick...et passer ceci au server dans un
hidden field. Pas tres costaud...
a.2) Solutions vue dans un blog: faire dans OnLoad le layout de grid -- mais vide -- et racorder les
EventHandler la. Ensuite, plus tard dans Render, mettre les numero dans les casse... Ce method
marcherait pour peutetre un control de mois -- mais je vois mal faire tout ce travaille pour
jour/semaine/mois, etc...pour mettre a la poubelle 75%....
a.3) Faire les controls pour le Mois, Annee, etc. des autre control. (CalendarYear, CalendarMois,
etc.) qui sont ajouter a Calendar.Controls[] dans Calendar.PreRender() -- ce ci a l'avantage du fait
que meme si Calendar a deja passer OnLoad et est deja a OnPreRender/OnLoad -- les sousControls
(calendarMois) va vite se ratrepper...et passer a travers OnInit, OnLoad, [LesEventsHandlers!], et
finalement arriver a PreRender aussi.
Du EventHandler du souscontrol je appelle manualement le EventHandler dans Calendar -- (trop tard
pour BubbleEvent ou autre solution). Cette solution, a laire beucoup plus flexible...sauf un des
bouton. Sur le CalendarMonth, chaque row a un ShowWeek button -- qui devrait causer un changement de
vue. Mais si le parent control est deja a Render() -- le event est trop tard -- pas de chance a
changer de vue et sauvegarder dans ViewState. Alors on bouge le LoadSubViewControl() a PreRender
plutot que Render()....
a.4) et c'est possible que il ya d'autre que je ne connais pas encore?

Question B:
Vous me dite que 'ben alors...le problem est regler, non?'....pas si vite :-) J'ai tellement galerer
les derniers semaines en train de comprendres ces choix -- que j'aimerai -- si possible -- un peu de
verification que la logique est bonne/fiable...bref, le meilleur... Solution a.3 ma l'aire plus
modulaire est plus logique en temps de event handling...mais esque oui? J'arrive pas a 'voir'
comment je devrait ecrir la part DataBind() du parent pour attacher le data au controls child...?


Et je me suis trouver dans un colle avec le handling des properties qui vont avec ce structure:


Question C:
Dans le livre de microsoft "Developing Microsoft Asp.net Server Controls and Components" (tres tres
bien!) le demarche pour ecrire un control et ses Styles, etait un peu comme ceci:
b.1) Overload SaveViewState(){ object[] blobs = new object[2]; blobs[0] > base.SaveViewState();blobs[1] = _InnerButton.SaveViewState();} et inverser ce process dans
LoadViewState()...
b.2) Puis que j'ai beaucoup de Style objects pour chaque view (environs 5 pars vue, fait 20 Styles
object total), j'ai fait des class comme ceci:
class CSS_Month : IStateHandler {}
class CSS_Year : IStateHandler {}
qui sont ensuit sauvegarder dans viewState de Calendar.

Mais la je me demande si c'est possible de 'economiser' les gestes et faire que au lieu de garder
tout les Properties dans Calendar, et les copier a CalendarMonth/CalendarYear quands ils sont
instantier (voir a.3...) que je offre
un instance de CalendarMonth comme property de Calendar... Huh?Quoi?!? Hum: je veut dire:

class Calendar (){
public CalendarDay Day {get {return _Day;}
CalendarDay _Day = new CalendarDay();
....
}

pour que le XML serialize est:

<CC:CALENDAR View="Day">
<MONTH ShowHeader=true>
<InnerHeaderStyle.....etc.>
</MONTH>
<DAY>
<InnerHeaderStyle.....etc.>
</DAY
</CC:CALENDAR>


Plutot que:

<CC:CALENDAR View="DAY">
<CSS>
<MONTH...>
<DAY...>
</CSS>
<SETTINGS>
<MONTH...>
<DAY...
</SETTINGS>
<BEVAHIOUR>
<MONTH ShowHeader=true>
etc.
</BEHAVIOUR>
</CC:CALENDAR>

Vous voyer? Solution A est plus 'modulaire'...plus compact... (Il faut pas oublier de maitre
ExpandableObject TypeConverter sur les CalendarView et CalendarDay...pour que ils aparait dans le
PropertyPanel du IDE...)

Seul Hic -- ca marche ...presque. Bug? Le IDE se perde les pedals et quands je change un value Style
de CalendarMonth il inject le xml dans... Calendar -- et pas CalendarMonth! Je crois pas qu'il sait
quelle control est le control que ils est. Solution?



Question C: Control.Clone - ca existe ?

Avec le control decrit comme property on peut, au Calendar.OnPreRender() etre ultra simple:
this.Controls.Add(this.Month);... ben oui... ca marche!
Bien sure ca marche pas pour l'annee..
for (int i=0;i<12;i++){Controls.Add(this.Month)....}
Ya t'il quelque chose comme Clone?
for (int i=0;i<12;i++){Controls.Add(this.Month.Clone())....}




Question D: Attribute.Default Value -- et les styles...
Ce qui est bien avec DefaultValue() c'est qui ci c'est mis -- le Property n'est pas ecrit au xml si
il est egal au DefaultValue... ca marche tres biens pour les simple types (string, bool, etc..
Mais pas bien pour les Style (complex type):

[DefaultValue("")]
public Style SSS {get {if (_SSS ==null){SSS=new Style();_SSS.CssClass="MYDEFAULTCLASS";};return
_SSS;}}
private Style _SSS;

....qui mets dans le xml

<CC:MYCONTROL SSS-CONTROLSTYLE="MYDEFAULTCLASS"/>







Ouf! Je croit que j'ai reussi a mettre sur papier tout les question qui me nargait.... Je vous
remercie tous de l'avoir lu...(rester reveiller ?!) meme ci cetait vraiment long...Merci.
En esperant beaucoup de reponse
:-)







Avatar
S.Sigal
YjLaMotte:
Merci vivement de ta (tes) reponse!

Control.Clone()

oui...c'est peutetre possible, manualment -- ou peutetre plus flexiblement avec Reflection...
PropertyInfo[] = ControlA.GetType().GetProperties(...);
Mais...peutetre pas: pourait marcher...mais dangereux:

La raison est que dans certain control, l'ordre des set properties est important....
Et peutetre ya des properties qui doiv pas etre set;

Je croit que ChildControlsCreated peut pas etre set (c'est juste un example stupide) mais
si je clone ControlA a ControlB, et avec reflection, je set:

ControlB.ChildControlsCreated=true;

avant de rouler les methods, ca bloquerait EnsureChildControls() plus tard...
(C'est pas un example reel, mais ca montre que il y'aurait des circomstances ou clone avec
reflection pourait causer des degats).


Je pensait plutot a un version C# de MemCopy?
ou peutetre c'est un histoire de ISerialize/deserialize ?


UPDATE!
Je viens de trouver:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemicloneableclasstopic.asp

ca veut dire que si je

class CalendarMonth : WebControl, ICloneable{
...
}

y a des chance que ca marche...


Merci YjLaMotte :-)








"YJLAMOTTE" wrote in message
news:
Je crois que Control.Clone n'existe pas.. en tout cas j'ai pas trouvé dans
MSDN.
IL ya Control.Create mais c pour les winforms et ca n'a pas l'air d'avoir un
rapport avec ce que tu veux faire

IL va falloir que tu fasses une petite fonction du style

private Control CloneControl(Control MonControle)
{
Control ReturnControl = new Control();
ReturnControl.Propriété1 = MonControle..Propriété1;
etc etc

return ReturnControl
}

Pour la suite, ce sera un prochain post.

YJLAMOTTE

"S.Sigal" wrote:

>
> Bonjour:
> (Et excuser mon francais ecrit terrible...)
>
> Je cherche des reponse/verification au questions suivants sur le 'principe' de design de
> CompositeControls complex...
>
> Question A:
> a) Comment faire des Components qui change de 'form'? Si vous avez un control qui contient un
> SELECT, qui montre un enum [Semains, Mois, Annee], et son SelectIndexChanged determine quelle


vue
> montrer, la question est comment faire pour montrer cette vue intelligament. Les choix que je


vois
> sont :
> a.1) Dans Render(), je change de layout (table 2 columns, 7 columns, ou 6, etc.). Le problem


avec
> cette methodology est que Render est apres OnLoad -- alors tout EventHandler attacher au cellule
> sont trop tard. Tout ce que
> j'ai reussi a faire etait de mettre du JS sur le Table.onclick...et passer ceci au server dans


un
> hidden field. Pas tres costaud...
> a.2) Solutions vue dans un blog: faire dans OnLoad le layout de grid -- mais vide -- et racorder


les
> EventHandler la. Ensuite, plus tard dans Render, mettre les numero dans les casse... Ce method
> marcherait pour peutetre un control de mois -- mais je vois mal faire tout ce travaille pour
> jour/semaine/mois, etc...pour mettre a la poubelle 75%....
> a.3) Faire les controls pour le Mois, Annee, etc. des autre control. (CalendarYear,


CalendarMois,
> etc.) qui sont ajouter a Calendar.Controls[] dans Calendar.PreRender() -- ce ci a l'avantage du


fait
> que meme si Calendar a deja passer OnLoad et est deja a OnPreRender/OnLoad -- les sousControls
> (calendarMois) va vite se ratrepper...et passer a travers OnInit, OnLoad, [LesEventsHandlers!],


et
> finalement arriver a PreRender aussi.
> Du EventHandler du souscontrol je appelle manualement le EventHandler dans Calendar -- (trop


tard
> pour BubbleEvent ou autre solution). Cette solution, a laire beucoup plus flexible...sauf un


des
> bouton. Sur le CalendarMonth, chaque row a un ShowWeek button -- qui devrait causer un


changement de
> vue. Mais si le parent control est deja a Render() -- le event est trop tard -- pas de chance a
> changer de vue et sauvegarder dans ViewState. Alors on bouge le LoadSubViewControl() a


PreRender
> plutot que Render()....
> a.4) et c'est possible que il ya d'autre que je ne connais pas encore?
>
> Question B:
> Vous me dite que 'ben alors...le problem est regler, non?'....pas si vite :-) J'ai tellement


galerer
> les derniers semaines en train de comprendres ces choix -- que j'aimerai -- si possible -- un


peu de
> verification que la logique est bonne/fiable...bref, le meilleur... Solution a.3 ma l'aire plus
> modulaire est plus logique en temps de event handling...mais esque oui? J'arrive pas a 'voir'
> comment je devrait ecrir la part DataBind() du parent pour attacher le data au controls


child...?
>
>
> Et je me suis trouver dans un colle avec le handling des properties qui vont avec ce structure:
>
>
> Question C:
> Dans le livre de microsoft "Developing Microsoft Asp.net Server Controls and Components" (tres


tres
> bien!) le demarche pour ecrire un control et ses Styles, etait un peu comme ceci:
> b.1) Overload SaveViewState(){ object[] blobs = new object[2]; blobs[0] > > base.SaveViewState();blobs[1] = _InnerButton.SaveViewState();} et inverser ce process dans
> LoadViewState()...
> b.2) Puis que j'ai beaucoup de Style objects pour chaque view (environs 5 pars vue, fait 20


Styles
> object total), j'ai fait des class comme ceci:
> class CSS_Month : IStateHandler {}
> class CSS_Year : IStateHandler {}
> qui sont ensuit sauvegarder dans viewState de Calendar.
>
> Mais la je me demande si c'est possible de 'economiser' les gestes et faire que au lieu de


garder
> tout les Properties dans Calendar, et les copier a CalendarMonth/CalendarYear quands ils sont
> instantier (voir a.3...) que je offre
> un instance de CalendarMonth comme property de Calendar... Huh?Quoi?!? Hum: je veut dire:
>
> class Calendar (){
> public CalendarDay Day {get {return _Day;}
> CalendarDay _Day = new CalendarDay();
> ....
> }
>
> pour que le XML serialize est:
>
> <CC:CALENDAR View="Day">
> <MONTH ShowHeader=true>
> <InnerHeaderStyle.....etc.>
> </MONTH>
> <DAY>
> <InnerHeaderStyle.....etc.>
> </DAY
> </CC:CALENDAR>
>
>
> Plutot que:
>
> <CC:CALENDAR View="DAY">
> <CSS>
> <MONTH...>
> <DAY...>
> </CSS>
> <SETTINGS>
> <MONTH...>
> <DAY...
> </SETTINGS>
> <BEVAHIOUR>
> <MONTH ShowHeader=true>
> etc.
> </BEHAVIOUR>
> </CC:CALENDAR>
>
> Vous voyer? Solution A est plus 'modulaire'...plus compact... (Il faut pas oublier de maitre
> ExpandableObject TypeConverter sur les CalendarView et CalendarDay...pour que ils aparait dans


le
> PropertyPanel du IDE...)
>
> Seul Hic -- ca marche ...presque. Bug? Le IDE se perde les pedals et quands je change un value


Style
> de CalendarMonth il inject le xml dans... Calendar -- et pas CalendarMonth! Je crois pas qu'il


sait
> quelle control est le control que ils est. Solution?
>
>
>
> Question C: Control.Clone - ca existe ?
>
> Avec le control decrit comme property on peut, au Calendar.OnPreRender() etre ultra simple:
> this.Controls.Add(this.Month);... ben oui... ca marche!
> Bien sure ca marche pas pour l'annee..
> for (int i=0;i<12;i++){Controls.Add(this.Month)....}
> Ya t'il quelque chose comme Clone?
> for (int i=0;i<12;i++){Controls.Add(this.Month.Clone())....}
>
>
>
>
> Question D: Attribute.Default Value -- et les styles...
> Ce qui est bien avec DefaultValue() c'est qui ci c'est mis -- le Property n'est pas ecrit au xml


si
> il est egal au DefaultValue... ca marche tres biens pour les simple types (string, bool, etc..
> Mais pas bien pour les Style (complex type):
>
> [DefaultValue("")]
> public Style SSS {get {if (_SSS ==null){SSS=new Style();_SSS.CssClass="MYDEFAULTCLASS";};return
> _SSS;}}
> private Style _SSS;
>
> ....qui mets dans le xml
>
> <CC:MYCONTROL SSS-CONTROLSTYLE="MYDEFAULTCLASS"/>
>
>
>
>
>
>
>
> Ouf! Je croit que j'ai reussi a mettre sur papier tout les question qui me nargait.... Je vous
> remercie tous de l'avoir lu...(rester reveiller ?!) meme ci cetait vraiment long...Merci.
> En esperant beaucoup de reponse
> :-)
>
>
>
>
>


Avatar
S.Sigal
J'ai parlait trop vite :-(

IClone est juste un interface... pas un method. Ils reste bein sure Quoi mettre entre
les acolades....

Le text qui ma rendu compte que j'ai crier eureka trop vite etait:

http://dotnetjunkies.com/Tutorial/67707D90-C7B4-4316-AF9A-62C89E9E6839.dcik
"The .NET Framework provides the IClone interface so that you can implement your own Clone() method
in your class. However, since IClone is just an interface it is up to you to make sure that you are
copying the properties/methods etc to the new object correctly. This can present a problem when
testing your code as you need a way to programmatically check that it has all the same properties
and methods, both public or private, that you would expect. In order to make sure of this you need
to be able to compare the old and new objects and the System.Refelction namespace enables you to do
just this. "


Alors on revients a Reflection/etc.... que je reste convaincu etre dangereux sans prendre en compte
le sequence des OnInit, OnLoad, etc....

Bon...je continurait de mijote sur Question C. ...
en attendant tes opinions pour Question A & B
:-)




"S.Sigal" wrote in message
news:
YjLaMotte:
Merci vivement de ta (tes) reponse!

Control.Clone()

oui...c'est peutetre possible, manualment -- ou peutetre plus flexiblement avec Reflection...
PropertyInfo[] = ControlA.GetType().GetProperties(...);
Mais...peutetre pas: pourait marcher...mais dangereux:

La raison est que dans certain control, l'ordre des set properties est important....
Et peutetre ya des properties qui doiv pas etre set;

Je croit que ChildControlsCreated peut pas etre set (c'est juste un example stupide) mais
si je clone ControlA a ControlB, et avec reflection, je set:

ControlB.ChildControlsCreated=true;

avant de rouler les methods, ca bloquerait EnsureChildControls() plus tard...
(C'est pas un example reel, mais ca montre que il y'aurait des circomstances ou clone avec
reflection pourait causer des degats).


Je pensait plutot a un version C# de MemCopy?
ou peutetre c'est un histoire de ISerialize/deserialize ?


UPDATE!
Je viens de trouver:



http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemicloneableclasstopic.asp

ca veut dire que si je

class CalendarMonth : WebControl, ICloneable{
...
}

y a des chance que ca marche...


Merci YjLaMotte :-)








"YJLAMOTTE" wrote in message
news:
> Je crois que Control.Clone n'existe pas.. en tout cas j'ai pas trouvé dans
> MSDN.
> IL ya Control.Create mais c pour les winforms et ca n'a pas l'air d'avoir un
> rapport avec ce que tu veux faire
>
> IL va falloir que tu fasses une petite fonction du style
>
> private Control CloneControl(Control MonControle)
> {
> Control ReturnControl = new Control();
> ReturnControl.Propriété1 = MonControle..Propriété1;
> etc etc
>
> return ReturnControl
> }
>
> Pour la suite, ce sera un prochain post.
>
> YJLAMOTTE
>
> "S.Sigal" wrote:
>
> >
> > Bonjour:
> > (Et excuser mon francais ecrit terrible...)
> >
> > Je cherche des reponse/verification au questions suivants sur le 'principe' de design de
> > CompositeControls complex...
> >
> > Question A:
> > a) Comment faire des Components qui change de 'form'? Si vous avez un control qui contient un
> > SELECT, qui montre un enum [Semains, Mois, Annee], et son SelectIndexChanged determine quelle
vue
> > montrer, la question est comment faire pour montrer cette vue intelligament. Les choix que je
vois
> > sont :
> > a.1) Dans Render(), je change de layout (table 2 columns, 7 columns, ou 6, etc.). Le problem
avec
> > cette methodology est que Render est apres OnLoad -- alors tout EventHandler attacher au


cellule
> > sont trop tard. Tout ce que
> > j'ai reussi a faire etait de mettre du JS sur le Table.onclick...et passer ceci au server dans
un
> > hidden field. Pas tres costaud...
> > a.2) Solutions vue dans un blog: faire dans OnLoad le layout de grid -- mais vide -- et


racorder
les
> > EventHandler la. Ensuite, plus tard dans Render, mettre les numero dans les casse... Ce


method
> > marcherait pour peutetre un control de mois -- mais je vois mal faire tout ce travaille pour
> > jour/semaine/mois, etc...pour mettre a la poubelle 75%....
> > a.3) Faire les controls pour le Mois, Annee, etc. des autre control. (CalendarYear,
CalendarMois,
> > etc.) qui sont ajouter a Calendar.Controls[] dans Calendar.PreRender() -- ce ci a l'avantage


du
fait
> > que meme si Calendar a deja passer OnLoad et est deja a OnPreRender/OnLoad -- les sousControls
> > (calendarMois) va vite se ratrepper...et passer a travers OnInit, OnLoad,


[LesEventsHandlers!],
et
> > finalement arriver a PreRender aussi.
> > Du EventHandler du souscontrol je appelle manualement le EventHandler dans Calendar -- (trop
tard
> > pour BubbleEvent ou autre solution). Cette solution, a laire beucoup plus flexible...sauf un
des
> > bouton. Sur le CalendarMonth, chaque row a un ShowWeek button -- qui devrait causer un
changement de
> > vue. Mais si le parent control est deja a Render() -- le event est trop tard -- pas de chance


a
> > changer de vue et sauvegarder dans ViewState. Alors on bouge le LoadSubViewControl() a
PreRender
> > plutot que Render()....
> > a.4) et c'est possible que il ya d'autre que je ne connais pas encore?
> >
> > Question B:
> > Vous me dite que 'ben alors...le problem est regler, non?'....pas si vite :-) J'ai tellement
galerer
> > les derniers semaines en train de comprendres ces choix -- que j'aimerai -- si possible -- un
peu de
> > verification que la logique est bonne/fiable...bref, le meilleur... Solution a.3 ma l'aire


plus
> > modulaire est plus logique en temps de event handling...mais esque oui? J'arrive pas a 'voir'
> > comment je devrait ecrir la part DataBind() du parent pour attacher le data au controls
child...?
> >
> >
> > Et je me suis trouver dans un colle avec le handling des properties qui vont avec ce


structure:
> >
> >
> > Question C:
> > Dans le livre de microsoft "Developing Microsoft Asp.net Server Controls and Components" (tres
tres
> > bien!) le demarche pour ecrire un control et ses Styles, etait un peu comme ceci:
> > b.1) Overload SaveViewState(){ object[] blobs = new object[2]; blobs[0] > > > base.SaveViewState();blobs[1] = _InnerButton.SaveViewState();} et inverser ce process dans
> > LoadViewState()...
> > b.2) Puis que j'ai beaucoup de Style objects pour chaque view (environs 5 pars vue, fait 20
Styles
> > object total), j'ai fait des class comme ceci:
> > class CSS_Month : IStateHandler {}
> > class CSS_Year : IStateHandler {}
> > qui sont ensuit sauvegarder dans viewState de Calendar.
> >
> > Mais la je me demande si c'est possible de 'economiser' les gestes et faire que au lieu de
garder
> > tout les Properties dans Calendar, et les copier a CalendarMonth/CalendarYear quands ils sont
> > instantier (voir a.3...) que je offre
> > un instance de CalendarMonth comme property de Calendar... Huh?Quoi?!? Hum: je veut dire:
> >
> > class Calendar (){
> > public CalendarDay Day {get {return _Day;}
> > CalendarDay _Day = new CalendarDay();
> > ....
> > }
> >
> > pour que le XML serialize est:
> >
> > <CC:CALENDAR View="Day">
> > <MONTH ShowHeader=true>
> > <InnerHeaderStyle.....etc.>
> > </MONTH>
> > <DAY>
> > <InnerHeaderStyle.....etc.>
> > </DAY
> > </CC:CALENDAR>
> >
> >
> > Plutot que:
> >
> > <CC:CALENDAR View="DAY">
> > <CSS>
> > <MONTH...>
> > <DAY...>
> > </CSS>
> > <SETTINGS>
> > <MONTH...>
> > <DAY...
> > </SETTINGS>
> > <BEVAHIOUR>
> > <MONTH ShowHeader=true>
> > etc.
> > </BEHAVIOUR>
> > </CC:CALENDAR>
> >
> > Vous voyer? Solution A est plus 'modulaire'...plus compact... (Il faut pas oublier de maitre
> > ExpandableObject TypeConverter sur les CalendarView et CalendarDay...pour que ils aparait dans
le
> > PropertyPanel du IDE...)
> >
> > Seul Hic -- ca marche ...presque. Bug? Le IDE se perde les pedals et quands je change un value
Style
> > de CalendarMonth il inject le xml dans... Calendar -- et pas CalendarMonth! Je crois pas qu'il
sait
> > quelle control est le control que ils est. Solution?
> >
> >
> >
> > Question C: Control.Clone - ca existe ?
> >
> > Avec le control decrit comme property on peut, au Calendar.OnPreRender() etre ultra simple:
> > this.Controls.Add(this.Month);... ben oui... ca marche!
> > Bien sure ca marche pas pour l'annee..
> > for (int i=0;i<12;i++){Controls.Add(this.Month)....}
> > Ya t'il quelque chose comme Clone?
> > for (int i=0;i<12;i++){Controls.Add(this.Month.Clone())....}
> >
> >
> >
> >
> > Question D: Attribute.Default Value -- et les styles...
> > Ce qui est bien avec DefaultValue() c'est qui ci c'est mis -- le Property n'est pas ecrit au


xml
si
> > il est egal au DefaultValue... ca marche tres biens pour les simple types (string, bool, etc..
> > Mais pas bien pour les Style (complex type):
> >
> > [DefaultValue("")]
> > public Style SSS {get {if (_SSS ==null){SSS=new


Style();_SSS.CssClass="MYDEFAULTCLASS";};return
> > _SSS;}}
> > private Style _SSS;
> >
> > ....qui mets dans le xml
> >
> > <CC:MYCONTROL SSS-CONTROLSTYLE="MYDEFAULTCLASS"/>
> >
> >
> >
> >
> >
> >
> >
> > Ouf! Je croit que j'ai reussi a mettre sur papier tout les question qui me nargait.... Je vous
> > remercie tous de l'avoir lu...(rester reveiller ?!) meme ci cetait vraiment long...Merci.
> > En esperant beaucoup de reponse
> > :-)
> >
> >
> >
> >
> >




Avatar
S.Sigal
Pour les interesse seulment...
trouver ce code de Cloning via Reflection
a http://www.codeproject.com/csharp/cloneimpl_class.asp

Cette tout...



/// <summary>
/// Clone the object, and returning a reference to a cloned object.
/// </summary>
/// <returns>Reference to the new cloned
/// object.</returns>
public object Clone()
{
//First we create an instance of this specific type.
object newObject = Activator.CreateInstance( this.GetType() );

//We get the array of fields for the new type instance.
FieldInfo[] fields = newObject.GetType().GetFields();

int i = 0;

foreach( FieldInfo fi in this.GetType().GetFields() )
{
//We query if the fiels support the ICloneable interface.
Type ICloneType = fi.FieldType.
GetInterface( "ICloneable" , true );

if( ICloneType != null )
{
//Getting the ICloneable interface from the object.
ICloneable IClone = (ICloneable)fi.GetValue(this);

//We use the clone method to set the new value to the field.
fields[i].SetValue( newObject , IClone.Clone() );
}
else
{
// If the field doesn't support the ICloneable
// interface then just set it.
fields[i].SetValue( newObject , fi.GetValue(this) );
}

//Now we check if the object support the
//IEnumerable interface, so if it does
//we need to enumerate all its items and check if
//they support the ICloneable interface.
Type IEnumerableType = fi.FieldType.GetInterface
( "IEnumerable" , true );
if( IEnumerableType != null )
{
//Get the IEnumerable interface from the field.
IEnumerable IEnum = (IEnumerable)fi.GetValue(this);

//This version support the IList and the
//IDictionary interfaces to iterate on collections.
Type IListType = fields[i].FieldType.GetInterface
( "IList" , true );
Type IDicType = fields[i].FieldType.GetInterface
( "IDictionary" , true );

int j = 0;
if( IListType != null )
{
//Getting the IList interface.
IList list = (IList)fields[i].GetValue(newObject);

foreach( object obj in IEnum )
{
//Checking to see if the current item
//support the ICloneable interface.
ICloneType = obj.GetType().
GetInterface( "ICloneable" , true );

if( ICloneType != null )
{
//If it does support the ICloneable interface,
//we use it to set the clone of
//the object in the list.
ICloneable clone = (ICloneable)obj;

list[j] = clone.Clone();
}

//NOTE: If the item in the list is not
//support the ICloneable interface then in the
//cloned list this item will be the same
//item as in the original list
//(as long as this type is a reference type).

j++;
}
}
else if( IDicType != null )
{
//Getting the dictionary interface.
IDictionary dic = (IDictionary)fields[i].
GetValue(newObject);
j = 0;

foreach( DictionaryEntry de in IEnum )
{
//Checking to see if the item
//support the ICloneable interface.
ICloneType = de.Value.GetType().
GetInterface( "ICloneable" , true );

if( ICloneType != null )
{
ICloneable clone = (ICloneable)de.Value;

dic[de.Key] = clone.Clone();
}
j++;
}
}
}
i++;
}
return newObject;
}



"S.Sigal" wrote in message
news:OE$
J'ai parlait trop vite :-(

IClone est juste un interface... pas un method. Ils reste bein sure Quoi mettre entre
les acolades....

Le text qui ma rendu compte que j'ai crier eureka trop vite etait:

http://dotnetjunkies.com/Tutorial/67707D90-C7B4-4316-AF9A-62C89E9E6839.dcik
"The .NET Framework provides the IClone interface so that you can implement your own Clone()


method
in your class. However, since IClone is just an interface it is up to you to make sure that you


are
copying the properties/methods etc to the new object correctly. This can present a problem when
testing your code as you need a way to programmatically check that it has all the same properties
and methods, both public or private, that you would expect. In order to make sure of this you need
to be able to compare the old and new objects and the System.Refelction namespace enables you to


do
just this. "


Alors on revients a Reflection/etc.... que je reste convaincu etre dangereux sans prendre en


compte
le sequence des OnInit, OnLoad, etc....

Bon...je continurait de mijote sur Question C. ...
en attendant tes opinions pour Question A & B
:-)




"S.Sigal" wrote in message
news:
> YjLaMotte:
> Merci vivement de ta (tes) reponse!
>
> Control.Clone()
>
> oui...c'est peutetre possible, manualment -- ou peutetre plus flexiblement avec Reflection...
> PropertyInfo[] = ControlA.GetType().GetProperties(...);
> Mais...peutetre pas: pourait marcher...mais dangereux:
>
> La raison est que dans certain control, l'ordre des set properties est important....
> Et peutetre ya des properties qui doiv pas etre set;
>
> Je croit que ChildControlsCreated peut pas etre set (c'est juste un example stupide) mais
> si je clone ControlA a ControlB, et avec reflection, je set:
>
> ControlB.ChildControlsCreated=true;
>
> avant de rouler les methods, ca bloquerait EnsureChildControls() plus tard...
> (C'est pas un example reel, mais ca montre que il y'aurait des circomstances ou clone avec
> reflection pourait causer des degats).
>
>
> Je pensait plutot a un version C# de MemCopy?
> ou peutetre c'est un histoire de ISerialize/deserialize ?
>
>
> UPDATE!
> Je viens de trouver:
>



http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemicloneableclasstopic.asp
>
> ca veut dire que si je
>
> class CalendarMonth : WebControl, ICloneable{
> ...
> }
>
> y a des chance que ca marche...
>
>
> Merci YjLaMotte :-)
>
>
>
>
>
>
>
>
> "YJLAMOTTE" wrote in message
> news:
> > Je crois que Control.Clone n'existe pas.. en tout cas j'ai pas trouvé dans
> > MSDN.
> > IL ya Control.Create mais c pour les winforms et ca n'a pas l'air d'avoir un
> > rapport avec ce que tu veux faire
> >
> > IL va falloir que tu fasses une petite fonction du style
> >
> > private Control CloneControl(Control MonControle)
> > {
> > Control ReturnControl = new Control();
> > ReturnControl.Propriété1 = MonControle..Propriété1;
> > etc etc
> >
> > return ReturnControl
> > }
> >
> > Pour la suite, ce sera un prochain post.
> >
> > YJLAMOTTE
> >
> > "S.Sigal" wrote:
> >
> > >
> > > Bonjour:
> > > (Et excuser mon francais ecrit terrible...)
> > >
> > > Je cherche des reponse/verification au questions suivants sur le 'principe' de design de
> > > CompositeControls complex...
> > >
> > > Question A:
> > > a) Comment faire des Components qui change de 'form'? Si vous avez un control qui contient


un
> > > SELECT, qui montre un enum [Semains, Mois, Annee], et son SelectIndexChanged determine


quelle
> vue
> > > montrer, la question est comment faire pour montrer cette vue intelligament. Les choix que


je
> vois
> > > sont :
> > > a.1) Dans Render(), je change de layout (table 2 columns, 7 columns, ou 6, etc.). Le problem
> avec
> > > cette methodology est que Render est apres OnLoad -- alors tout EventHandler attacher au
cellule
> > > sont trop tard. Tout ce que
> > > j'ai reussi a faire etait de mettre du JS sur le Table.onclick...et passer ceci au server


dans
> un
> > > hidden field. Pas tres costaud...
> > > a.2) Solutions vue dans un blog: faire dans OnLoad le layout de grid -- mais vide -- et
racorder
> les
> > > EventHandler la. Ensuite, plus tard dans Render, mettre les numero dans les casse... Ce
method
> > > marcherait pour peutetre un control de mois -- mais je vois mal faire tout ce travaille pour
> > > jour/semaine/mois, etc...pour mettre a la poubelle 75%....
> > > a.3) Faire les controls pour le Mois, Annee, etc. des autre control. (CalendarYear,
> CalendarMois,
> > > etc.) qui sont ajouter a Calendar.Controls[] dans Calendar.PreRender() -- ce ci a l'avantage
du
> fait
> > > que meme si Calendar a deja passer OnLoad et est deja a OnPreRender/OnLoad -- les


sousControls
> > > (calendarMois) va vite se ratrepper...et passer a travers OnInit, OnLoad,
[LesEventsHandlers!],
> et
> > > finalement arriver a PreRender aussi.
> > > Du EventHandler du souscontrol je appelle manualement le EventHandler dans Calendar -- (trop
> tard
> > > pour BubbleEvent ou autre solution). Cette solution, a laire beucoup plus flexible...sauf


un
> des
> > > bouton. Sur le CalendarMonth, chaque row a un ShowWeek button -- qui devrait causer un
> changement de
> > > vue. Mais si le parent control est deja a Render() -- le event est trop tard -- pas de


chance
a
> > > changer de vue et sauvegarder dans ViewState. Alors on bouge le LoadSubViewControl() a
> PreRender
> > > plutot que Render()....
> > > a.4) et c'est possible que il ya d'autre que je ne connais pas encore?
> > >
> > > Question B:
> > > Vous me dite que 'ben alors...le problem est regler, non?'....pas si vite :-) J'ai tellement
> galerer
> > > les derniers semaines en train de comprendres ces choix -- que j'aimerai -- si possible --


un
> peu de
> > > verification que la logique est bonne/fiable...bref, le meilleur... Solution a.3 ma l'aire
plus
> > > modulaire est plus logique en temps de event handling...mais esque oui? J'arrive pas a


'voir'
> > > comment je devrait ecrir la part DataBind() du parent pour attacher le data au controls
> child...?
> > >
> > >
> > > Et je me suis trouver dans un colle avec le handling des properties qui vont avec ce
structure:
> > >
> > >
> > > Question C:
> > > Dans le livre de microsoft "Developing Microsoft Asp.net Server Controls and Components"


(tres
> tres
> > > bien!) le demarche pour ecrire un control et ses Styles, etait un peu comme ceci:
> > > b.1) Overload SaveViewState(){ object[] blobs = new object[2]; blobs[0] > > > > base.SaveViewState();blobs[1] = _InnerButton.SaveViewState();} et inverser ce process dans
> > > LoadViewState()...
> > > b.2) Puis que j'ai beaucoup de Style objects pour chaque view (environs 5 pars vue, fait 20
> Styles
> > > object total), j'ai fait des class comme ceci:
> > > class CSS_Month : IStateHandler {}
> > > class CSS_Year : IStateHandler {}
> > > qui sont ensuit sauvegarder dans viewState de Calendar.
> > >
> > > Mais la je me demande si c'est possible de 'economiser' les gestes et faire que au lieu de
> garder
> > > tout les Properties dans Calendar, et les copier a CalendarMonth/CalendarYear quands ils


sont
> > > instantier (voir a.3...) que je offre
> > > un instance de CalendarMonth comme property de Calendar... Huh?Quoi?!? Hum: je veut dire:
> > >
> > > class Calendar (){
> > > public CalendarDay Day {get {return _Day;}
> > > CalendarDay _Day = new CalendarDay();
> > > ....
> > > }
> > >
> > > pour que le XML serialize est:
> > >
> > > <CC:CALENDAR View="Day">
> > > <MONTH ShowHeader=true>
> > > <InnerHeaderStyle.....etc.>
> > > </MONTH>
> > > <DAY>
> > > <InnerHeaderStyle.....etc.>
> > > </DAY
> > > </CC:CALENDAR>
> > >
> > >
> > > Plutot que:
> > >
> > > <CC:CALENDAR View="DAY">
> > > <CSS>
> > > <MONTH...>
> > > <DAY...>
> > > </CSS>
> > > <SETTINGS>
> > > <MONTH...>
> > > <DAY...
> > > </SETTINGS>
> > > <BEVAHIOUR>
> > > <MONTH ShowHeader=true>
> > > etc.
> > > </BEHAVIOUR>
> > > </CC:CALENDAR>
> > >
> > > Vous voyer? Solution A est plus 'modulaire'...plus compact... (Il faut pas oublier de maitre
> > > ExpandableObject TypeConverter sur les CalendarView et CalendarDay...pour que ils aparait


dans
> le
> > > PropertyPanel du IDE...)
> > >
> > > Seul Hic -- ca marche ...presque. Bug? Le IDE se perde les pedals et quands je change un


value
> Style
> > > de CalendarMonth il inject le xml dans... Calendar -- et pas CalendarMonth! Je crois pas


qu'il
> sait
> > > quelle control est le control que ils est. Solution?
> > >
> > >
> > >
> > > Question C: Control.Clone - ca existe ?
> > >
> > > Avec le control decrit comme property on peut, au Calendar.OnPreRender() etre ultra simple:
> > > this.Controls.Add(this.Month);... ben oui... ca marche!
> > > Bien sure ca marche pas pour l'annee..
> > > for (int i=0;i<12;i++){Controls.Add(this.Month)....}
> > > Ya t'il quelque chose comme Clone?
> > > for (int i=0;i<12;i++){Controls.Add(this.Month.Clone())....}
> > >
> > >
> > >
> > >
> > > Question D: Attribute.Default Value -- et les styles...
> > > Ce qui est bien avec DefaultValue() c'est qui ci c'est mis -- le Property n'est pas ecrit au
xml
> si
> > > il est egal au DefaultValue... ca marche tres biens pour les simple types (string, bool,


etc..
> > > Mais pas bien pour les Style (complex type):
> > >
> > > [DefaultValue("")]
> > > public Style SSS {get {if (_SSS ==null){SSS=new
Style();_SSS.CssClass="MYDEFAULTCLASS";};return
> > > _SSS;}}
> > > private Style _SSS;
> > >
> > > ....qui mets dans le xml
> > >
> > > <CC:MYCONTROL SSS-CONTROLSTYLE="MYDEFAULTCLASS"/>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Ouf! Je croit que j'ai reussi a mettre sur papier tout les question qui me nargait.... Je


vous
> > > remercie tous de l'avoir lu...(rester reveiller ?!) meme ci cetait vraiment long...Merci.
> > > En esperant beaucoup de reponse
> > > :-)
> > >
> > >
> > >
> > >
> > >
>
>




Avatar
S.Sigal
YlaMotte -- ah...Suit vraiment navre de mon francais ... terrible :-) Et mes ideas ...complique :-)

Non-- t'en fait pas -- je cherche pas a faire ceci avec du JScript ClientSide.
Je cherche biens a faire ceci ServerSide,

Voyons:


class Calendar : WebControl{
enum eView {Day,Week,Month,Year,}

protected DropDownList VIEWSELECTOR;
protected WebControl SUBCONTROL;

DateTime View {get {object o = ViewState["View"];return (o==null)?eView.Month:(eView)o;}set
{ViewState["View"] = value;}}
DateTime Date {get {object o = ViewState["Date"];return
(o==null)?DateTime.Today:(DateTime)o;}set {ViewState["Date"] = value;}}


public override CreateChildControls(){
VIEWSELECTOR = new DropDownList();
this.Controls.Add(VIEWSELECTOR);
VIEWSELECTOR.SelectedIndexChanged += new EventHandler (CHANGE_VIEW);
}


override protected void OnPreRender(EventArgs e){
if (View == eView.Day){SUBCONTROL = new CalendarWeek(this, Date);}
if (View == eView.Month){SUBCONTROL = new CalendarMonth(this,Date);}
etc...
}

public void CHANGE_VIEW(object Sender, EventArgs e){
Date = (ViewInfo)e.NewDate;
View = (ViewInfo)e.View;
}


}


class CalendarMonth : WebControl{
public void CalendarMonth(Calendar qParent, DateTime qDate){
_Parent =qParent;
this.Date = qDate;
}

private Calendar _Parent = null;
public DateTime Date {get {return _Date;}set {_Date = value;}}
private DateTime _Date = System.DateTime.Today;

protected void OnLoad(){
TABLE = new Table();
for (int r=0;r<6;t++){
TableRow oRow = new TableRow();
TABLE.Rows.Add(oRow);
for (int c=0;c<7;c++){
TableCell oCell = new TableCell();
if (c==0){
Button oButton = new Button();
oCell.Controls.Add(oButton);
oButton.Click += new EventHandler(WEEK_CLICKED);
}
oRow.Controls.Add(oCell);
}
protected void WEEK_CLICKED (object Sender, EventArgs e){
ViewInfo e2 = new ViewInfo(..., eView.Week);
_Parent.ChangeView(this,e2);
}

}


class CalendarDay : WebControl{
etc.
}

class CalendarYear : WebControl{
}

OOOOOFFFF... Je croit qu'il ya assez pour montre ou je pensait aller... (aucun de ce code a etait
mis dans le IDE alors c'est tout du hypothese que ca peut marcher comme ca...)



"YJLAMOTTE" wrote in message
news:
Et on continue..

Bon si j'ai bien compris , c'est pas facile.. de te suivre ;) , tu veux
qu'au changement de la valeur d'une dropdownlist (ddl) l'affichage de ton
resultat change dynamiquement.

Si tu as une seule ddl : pourquoi ne pas utiliser l'autopostback et
rafraichir ton control qui affiche le resultat ? (un Datagrid je presume)

Si tu en as plusieurs : est ce que c'est choquant (d'un point de vue
ergonomie) d'attendre d'avoir tout choisis et de cliquer sur un bouton ?

Les utilisateurs aime les trucs qui clignote, qui font papa/maman et le café
mais il faut savoir rester simple, avoir quelque chose sans bug ou presque
plutot qu'une interface super classe qui plante au premier click (c'est mon
avis certes.) . Apres si on peut avoir les deux ca ne gache rien.. mais
appliquons la méthode KISS : Keep it stupid and simple :)




"S.Sigal" wrote:

>
> Bonjour:
> (Et excuser mon francais ecrit terrible...)
>
> Je cherche des reponse/verification au questions suivants sur le 'principe' de design de
> CompositeControls complex...
>
> Question A:
> a) Comment faire des Components qui change de 'form'? Si vous avez un control qui contient un
> SELECT, qui montre un enum [Semains, Mois, Annee], et son SelectIndexChanged determine quelle


vue
> montrer, la question est comment faire pour montrer cette vue intelligament. Les choix que je


vois
> sont :
> a.1) Dans Render(), je change de layout (table 2 columns, 7 columns, ou 6, etc.). Le problem


avec
> cette methodology est que Render est apres OnLoad -- alors tout EventHandler attacher au cellule
> sont trop tard. Tout ce que
> j'ai reussi a faire etait de mettre du JS sur le Table.onclick...et passer ceci au server dans


un
> hidden field. Pas tres costaud...
> a.2) Solutions vue dans un blog: faire dans OnLoad le layout de grid -- mais vide -- et racorder


les
> EventHandler la. Ensuite, plus tard dans Render, mettre les numero dans les casse... Ce method
> marcherait pour peutetre un control de mois -- mais je vois mal faire tout ce travaille pour
> jour/semaine/mois, etc...pour mettre a la poubelle 75%....
> a.3) Faire les controls pour le Mois, Annee, etc. des autre control. (CalendarYear,


CalendarMois,
> etc.) qui sont ajouter a Calendar.Controls[] dans Calendar.PreRender() -- ce ci a l'avantage du


fait
> que meme si Calendar a deja passer OnLoad et est deja a OnPreRender/OnLoad -- les sousControls
> (calendarMois) va vite se ratrepper...et passer a travers OnInit, OnLoad, [LesEventsHandlers!],


et
> finalement arriver a PreRender aussi.
> Du EventHandler du souscontrol je appelle manualement le EventHandler dans Calendar -- (trop


tard
> pour BubbleEvent ou autre solution). Cette solution, a laire beucoup plus flexible...sauf un


des
> bouton. Sur le CalendarMonth, chaque row a un ShowWeek button -- qui devrait causer un


changement de
> vue. Mais si le parent control est deja a Render() -- le event est trop tard -- pas de chance a
> changer de vue et sauvegarder dans ViewState. Alors on bouge le LoadSubViewControl() a


PreRender
> plutot que Render()....
> a.4) et c'est possible que il ya d'autre que je ne connais pas encore?
>
> Question B:
> Vous me dite que 'ben alors...le problem est regler, non?'....pas si vite :-) J'ai tellement


galerer
> les derniers semaines en train de comprendres ces choix -- que j'aimerai -- si possible -- un


peu de
> verification que la logique est bonne/fiable...bref, le meilleur... Solution a.3 ma l'aire plus
> modulaire est plus logique en temps de event handling...mais esque oui? J'arrive pas a 'voir'
> comment je devrait ecrir la part DataBind() du parent pour attacher le data au controls


child...?
>
>
> Et je me suis trouver dans un colle avec le handling des properties qui vont avec ce structure:
>
>
> Question C:
> Dans le livre de microsoft "Developing Microsoft Asp.net Server Controls and Components" (tres


tres
> bien!) le demarche pour ecrire un control et ses Styles, etait un peu comme ceci:
> b.1) Overload SaveViewState(){ object[] blobs = new object[2]; blobs[0] > > base.SaveViewState();blobs[1] = _InnerButton.SaveViewState();} et inverser ce process dans
> LoadViewState()...
> b.2) Puis que j'ai beaucoup de Style objects pour chaque view (environs 5 pars vue, fait 20


Styles
> object total), j'ai fait des class comme ceci:
> class CSS_Month : IStateHandler {}
> class CSS_Year : IStateHandler {}
> qui sont ensuit sauvegarder dans viewState de Calendar.
>
> Mais la je me demande si c'est possible de 'economiser' les gestes et faire que au lieu de


garder
> tout les Properties dans Calendar, et les copier a CalendarMonth/CalendarYear quands ils sont
> instantier (voir a.3...) que je offre
> un instance de CalendarMonth comme property de Calendar... Huh?Quoi?!? Hum: je veut dire:
>
> class Calendar (){
> public CalendarDay Day {get {return _Day;}
> CalendarDay _Day = new CalendarDay();
> ....
> }
>
> pour que le XML serialize est:
>
> <CC:CALENDAR View="Day">
> <MONTH ShowHeader=true>
> <InnerHeaderStyle.....etc.>
> </MONTH>
> <DAY>
> <InnerHeaderStyle.....etc.>
> </DAY
> </CC:CALENDAR>
>
>
> Plutot que:
>
> <CC:CALENDAR View="DAY">
> <CSS>
> <MONTH...>
> <DAY...>
> </CSS>
> <SETTINGS>
> <MONTH...>
> <DAY...
> </SETTINGS>
> <BEVAHIOUR>
> <MONTH ShowHeader=true>
> etc.
> </BEHAVIOUR>
> </CC:CALENDAR>
>
> Vous voyer? Solution A est plus 'modulaire'...plus compact... (Il faut pas oublier de maitre
> ExpandableObject TypeConverter sur les CalendarView et CalendarDay...pour que ils aparait dans


le
> PropertyPanel du IDE...)
>
> Seul Hic -- ca marche ...presque. Bug? Le IDE se perde les pedals et quands je change un value


Style
> de CalendarMonth il inject le xml dans... Calendar -- et pas CalendarMonth! Je crois pas qu'il


sait
> quelle control est le control que ils est. Solution?
>
>
>
> Question C: Control.Clone - ca existe ?
>
> Avec le control decrit comme property on peut, au Calendar.OnPreRender() etre ultra simple:
> this.Controls.Add(this.Month);... ben oui... ca marche!
> Bien sure ca marche pas pour l'annee..
> for (int i=0;i<12;i++){Controls.Add(this.Month)....}
> Ya t'il quelque chose comme Clone?
> for (int i=0;i<12;i++){Controls.Add(this.Month.Clone())....}
>
>
>
>
> Question D: Attribute.Default Value -- et les styles...
> Ce qui est bien avec DefaultValue() c'est qui ci c'est mis -- le Property n'est pas ecrit au xml


si
> il est egal au DefaultValue... ca marche tres biens pour les simple types (string, bool, etc..
> Mais pas bien pour les Style (complex type):
>
> [DefaultValue("")]
> public Style SSS {get {if (_SSS ==null){SSS=new Style();_SSS.CssClass="MYDEFAULTCLASS";};return
> _SSS;}}
> private Style _SSS;
>
> ....qui mets dans le xml
>
> <CC:MYCONTROL SSS-CONTROLSTYLE="MYDEFAULTCLASS"/>
>
>
>
>
>
>
>
> Ouf! Je croit que j'ai reussi a mettre sur papier tout les question qui me nargait.... Je vous
> remercie tous de l'avoir lu...(rester reveiller ?!) meme ci cetait vraiment long...Merci.
> En esperant beaucoup de reponse
> :-)
>
>
>
>
>


Avatar
S.Sigal
C'est vrai que KISS c'est la direction que j'aimerai etre dans...
Le problem c'est, qu'a present, submerger dans un pile de livres sur comment faire en asp ...je me
sens beaucoup trop...TSTKIS...

Too Stupid to keep it Simple...



Esperant que cette situation change vite ;-)



"YJLAMOTTE" wrote in message
news:
Et on continue..

Bon si j'ai bien compris , c'est pas facile.. de te suivre ;) , tu veux
qu'au changement de la valeur d'une dropdownlist (ddl) l'affichage de ton
resultat change dynamiquement.

Si tu as une seule ddl : pourquoi ne pas utiliser l'autopostback et
rafraichir ton control qui affiche le resultat ? (un Datagrid je presume)

Si tu en as plusieurs : est ce que c'est choquant (d'un point de vue
ergonomie) d'attendre d'avoir tout choisis et de cliquer sur un bouton ?

Les utilisateurs aime les trucs qui clignote, qui font papa/maman et le café
mais il faut savoir rester simple, avoir quelque chose sans bug ou presque
plutot qu'une interface super classe qui plante au premier click (c'est mon
avis certes.) . Apres si on peut avoir les deux ca ne gache rien.. mais
appliquons la méthode KISS : Keep it stupid and simple :)




"S.Sigal" wrote:

>
> Bonjour:
> (Et excuser mon francais ecrit terrible...)
>
> Je cherche des reponse/verification au questions suivants sur le 'principe' de design de
> CompositeControls complex...
>
> Question A:
> a) Comment faire des Components qui change de 'form'? Si vous avez un control qui contient un
> SELECT, qui montre un enum [Semains, Mois, Annee], et son SelectIndexChanged determine quelle


vue
> montrer, la question est comment faire pour montrer cette vue intelligament. Les choix que je


vois
> sont :
> a.1) Dans Render(), je change de layout (table 2 columns, 7 columns, ou 6, etc.). Le problem


avec
> cette methodology est que Render est apres OnLoad -- alors tout EventHandler attacher au cellule
> sont trop tard. Tout ce que
> j'ai reussi a faire etait de mettre du JS sur le Table.onclick...et passer ceci au server dans


un
> hidden field. Pas tres costaud...
> a.2) Solutions vue dans un blog: faire dans OnLoad le layout de grid -- mais vide -- et racorder


les
> EventHandler la. Ensuite, plus tard dans Render, mettre les numero dans les casse... Ce method
> marcherait pour peutetre un control de mois -- mais je vois mal faire tout ce travaille pour
> jour/semaine/mois, etc...pour mettre a la poubelle 75%....
> a.3) Faire les controls pour le Mois, Annee, etc. des autre control. (CalendarYear,


CalendarMois,
> etc.) qui sont ajouter a Calendar.Controls[] dans Calendar.PreRender() -- ce ci a l'avantage du


fait
> que meme si Calendar a deja passer OnLoad et est deja a OnPreRender/OnLoad -- les sousControls
> (calendarMois) va vite se ratrepper...et passer a travers OnInit, OnLoad, [LesEventsHandlers!],


et
> finalement arriver a PreRender aussi.
> Du EventHandler du souscontrol je appelle manualement le EventHandler dans Calendar -- (trop


tard
> pour BubbleEvent ou autre solution). Cette solution, a laire beucoup plus flexible...sauf un


des
> bouton. Sur le CalendarMonth, chaque row a un ShowWeek button -- qui devrait causer un


changement de
> vue. Mais si le parent control est deja a Render() -- le event est trop tard -- pas de chance a
> changer de vue et sauvegarder dans ViewState. Alors on bouge le LoadSubViewControl() a


PreRender
> plutot que Render()....
> a.4) et c'est possible que il ya d'autre que je ne connais pas encore?
>
> Question B:
> Vous me dite que 'ben alors...le problem est regler, non?'....pas si vite :-) J'ai tellement


galerer
> les derniers semaines en train de comprendres ces choix -- que j'aimerai -- si possible -- un


peu de
> verification que la logique est bonne/fiable...bref, le meilleur... Solution a.3 ma l'aire plus
> modulaire est plus logique en temps de event handling...mais esque oui? J'arrive pas a 'voir'
> comment je devrait ecrir la part DataBind() du parent pour attacher le data au controls


child...?
>
>
> Et je me suis trouver dans un colle avec le handling des properties qui vont avec ce structure:
>
>
> Question C:
> Dans le livre de microsoft "Developing Microsoft Asp.net Server Controls and Components" (tres


tres
> bien!) le demarche pour ecrire un control et ses Styles, etait un peu comme ceci:
> b.1) Overload SaveViewState(){ object[] blobs = new object[2]; blobs[0] > > base.SaveViewState();blobs[1] = _InnerButton.SaveViewState();} et inverser ce process dans
> LoadViewState()...
> b.2) Puis que j'ai beaucoup de Style objects pour chaque view (environs 5 pars vue, fait 20


Styles
> object total), j'ai fait des class comme ceci:
> class CSS_Month : IStateHandler {}
> class CSS_Year : IStateHandler {}
> qui sont ensuit sauvegarder dans viewState de Calendar.
>
> Mais la je me demande si c'est possible de 'economiser' les gestes et faire que au lieu de


garder
> tout les Properties dans Calendar, et les copier a CalendarMonth/CalendarYear quands ils sont
> instantier (voir a.3...) que je offre
> un instance de CalendarMonth comme property de Calendar... Huh?Quoi?!? Hum: je veut dire:
>
> class Calendar (){
> public CalendarDay Day {get {return _Day;}
> CalendarDay _Day = new CalendarDay();
> ....
> }
>
> pour que le XML serialize est:
>
> <CC:CALENDAR View="Day">
> <MONTH ShowHeader=true>
> <InnerHeaderStyle.....etc.>
> </MONTH>
> <DAY>
> <InnerHeaderStyle.....etc.>
> </DAY
> </CC:CALENDAR>
>
>
> Plutot que:
>
> <CC:CALENDAR View="DAY">
> <CSS>
> <MONTH...>
> <DAY...>
> </CSS>
> <SETTINGS>
> <MONTH...>
> <DAY...
> </SETTINGS>
> <BEVAHIOUR>
> <MONTH ShowHeader=true>
> etc.
> </BEHAVIOUR>
> </CC:CALENDAR>
>
> Vous voyer? Solution A est plus 'modulaire'...plus compact... (Il faut pas oublier de maitre
> ExpandableObject TypeConverter sur les CalendarView et CalendarDay...pour que ils aparait dans


le
> PropertyPanel du IDE...)
>
> Seul Hic -- ca marche ...presque. Bug? Le IDE se perde les pedals et quands je change un value


Style
> de CalendarMonth il inject le xml dans... Calendar -- et pas CalendarMonth! Je crois pas qu'il


sait
> quelle control est le control que ils est. Solution?
>
>
>
> Question C: Control.Clone - ca existe ?
>
> Avec le control decrit comme property on peut, au Calendar.OnPreRender() etre ultra simple:
> this.Controls.Add(this.Month);... ben oui... ca marche!
> Bien sure ca marche pas pour l'annee..
> for (int i=0;i<12;i++){Controls.Add(this.Month)....}
> Ya t'il quelque chose comme Clone?
> for (int i=0;i<12;i++){Controls.Add(this.Month.Clone())....}
>
>
>
>
> Question D: Attribute.Default Value -- et les styles...
> Ce qui est bien avec DefaultValue() c'est qui ci c'est mis -- le Property n'est pas ecrit au xml


si
> il est egal au DefaultValue... ca marche tres biens pour les simple types (string, bool, etc..
> Mais pas bien pour les Style (complex type):
>
> [DefaultValue("")]
> public Style SSS {get {if (_SSS ==null){SSS=new Style();_SSS.CssClass="MYDEFAULTCLASS";};return
> _SSS;}}
> private Style _SSS;
>
> ....qui mets dans le xml
>
> <CC:MYCONTROL SSS-CONTROLSTYLE="MYDEFAULTCLASS"/>
>
>
>
>
>
>
>
> Ouf! Je croit que j'ai reussi a mettre sur papier tout les question qui me nargait.... Je vous
> remercie tous de l'avoir lu...(rester reveiller ?!) meme ci cetait vraiment long...Merci.
> En esperant beaucoup de reponse
> :-)
>
>
>
>
>


Avatar
S.Sigal
C'est vrai que eviter le complex c'est bien.

Et je suis presque d'accord sur ce que tu dit en terme de 4 controls...presque.

En fait c'est a peu pres entre les deux que je vis... Un UniControl qui control 4 controls =:-)
(Sauf que...vraiment plus complex! Aie)

Le but etait de garder tout les variables grouper par sous control (les variable Month avec
MonthView, etc.)....sauf garder la partie databind, headerbar, etc. dans le control mere..


En fait , en regardant le tout, (de travers bien sure !) , c'est un peu la meme discussion de
design de tout control parent/enfant: "parent-intelligament, enfant-idiot -- ou parent-stupid,
enfant-intelligament"...non?
Les livre parle plutot de parent-intelligament -- pas de enfants,
toi tu parle de parent stupide, enfant intelligament,
moi, je cherche un compromise entre les deux pour que les enfants saits qu'ils sont du meme
equipe/peuve se parler...


(Je crois que dans la derniere phrase j'ai arriver a insulter la quasi totalite de tout les
controls, et maintenant ils vont tous bouder et mon asp.net va pas marcher tout le weekend....!)











"YJLAMOTTE" wrote in message
news:
J'adore cette nouvelle méthode TSTKIS :)

Plus serieusement, j'ai regardé ton code, en gros tu veux que la personne
puisse choisir un jour, une semaine ou un mois en fonction de sa selection
dans ta DDL dans un control.
Pourquoi ne pas faire 3 control (avec les parametres qui vont bien) et faire
un page.loadcontrol comme ca tu controles independamment le rendu de chaque
control plutot que de chercher a en faire un seul tres complexe
(en plus tu peux les réutiliser 1 par 1 dans certains cas)

J'ai trouvé ce lien qui peut peut etre t'aider..
http://samples.gotdotnet.com/quickstart/aspplus/doc/webpagelets.aspx



"S.Sigal" wrote:

> C'est vrai que KISS c'est la direction que j'aimerai etre dans...
> Le problem c'est, qu'a present, submerger dans un pile de livres sur comment faire en asp ...je


me
> sens beaucoup trop...TSTKIS...
>
> Too Stupid to keep it Simple...
>
>
>
> Esperant que cette situation change vite ;-)
>
>
>
> "YJLAMOTTE" wrote in message
> news:
> > Et on continue..
> >
> > Bon si j'ai bien compris , c'est pas facile.. de te suivre ;) , tu veux
> > qu'au changement de la valeur d'une dropdownlist (ddl) l'affichage de ton
> > resultat change dynamiquement.
> >
> > Si tu as une seule ddl : pourquoi ne pas utiliser l'autopostback et
> > rafraichir ton control qui affiche le resultat ? (un Datagrid je presume)
> >
> > Si tu en as plusieurs : est ce que c'est choquant (d'un point de vue
> > ergonomie) d'attendre d'avoir tout choisis et de cliquer sur un bouton ?
> >
> > Les utilisateurs aime les trucs qui clignote, qui font papa/maman et le café
> > mais il faut savoir rester simple, avoir quelque chose sans bug ou presque
> > plutot qu'une interface super classe qui plante au premier click (c'est mon
> > avis certes.) . Apres si on peut avoir les deux ca ne gache rien.. mais
> > appliquons la méthode KISS : Keep it stupid and simple :)
> >
> >
> >
> >
> > "S.Sigal" wrote:
> >
> > >
> > > Bonjour:
> > > (Et excuser mon francais ecrit terrible...)
> > >
> > > Je cherche des reponse/verification au questions suivants sur le 'principe' de design de
> > > CompositeControls complex...
> > >
> > > Question A:
> > > a) Comment faire des Components qui change de 'form'? Si vous avez un control qui contient


un
> > > SELECT, qui montre un enum [Semains, Mois, Annee], et son SelectIndexChanged determine


quelle
> vue
> > > montrer, la question est comment faire pour montrer cette vue intelligament. Les choix que


je
> vois
> > > sont :
> > > a.1) Dans Render(), je change de layout (table 2 columns, 7 columns, ou 6, etc.). Le problem
> avec
> > > cette methodology est que Render est apres OnLoad -- alors tout EventHandler attacher au


cellule
> > > sont trop tard. Tout ce que
> > > j'ai reussi a faire etait de mettre du JS sur le Table.onclick...et passer ceci au server


dans
> un
> > > hidden field. Pas tres costaud...
> > > a.2) Solutions vue dans un blog: faire dans OnLoad le layout de grid -- mais vide -- et


racorder
> les
> > > EventHandler la. Ensuite, plus tard dans Render, mettre les numero dans les casse... Ce


method
> > > marcherait pour peutetre un control de mois -- mais je vois mal faire tout ce travaille pour
> > > jour/semaine/mois, etc...pour mettre a la poubelle 75%....
> > > a.3) Faire les controls pour le Mois, Annee, etc. des autre control. (CalendarYear,
> CalendarMois,
> > > etc.) qui sont ajouter a Calendar.Controls[] dans Calendar.PreRender() -- ce ci a l'avantage


du
> fait
> > > que meme si Calendar a deja passer OnLoad et est deja a OnPreRender/OnLoad -- les


sousControls
> > > (calendarMois) va vite se ratrepper...et passer a travers OnInit, OnLoad,


[LesEventsHandlers!],
> et
> > > finalement arriver a PreRender aussi.
> > > Du EventHandler du souscontrol je appelle manualement le EventHandler dans Calendar -- (trop
> tard
> > > pour BubbleEvent ou autre solution). Cette solution, a laire beucoup plus flexible...sauf


un
> des
> > > bouton. Sur le CalendarMonth, chaque row a un ShowWeek button -- qui devrait causer un
> changement de
> > > vue. Mais si le parent control est deja a Render() -- le event est trop tard -- pas de


chance a
> > > changer de vue et sauvegarder dans ViewState. Alors on bouge le LoadSubViewControl() a
> PreRender
> > > plutot que Render()....
> > > a.4) et c'est possible que il ya d'autre que je ne connais pas encore?
> > >
> > > Question B:
> > > Vous me dite que 'ben alors...le problem est regler, non?'....pas si vite :-) J'ai tellement
> galerer
> > > les derniers semaines en train de comprendres ces choix -- que j'aimerai -- si possible --


un
> peu de
> > > verification que la logique est bonne/fiable...bref, le meilleur... Solution a.3 ma l'aire


plus
> > > modulaire est plus logique en temps de event handling...mais esque oui? J'arrive pas a


'voir'
> > > comment je devrait ecrir la part DataBind() du parent pour attacher le data au controls
> child...?
> > >
> > >
> > > Et je me suis trouver dans un colle avec le handling des properties qui vont avec ce


structure:
> > >
> > >
> > > Question C:
> > > Dans le livre de microsoft "Developing Microsoft Asp.net Server Controls and Components"


(tres
> tres
> > > bien!) le demarche pour ecrire un control et ses Styles, etait un peu comme ceci:
> > > b.1) Overload SaveViewState(){ object[] blobs = new object[2]; blobs[0] > > > > base.SaveViewState();blobs[1] = _InnerButton.SaveViewState();} et inverser ce process dans
> > > LoadViewState()...
> > > b.2) Puis que j'ai beaucoup de Style objects pour chaque view (environs 5 pars vue, fait 20
> Styles
> > > object total), j'ai fait des class comme ceci:
> > > class CSS_Month : IStateHandler {}
> > > class CSS_Year : IStateHandler {}
> > > qui sont ensuit sauvegarder dans viewState de Calendar.
> > >
> > > Mais la je me demande si c'est possible de 'economiser' les gestes et faire que au lieu de
> garder
> > > tout les Properties dans Calendar, et les copier a CalendarMonth/CalendarYear quands ils


sont
> > > instantier (voir a.3...) que je offre
> > > un instance de CalendarMonth comme property de Calendar... Huh?Quoi?!? Hum: je veut dire:
> > >
> > > class Calendar (){
> > > public CalendarDay Day {get {return _Day;}
> > > CalendarDay _Day = new CalendarDay();
> > > ....
> > > }
> > >
> > > pour que le XML serialize est:
> > >
> > > <CC:CALENDAR View="Day">
> > > <MONTH ShowHeader=true>
> > > <InnerHeaderStyle.....etc.>
> > > </MONTH>
> > > <DAY>
> > > <InnerHeaderStyle.....etc.>
> > > </DAY
> > > </CC:CALENDAR>
> > >
> > >
> > > Plutot que:
> > >
> > > <CC:CALENDAR View="DAY">
> > > <CSS>
> > > <MONTH...>
> > > <DAY...>
> > > </CSS>
> > > <SETTINGS>
> > > <MONTH...>
> > > <DAY...
> > > </SETTINGS>
> > > <BEVAHIOUR>
> > > <MONTH ShowHeader=true>
> > > etc.
> > > </BEHAVIOUR>
> > > </CC:CALENDAR>
> > >
> > > Vous voyer? Solution A est plus 'modulaire'...plus compact... (Il faut pas oublier de maitre
> > > ExpandableObject TypeConverter sur les CalendarView et CalendarDay...pour que ils aparait


dans
> le
> > > PropertyPanel du IDE...)
> > >
> > > Seul Hic -- ca marche ...presque. Bug? Le IDE se perde les pedals et quands je change un


value
> Style
> > > de CalendarMonth il inject le xml dans... Calendar -- et pas CalendarMonth! Je crois pas


qu'il
> sait
> > > quelle control est le control que ils est. Solution?
> > >
> > >
> > >
> > > Question C: Control.Clone - ca existe ?
> > >
> > > Avec le control decrit comme property on peut, au Calendar.OnPreRender() etre ultra simple:
> > > this.Controls.Add(this.Month);... ben oui... ca marche!
> > > Bien sure ca marche pas pour l'annee..
> > > for (int i=0;i<12;i++){Controls.Add(this.Month)....}
> > > Ya t'il quelque chose comme Clone?
> > > for (int i=0;i<12;i++){Controls.Add(this.Month.Clone())....}
> > >
> > >
> > >
> > >
> > > Question D: Attribute.Default Value -- et les styles...
> > > Ce qui est bien avec DefaultValue() c'est qui ci c'est mis -- le Property n'est pas ecrit au


xml
> si
> > > il est egal au DefaultValue... ca marche tres biens pour les simple types (string, bool,


etc..
> > > Mais pas bien pour les Style (complex type):
> > >
> > > [DefaultValue("")]
> > > public Style SSS {get {if (_SSS ==null){SSS=new


Style();_SSS.CssClass="MYDEFAULTCLASS";};return
> > > _SSS;}}
> > > private Style _SSS;
> > >
> > > ....qui mets dans le xml
> > >
> > > <CC:MYCONTROL SSS-CONTROLSTYLE="MYDEFAULTCLASS"/>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Ouf! Je croit que j'ai reussi a mettre sur papier tout les question qui me nargait.... Je


vous
> > > remercie tous de l'avoir lu...(rester reveiller ?!) meme ci cetait vraiment long...Merci.
> > > En esperant beaucoup de reponse
> > > :-)
> > >
> > >
> > >
> > >
> > >
>
>
>


Avatar
YJLAMOTTE
Effectivement si j'était un control je ne voudrais plus jamais t'adresser la
parole , espece de malautru ! :)
Plus sérieusement, as tu trouvé une solution ou une nouvelle voie ?

YJLAMOTTE

"S.Sigal" wrote:

C'est vrai que eviter le complex c'est bien.

Et je suis presque d'accord sur ce que tu dit en terme de 4 controls...presque.

En fait c'est a peu pres entre les deux que je vis... Un UniControl qui control 4 controls =:-)
(Sauf que...vraiment plus complex! Aie)

Le but etait de garder tout les variables grouper par sous control (les variable Month avec
MonthView, etc.)....sauf garder la partie databind, headerbar, etc. dans le control mere..


En fait , en regardant le tout, (de travers bien sure !) , c'est un peu la meme discussion de
design de tout control parent/enfant: "parent-intelligament, enfant-idiot -- ou parent-stupid,
enfant-intelligament"...non?
Les livre parle plutot de parent-intelligament -- pas de enfants,
toi tu parle de parent stupide, enfant intelligament,
moi, je cherche un compromise entre les deux pour que les enfants saits qu'ils sont du meme
equipe/peuve se parler...


(Je crois que dans la derniere phrase j'ai arriver a insulter la quasi totalite de tout les
controls, et maintenant ils vont tous bouder et mon asp.net va pas marcher tout le weekend....!)











"YJLAMOTTE" wrote in message
news:
> J'adore cette nouvelle méthode TSTKIS :)
>
> Plus serieusement, j'ai regardé ton code, en gros tu veux que la personne
> puisse choisir un jour, une semaine ou un mois en fonction de sa selection
> dans ta DDL dans un control.
> Pourquoi ne pas faire 3 control (avec les parametres qui vont bien) et faire
> un page.loadcontrol comme ca tu controles independamment le rendu de chaque
> control plutot que de chercher a en faire un seul tres complexe
> (en plus tu peux les réutiliser 1 par 1 dans certains cas)
>
> J'ai trouvé ce lien qui peut peut etre t'aider..
> http://samples.gotdotnet.com/quickstart/aspplus/doc/webpagelets.aspx
>
>
>
> "S.Sigal" wrote:
>
> > C'est vrai que KISS c'est la direction que j'aimerai etre dans...
> > Le problem c'est, qu'a present, submerger dans un pile de livres sur comment faire en asp ...je
me
> > sens beaucoup trop...TSTKIS...
> >
> > Too Stupid to keep it Simple...
> >
> >
> >
> > Esperant que cette situation change vite ;-)
> >
> >
> >
> > "YJLAMOTTE" wrote in message
> > news:
> > > Et on continue..
> > >
> > > Bon si j'ai bien compris , c'est pas facile.. de te suivre ;) , tu veux
> > > qu'au changement de la valeur d'une dropdownlist (ddl) l'affichage de ton
> > > resultat change dynamiquement.
> > >
> > > Si tu as une seule ddl : pourquoi ne pas utiliser l'autopostback et
> > > rafraichir ton control qui affiche le resultat ? (un Datagrid je presume)
> > >
> > > Si tu en as plusieurs : est ce que c'est choquant (d'un point de vue
> > > ergonomie) d'attendre d'avoir tout choisis et de cliquer sur un bouton ?
> > >
> > > Les utilisateurs aime les trucs qui clignote, qui font papa/maman et le café
> > > mais il faut savoir rester simple, avoir quelque chose sans bug ou presque
> > > plutot qu'une interface super classe qui plante au premier click (c'est mon
> > > avis certes.) . Apres si on peut avoir les deux ca ne gache rien.. mais
> > > appliquons la méthode KISS : Keep it stupid and simple :)
> > >
> > >
> > >
> > >
> > > "S.Sigal" wrote:
> > >
> > > >
> > > > Bonjour:
> > > > (Et excuser mon francais ecrit terrible...)
> > > >
> > > > Je cherche des reponse/verification au questions suivants sur le 'principe' de design de
> > > > CompositeControls complex...
> > > >
> > > > Question A:
> > > > a) Comment faire des Components qui change de 'form'? Si vous avez un control qui contient
un
> > > > SELECT, qui montre un enum [Semains, Mois, Annee], et son SelectIndexChanged determine
quelle
> > vue
> > > > montrer, la question est comment faire pour montrer cette vue intelligament. Les choix que
je
> > vois
> > > > sont :
> > > > a.1) Dans Render(), je change de layout (table 2 columns, 7 columns, ou 6, etc.). Le problem
> > avec
> > > > cette methodology est que Render est apres OnLoad -- alors tout EventHandler attacher au
cellule
> > > > sont trop tard. Tout ce que
> > > > j'ai reussi a faire etait de mettre du JS sur le Table.onclick...et passer ceci au server
dans
> > un
> > > > hidden field. Pas tres costaud...
> > > > a.2) Solutions vue dans un blog: faire dans OnLoad le layout de grid -- mais vide -- et
racorder
> > les
> > > > EventHandler la. Ensuite, plus tard dans Render, mettre les numero dans les casse... Ce
method
> > > > marcherait pour peutetre un control de mois -- mais je vois mal faire tout ce travaille pour
> > > > jour/semaine/mois, etc...pour mettre a la poubelle 75%....
> > > > a.3) Faire les controls pour le Mois, Annee, etc. des autre control. (CalendarYear,
> > CalendarMois,
> > > > etc.) qui sont ajouter a Calendar.Controls[] dans Calendar.PreRender() -- ce ci a l'avantage
du
> > fait
> > > > que meme si Calendar a deja passer OnLoad et est deja a OnPreRender/OnLoad -- les
sousControls
> > > > (calendarMois) va vite se ratrepper...et passer a travers OnInit, OnLoad,
[LesEventsHandlers!],
> > et
> > > > finalement arriver a PreRender aussi.
> > > > Du EventHandler du souscontrol je appelle manualement le EventHandler dans Calendar -- (trop
> > tard
> > > > pour BubbleEvent ou autre solution). Cette solution, a laire beucoup plus flexible...sauf
un
> > des
> > > > bouton. Sur le CalendarMonth, chaque row a un ShowWeek button -- qui devrait causer un
> > changement de
> > > > vue. Mais si le parent control est deja a Render() -- le event est trop tard -- pas de
chance a
> > > > changer de vue et sauvegarder dans ViewState. Alors on bouge le LoadSubViewControl() a
> > PreRender
> > > > plutot que Render()....
> > > > a.4) et c'est possible que il ya d'autre que je ne connais pas encore?
> > > >
> > > > Question B:
> > > > Vous me dite que 'ben alors...le problem est regler, non?'....pas si vite :-) J'ai tellement
> > galerer
> > > > les derniers semaines en train de comprendres ces choix -- que j'aimerai -- si possible --
un
> > peu de
> > > > verification que la logique est bonne/fiable...bref, le meilleur... Solution a.3 ma l'aire
plus
> > > > modulaire est plus logique en temps de event handling...mais esque oui? J'arrive pas a
'voir'
> > > > comment je devrait ecrir la part DataBind() du parent pour attacher le data au controls
> > child...?
> > > >
> > > >
> > > > Et je me suis trouver dans un colle avec le handling des properties qui vont avec ce
structure:
> > > >
> > > >
> > > > Question C:
> > > > Dans le livre de microsoft "Developing Microsoft Asp.net Server Controls and Components"
(tres
> > tres
> > > > bien!) le demarche pour ecrire un control et ses Styles, etait un peu comme ceci:
> > > > b.1) Overload SaveViewState(){ object[] blobs = new object[2]; blobs[0] > > > > > base.SaveViewState();blobs[1] = _InnerButton.SaveViewState();} et inverser ce process dans
> > > > LoadViewState()...
> > > > b.2) Puis que j'ai beaucoup de Style objects pour chaque view (environs 5 pars vue, fait 20
> > Styles
> > > > object total), j'ai fait des class comme ceci:
> > > > class CSS_Month : IStateHandler {}
> > > > class CSS_Year : IStateHandler {}
> > > > qui sont ensuit sauvegarder dans viewState de Calendar.
> > > >
> > > > Mais la je me demande si c'est possible de 'economiser' les gestes et faire que au lieu de
> > garder
> > > > tout les Properties dans Calendar, et les copier a CalendarMonth/CalendarYear quands ils
sont
> > > > instantier (voir a.3...) que je offre
> > > > un instance de CalendarMonth comme property de Calendar... Huh?Quoi?!? Hum: je veut dire:
> > > >
> > > > class Calendar (){
> > > > public CalendarDay Day {get {return _Day;}
> > > > CalendarDay _Day = new CalendarDay();
> > > > ....
> > > > }
> > > >
> > > > pour que le XML serialize est:
> > > >
> > > > <CC:CALENDAR View="Day">
> > > > <MONTH ShowHeader=true>
> > > > <InnerHeaderStyle.....etc.>
> > > > </MONTH>
> > > > <DAY>
> > > > <InnerHeaderStyle.....etc.>
> > > > </DAY
> > > > </CC:CALENDAR>
> > > >
> > > >
> > > > Plutot que:
> > > >
> > > > <CC:CALENDAR View="DAY">
> > > > <CSS>
> > > > <MONTH...>
> > > > <DAY...>
> > > > </CSS>
> > > > <SETTINGS>
> > > > <MONTH...>
> > > > <DAY...
> > > > </SETTINGS>
> > > > <BEVAHIOUR>
> > > > <MONTH ShowHeader=true>
> > > > etc.
> > > > </BEHAVIOUR>
> > > > </CC:CALENDAR>
> > > >
> > > > Vous voyer? Solution A est plus 'modulaire'...plus compact... (Il faut pas oublier de maitre
> > > > ExpandableObject TypeConverter sur les CalendarView et CalendarDay...pour que ils aparait
dans
> > le
> > > > PropertyPanel du IDE...)
> > > >
> > > > Seul Hic -- ca marche ...presque. Bug? Le IDE se perde les pedals et quands je change un
value
> > Style
> > > > de CalendarMonth il inject le xml dans... Calendar -- et pas CalendarMonth! Je crois pas
qu'il
> > sait
> > > > quelle control est le control que ils est. Solution?
> > > >
> > > >
> > > >
> > > > Question C: Control.Clone - ca existe ?
> > > >
> > > > Avec le control decrit comme property on peut, au Calendar.OnPreRender() etre ultra simple:
> > > > this.Controls.Add(this.Month);... ben oui... ca marche!
> > > > Bien sure ca marche pas pour l'annee..
> > > > for (int i=0;i<12;i++){Controls.Add(this.Month)....}
> > > > Ya t'il quelque chose comme Clone?
> > > > for (int i=0;i<12;i++){Controls.Add(this.Month.Clone())....}
> > > >
> > > >
> > > >
> > > >
> > > > Question D: Attribute.Default Value -- et les styles...
> > > > Ce qui est bien avec DefaultValue() c'est qui ci c'est mis -- le Property n'est pas ecrit au
xml
> > si
> > > > il est egal au DefaultValue... ca marche tres biens pour les simple types (string, bool,
etc..
> > > > Mais pas bien pour les Style (complex type):
> > > >
> > > > [DefaultValue("")]
> > > > public Style SSS {get {if (_SSS ==null){SSS=new
Style();_SSS.CssClass="MYDEFAULTCLASS";};return
> > > > _SSS;}}
> > > > private Style _SSS;
> > > >
> > > > ....qui mets dans le xml
> > > >
> > > > <CC:MYCONTROL SSS-CONTROLSTYLE="MYDEFAULTCLASS"/>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Ouf! Je croit que j'ai reussi a mettre sur papier tout les question qui me nargait.... Je
vous
> > > > remercie tous de l'avoir lu...(rester reveiller ?!) meme ci cetait vraiment long...Merci.
> > > > En esperant beaucoup de reponse
> > > > :-)
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >





Avatar
S.Sigal
Salut Yjlamotte :-)

Le problem avec les controls -- c'est leur nom. Je croit que c'est ca...
Ons aurait du les nommes des des "Controlle" (il me manque accent aigue sur clavier)... sa les
aurait appris qui etait "Le Boss" -- au lieu de ce qui ce passe trop souvent (dans mon IDE), qui est
que je suis le Controlle pars les Control-luers!

Bon. Betisse apart.
J'ai rode dans les forums de chez ASP.NET/Forums/Building Controls et pose des questions -- et Andy
Smith (un sort de guru des controls?) ma carrement dit que "tout en un/pas de sous controls" etait
meilleur...
Peutetre je devrait prendre son avis -- ils sait beaucoup plus que moi en gros-- maise j'ai aussi
remarque que les controlle que ils demontre ne sont pas aussi complex que un multi-view.......

Etant que je suis tres obstiner, je suis en train de continuer le chemain tout seuls et Lundi apres
quelque experiments, je te dirait qu'elle voit j'ai pris, ok?

A lundi!


"YJLAMOTTE" wrote in message
news:
Effectivement si j'était un control je ne voudrais plus jamais t'adresser la
parole , espece de malautru ! :)
Plus sérieusement, as tu trouvé une solution ou une nouvelle voie ?

YJLAMOTTE

"S.Sigal" wrote:

> C'est vrai que eviter le complex c'est bien.
>
> Et je suis presque d'accord sur ce que tu dit en terme de 4 controls...presque.
>
> En fait c'est a peu pres entre les deux que je vis... Un UniControl qui control 4 controls =:-)
> (Sauf que...vraiment plus complex! Aie)
>
> Le but etait de garder tout les variables grouper par sous control (les variable Month avec
> MonthView, etc.)....sauf garder la partie databind, headerbar, etc. dans le control mere..
>
>
> En fait , en regardant le tout, (de travers bien sure !) , c'est un peu la meme discussion de
> design de tout control parent/enfant: "parent-intelligament, enfant-idiot -- ou parent-stupid,
> enfant-intelligament"...non?
> Les livre parle plutot de parent-intelligament -- pas de enfants,
> toi tu parle de parent stupide, enfant intelligament,
> moi, je cherche un compromise entre les deux pour que les enfants saits qu'ils sont du meme
> equipe/peuve se parler...
>
>
> (Je crois que dans la derniere phrase j'ai arriver a insulter la quasi totalite de tout les
> controls, et maintenant ils vont tous bouder et mon asp.net va pas marcher tout le weekend....!)
>
>
>
>
>
>
>
>
>
>
>
> "YJLAMOTTE" wrote in message
> news:
> > J'adore cette nouvelle méthode TSTKIS :)
> >
> > Plus serieusement, j'ai regardé ton code, en gros tu veux que la personne
> > puisse choisir un jour, une semaine ou un mois en fonction de sa selection
> > dans ta DDL dans un control.
> > Pourquoi ne pas faire 3 control (avec les parametres qui vont bien) et faire
> > un page.loadcontrol comme ca tu controles independamment le rendu de chaque
> > control plutot que de chercher a en faire un seul tres complexe
> > (en plus tu peux les réutiliser 1 par 1 dans certains cas)
> >
> > J'ai trouvé ce lien qui peut peut etre t'aider..
> > http://samples.gotdotnet.com/quickstart/aspplus/doc/webpagelets.aspx
> >
> >
> >
> > "S.Sigal" wrote:
> >
> > > C'est vrai que KISS c'est la direction que j'aimerai etre dans...
> > > Le problem c'est, qu'a present, submerger dans un pile de livres sur comment faire en asp


...je
> me
> > > sens beaucoup trop...TSTKIS...
> > >
> > > Too Stupid to keep it Simple...
> > >
> > >
> > >
> > > Esperant que cette situation change vite ;-)
> > >
> > >
> > >
> > > "YJLAMOTTE" wrote in message
> > > news:
> > > > Et on continue..
> > > >
> > > > Bon si j'ai bien compris , c'est pas facile.. de te suivre ;) , tu veux
> > > > qu'au changement de la valeur d'une dropdownlist (ddl) l'affichage de ton
> > > > resultat change dynamiquement.
> > > >
> > > > Si tu as une seule ddl : pourquoi ne pas utiliser l'autopostback et
> > > > rafraichir ton control qui affiche le resultat ? (un Datagrid je presume)
> > > >
> > > > Si tu en as plusieurs : est ce que c'est choquant (d'un point de vue
> > > > ergonomie) d'attendre d'avoir tout choisis et de cliquer sur un bouton ?
> > > >
> > > > Les utilisateurs aime les trucs qui clignote, qui font papa/maman et le café
> > > > mais il faut savoir rester simple, avoir quelque chose sans bug ou presque
> > > > plutot qu'une interface super classe qui plante au premier click (c'est mon
> > > > avis certes.) . Apres si on peut avoir les deux ca ne gache rien.. mais
> > > > appliquons la méthode KISS : Keep it stupid and simple :)
> > > >
> > > >
> > > >
> > > >
> > > > "S.Sigal" wrote:
> > > >
> > > > >
> > > > > Bonjour:
> > > > > (Et excuser mon francais ecrit terrible...)
> > > > >
> > > > > Je cherche des reponse/verification au questions suivants sur le 'principe' de design de
> > > > > CompositeControls complex...
> > > > >
> > > > > Question A:
> > > > > a) Comment faire des Components qui change de 'form'? Si vous avez un control qui


contient
> un
> > > > > SELECT, qui montre un enum [Semains, Mois, Annee], et son SelectIndexChanged determine
> quelle
> > > vue
> > > > > montrer, la question est comment faire pour montrer cette vue intelligament. Les choix


que
> je
> > > vois
> > > > > sont :
> > > > > a.1) Dans Render(), je change de layout (table 2 columns, 7 columns, ou 6, etc.). Le


problem
> > > avec
> > > > > cette methodology est que Render est apres OnLoad -- alors tout EventHandler attacher au
> cellule
> > > > > sont trop tard. Tout ce que
> > > > > j'ai reussi a faire etait de mettre du JS sur le Table.onclick...et passer ceci au


server
> dans
> > > un
> > > > > hidden field. Pas tres costaud...
> > > > > a.2) Solutions vue dans un blog: faire dans OnLoad le layout de grid -- mais vide -- et
> racorder
> > > les
> > > > > EventHandler la. Ensuite, plus tard dans Render, mettre les numero dans les casse... Ce
> method
> > > > > marcherait pour peutetre un control de mois -- mais je vois mal faire tout ce travaille


pour
> > > > > jour/semaine/mois, etc...pour mettre a la poubelle 75%....
> > > > > a.3) Faire les controls pour le Mois, Annee, etc. des autre control. (CalendarYear,
> > > CalendarMois,
> > > > > etc.) qui sont ajouter a Calendar.Controls[] dans Calendar.PreRender() -- ce ci a


l'avantage
> du
> > > fait
> > > > > que meme si Calendar a deja passer OnLoad et est deja a OnPreRender/OnLoad -- les
> sousControls
> > > > > (calendarMois) va vite se ratrepper...et passer a travers OnInit, OnLoad,
> [LesEventsHandlers!],
> > > et
> > > > > finalement arriver a PreRender aussi.
> > > > > Du EventHandler du souscontrol je appelle manualement le EventHandler dans Calendar --


(trop
> > > tard
> > > > > pour BubbleEvent ou autre solution). Cette solution, a laire beucoup plus


flexible...sauf
> un
> > > des
> > > > > bouton. Sur le CalendarMonth, chaque row a un ShowWeek button -- qui devrait causer un
> > > changement de
> > > > > vue. Mais si le parent control est deja a Render() -- le event est trop tard -- pas de
> chance a
> > > > > changer de vue et sauvegarder dans ViewState. Alors on bouge le LoadSubViewControl() a
> > > PreRender
> > > > > plutot que Render()....
> > > > > a.4) et c'est possible que il ya d'autre que je ne connais pas encore?
> > > > >
> > > > > Question B:
> > > > > Vous me dite que 'ben alors...le problem est regler, non?'....pas si vite :-) J'ai


tellement
> > > galerer
> > > > > les derniers semaines en train de comprendres ces choix -- que j'aimerai -- si


possible --
> un
> > > peu de
> > > > > verification que la logique est bonne/fiable...bref, le meilleur... Solution a.3 ma


l'aire
> plus
> > > > > modulaire est plus logique en temps de event handling...mais esque oui? J'arrive pas a
> 'voir'
> > > > > comment je devrait ecrir la part DataBind() du parent pour attacher le data au controls
> > > child...?
> > > > >
> > > > >
> > > > > Et je me suis trouver dans un colle avec le handling des properties qui vont avec ce
> structure:
> > > > >
> > > > >
> > > > > Question C:
> > > > > Dans le livre de microsoft "Developing Microsoft Asp.net Server Controls and Components"
> (tres
> > > tres
> > > > > bien!) le demarche pour ecrire un control et ses Styles, etait un peu comme ceci:
> > > > > b.1) Overload SaveViewState(){ object[] blobs = new object[2]; blobs[0] > > > > > > base.SaveViewState();blobs[1] = _InnerButton.SaveViewState();} et inverser ce process


dans
> > > > > LoadViewState()...
> > > > > b.2) Puis que j'ai beaucoup de Style objects pour chaque view (environs 5 pars vue, fait


20
> > > Styles
> > > > > object total), j'ai fait des class comme ceci:
> > > > > class CSS_Month : IStateHandler {}
> > > > > class CSS_Year : IStateHandler {}
> > > > > qui sont ensuit sauvegarder dans viewState de Calendar.
> > > > >
> > > > > Mais la je me demande si c'est possible de 'economiser' les gestes et faire que au lieu


de
> > > garder
> > > > > tout les Properties dans Calendar, et les copier a CalendarMonth/CalendarYear quands ils
> sont
> > > > > instantier (voir a.3...) que je offre
> > > > > un instance de CalendarMonth comme property de Calendar... Huh?Quoi?!? Hum: je veut


dire:
> > > > >
> > > > > class Calendar (){
> > > > > public CalendarDay Day {get {return _Day;}
> > > > > CalendarDay _Day = new CalendarDay();
> > > > > ....
> > > > > }
> > > > >
> > > > > pour que le XML serialize est:
> > > > >
> > > > > <CC:CALENDAR View="Day">
> > > > > <MONTH ShowHeader=true>
> > > > > <InnerHeaderStyle.....etc.>
> > > > > </MONTH>
> > > > > <DAY>
> > > > > <InnerHeaderStyle.....etc.>
> > > > > </DAY
> > > > > </CC:CALENDAR>
> > > > >
> > > > >
> > > > > Plutot que:
> > > > >
> > > > > <CC:CALENDAR View="DAY">
> > > > > <CSS>
> > > > > <MONTH...>
> > > > > <DAY...>
> > > > > </CSS>
> > > > > <SETTINGS>
> > > > > <MONTH...>
> > > > > <DAY...
> > > > > </SETTINGS>
> > > > > <BEVAHIOUR>
> > > > > <MONTH ShowHeader=true>
> > > > > etc.
> > > > > </BEHAVIOUR>
> > > > > </CC:CALENDAR>
> > > > >
> > > > > Vous voyer? Solution A est plus 'modulaire'...plus compact... (Il faut pas oublier de


maitre
> > > > > ExpandableObject TypeConverter sur les CalendarView et CalendarDay...pour que ils


aparait
> dans
> > > le
> > > > > PropertyPanel du IDE...)
> > > > >
> > > > > Seul Hic -- ca marche ...presque. Bug? Le IDE se perde les pedals et quands je change un
> value
> > > Style
> > > > > de CalendarMonth il inject le xml dans... Calendar -- et pas CalendarMonth! Je crois pas
> qu'il
> > > sait
> > > > > quelle control est le control que ils est. Solution?
> > > > >
> > > > >
> > > > >
> > > > > Question C: Control.Clone - ca existe ?
> > > > >
> > > > > Avec le control decrit comme property on peut, au Calendar.OnPreRender() etre ultra


simple:
> > > > > this.Controls.Add(this.Month);... ben oui... ca marche!
> > > > > Bien sure ca marche pas pour l'annee..
> > > > > for (int i=0;i<12;i++){Controls.Add(this.Month)....}
> > > > > Ya t'il quelque chose comme Clone?
> > > > > for (int i=0;i<12;i++){Controls.Add(this.Month.Clone())....}
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Question D: Attribute.Default Value -- et les styles...
> > > > > Ce qui est bien avec DefaultValue() c'est qui ci c'est mis -- le Property n'est pas


ecrit au
> xml
> > > si
> > > > > il est egal au DefaultValue... ca marche tres biens pour les simple types (string, bool,
> etc..
> > > > > Mais pas bien pour les Style (complex type):
> > > > >
> > > > > [DefaultValue("")]
> > > > > public Style SSS {get {if (_SSS ==null){SSS=new
> Style();_SSS.CssClass="MYDEFAULTCLASS";};return
> > > > > _SSS;}}
> > > > > private Style _SSS;
> > > > >
> > > > > ....qui mets dans le xml
> > > > >
> > > > > <CC:MYCONTROL SSS-CONTROLSTYLE="MYDEFAULTCLASS"/>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Ouf! Je croit que j'ai reussi a mettre sur papier tout les question qui me nargait....


Je
> vous
> > > > > remercie tous de l'avoir lu...(rester reveiller ?!) meme ci cetait vraiment


long...Merci.
> > > > > En esperant beaucoup de reponse
> > > > > :-)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>