salut,

#region permet de "regrouper" le code au niveau de l'interface de visual studio (pour plus de lisibilité).

tout le code qui se trouve entre #region et #end region peut être "fermé/déployé" avec les + - dans l'interface de développement, ce qui évite de scroller sur 18 pages...

oki, donc environs 5000 contrôles...

tiens moi au courant pour la mémoire, ca m'intéresse énormément.

yopyop

yop,

effectivement, je n'ai pas tout testé.

Mais il me semble que les les contrôles doivent toujours être dans entre les balises form.
Autrement, pour partir de la page directement il suffit de ne pas utiliser l'instruction
form = FindFormControl(page); (mettre form=Page devrait enlever le bug).

Concernant la rapidité, je peux certainement améliorer ca (mais g pas le temps pour l'instant, surtout de créer la page de test. Environs combien de contrôles ? 5 fois plus rapide, mais genre on passe de 1 à 5 secondes ou de 0.1 seconde à 0.5 ?).

bref ... j'ai au moins montré comment parcourir un arbre sans récursivité, ce qui à mon avis est intéressant ... non ?

Concernant ton static, pourquoi ne passes-tu pas le ClientID en paramètre ?
private static Control getControlFromClientIDInternal(Control Container, ref String ClientId)
(je ne connais pas l'équivalent de ByRef en C#).
Avec ca ta variable n'est pas copiée en mémoire (juste la référence).

Concernant la mémoire sur le serveur, tout dépend de la fréquentation de ton application.
Sur les gros sites ca peut causer de gros problèmes (je prèfère ajouter 2-3 secondes de loading sur une page plutôt que d'empêcher 500 personnes de bosser pendant 30 minutes).

yopyop

GROSSE déception :(

Malheureusement, le ClientId d'un contrôle ne contient pas tous les contrôles de sa hiérarchie (si le contrôle est dans un placeholder, le nom du placeholder contenant le contrôle n'apparait pas dans le ClientId).

Donc on peut oublier l'idée d'utiliser le clientId afin de "scier" les mauvaises branches ... (mouaip, bravo Microsoft).

Bref, voici la même recherche, mais SANS utiliser la récursivité.
Je ne sais pas si c'est plus rapide .. (je pense que oui, mais surout que ca prends moins de mémoire) mais bon, comme ca je montre comment faire une recherche dans un arbre sans utiliser la récursivité (ca devrait au moins intéresser les codeurs portés sur l'aglorythmique...j'espère):

//Return the Control form
public Control FindFormControl(Page page)
{
foreach (Control c in page.Controls )
{
if (c.ToString() == "System.Web.UI.HtmlControls.HtmlForm")
return c;
}
return null;
}

//Return a Control retrived by its ClientId
public Control FindControlByClientID(Page page, String clientId)
{
Control c = null;
Control form = null;
ArrayList arr = new ArrayList(); //Buffer contenant les contrôles à checker

form = FindFormControl(page);

if (form!=null)
{
arr.Add(form);
while (arr.Count>0)
{
c = (Control)arr[0];
if (c.ClientID == clientId)
{
arr.Clear();
return c;
}
else
{
foreach (Control child in c.Controls)
{
arr.Add(child);
}
arr.RemoveAt(0);
}
}
}
return null;
}


Qu'en pensez-vous ?

re,

c'était un example pour parcourir un arbre sans utiliser la récursivité....
maintenant que l'arbre soit dans une base de données, en mémoire, en xml ca ne change rien, le principe est le même (faut vraiment te prendre par la main toi ;-) ).

bon bein
demain je pose le code en C#, avec le parcour de webcontrols

bon, bein voilà un example .... en java:

je lui passe un message_id et je vais chercher tous ses enfants.


/**
* build a string containing the id of a message and all ids of its replies
*
* @param String inSQL
* @return a String
*/
private static String getAll(String inSQL){
String firstId = inSQL;
Vector inIds  = new Vector();
Vector outIds = new Vector();
String anId = "";
inIds.addElement(inSQL);
while(inIds.size()>0){
anId = (String)inIds.firstElement();
outIds.addElement(inIds.firstElement());
inIds.removeElementAt(0);
try{
ResultSet rs = ForumApplicationDB.execSql("select message_id from message where parent_id=" + anId );
while(rs.next()){
inIds.addElement(rs.getString("message_id"));
//Tools.toConsole("MessageDB: enfant trouve ", "" + inIds.lastElement() );
}
}catch(SQLException sqlEx){
Tools.toConsole("MessageDB: error listing", sqlEx.toString());
}
//Tools.toConsole("MessageDB: hors boucle", "hors");
//Tools.toConsole("MessageDB: liste out ", "" + outIds.toString() );
//Tools.toConsole("MessageDB: liste in ", "" + inIds.toString() );
}
return outIds.toString();
}

ca veux dire:

la récursivité peut être évitée si la dernière instruction est un return (évité ne veut pas dire arrêté !!!!)

ce qui veux dire que
1/
il faut éviter la récursivité au maximum, surtout lorsqu'on ne sait pas combien d'appels récursifs il va y avoir (ca prend beaucoup beaucoup beaucoup beaucoup de mémoire).
2/
si la dernière instruction de ta fonction récursive est un return (ou un appel à la fonction récursive, j'avoue ne plus me souvenir .. l'âge sans doute), tu peux transformer ta fonction récursive en une fonction non récursive (donc pas arrêter, mais éviter la récursivité. Essaie d'éviter une voiture qui roule à 50km/h et ensuite essaie de l'arrêté, tu comprendras qu'il y a une différence entre ces deux mots ;-) ).

donc au final, ca veut dire beaucoup si on veux bien se donner la peine de comprendre ;-)

"qui ne veut pas dire grand chose à part arrêter tout une fois qu'on a trouvé ce qu'on cherche..." <- tsss tsss ... pas très gentleman de votre part monsieur ;-)

yopyop

PS:
Merci Nurgle ...

re,

pas d'accord,
lorsque tu as un itinéraire et 4 routes devant toi, tu n'essaies pas les 4 routes et toutes leurs "sous-routes". Tu regardes les 4 routes et t'engouffre uniquement dans celle qui est dans ton itinéraire.

c'est la même chose dans ce cas là...

si ton contrôle est à la racine (ta destination est l'une des 4 routes), là c'est effectivement kifkif, mais si c'est un contrôle "enfant" (une "sous-route"), tu évites de parcourir tout les autres enfants des autres contrôles...

et quand je parle d'éviter la récursivité, je ne parle pas simplement de l'arrêter, mais de ne pas l'utiliser du tout.

yopyop

exact,

JesusOnline:
mon idée pose effectivement des problèmes dans le cas où un développeur mets un "_" dans le nom d'un contrôle (peut-être faut-il changer de développeur ;-) ). L'idée n'est donc pas très "universelle".

Nurgle:
bien que l'on puisse spécifier le controle séparateur, il ne faut pas modifier celui utilisé par ClientId (_ est supporté par le client script c'est pour cela que Microsoft l'utilise et non un "#","@","*" ou autre).


Deux suggestions (encore):

1/
Si FindControl fait lui-même une recherche récursive, pourquoi ne par continuer à utiliser l'idée du split mais en partant de la fin de la string (ClientID). En 2-3 findcontrol on retrouve le composant (n + le nombre de _ mis par le développeur)

2/
Autrement, pourquoi ne pas "scier" les mauvaises branches dès le départ ??
Tu check si le Container.ClientId est contenu dans le _ClientID (Instr)
Si oui, tu es dans la bonne ramification tu continues
Si non, tu n'as même pas besoin de checker les enfants, la branche est "pourrie".

Pourquoi déclarer _ClientId en shared ... euh pardon ... en static (vb.net)????
Si tu lances ta recherche 2 fois en même temps (+- en même temps) ca ne fonctionne plus...
Non ?

Et finalement, un vieux de la vielle m'a appris il y a bien longtemps que la récursivité pouvait être évitée si la dernière instruction est un return ;)

salut,

source intéressante.

Perso je n'aurai pas utilisé la récursivité (Ca peut utiliser pas mal de ressources suivant la profondeur. De plus, dans le pire des cas, tu parcours TOUS les contrôles de la page), mais simplement le fait que ClientId contient "l'arbre" des contrôles parents:

ctrl1_subctrl1_subsubctrl3_ControlToFind_subctrl, split + while et on trouve le contrôle sans devoir parcourir tous les contrôles dans la page mais uniquement sa hiérarchie.

Mais bon, on a tous notre façon de faire ;)

yopyop