RECUPERER L'INSTANCE D'UN CONTROL À PARTIR DE SON CLIENTID

Commentaire de Nurgle le 19/06/2006 18:12:30 administrateur CS

Eh ben voilà, on avait bien la même idée :)
Mais pourquoi ça :
# Control c = Container.FindControl(ClientID);
#             if (c != null)
#                 return c;

??
ça voudrait dire que c.ClientID = c.ID

Commentaire de Nurgle le 19/06/2006 19:17:07 administrateur CS

ah exact... c'est logique :p

très bonne idée en tout cas, ça peut parfois servir quand on fait de l'ajax :D
10/10

Commentaire de jesusonline le 04/07/2006 17:46:46 administrateur CS

YopYop, je suis trés interessé par ta solution, tu pourrais développer, car la je vois pas la diférence entre ta méthode et la mienne :s

Commentaire de jesusonline le 04/07/2006 18:21:28 administrateur CS

Je ne pense pas que ca fonctionnne. Dans la boite ou je suis par exemple certains Controles sont nommé id="_toto", imagine aussi un controle nommé "_to_to"

Les controles n'ont pas obligatoirement d'id, ce qui veut dire qu'on pourrait faire <asp:label runat="server" /> c'est pas conseillé mais ca fonctionne :) dans certains cas le framework ou le concepteur de controle peut l'utiliser, du coup si ton controle est contenu dans un de ses controles tu peux rien faire.

Commentaire de jesusonline le 04/07/2006 18:38:07 administrateur CS

la propriété existe mais on est obligé de faire ca pour chaque controle, donc c'est injouable.

Pour ce qui est des ID automatique, à ton avis pourquoi le premier s'appelle ctl00 ;-) il y a un compteur qui va s'incrémenter à chaque fois qu'on l'appelle donc ctl01, etc...

Commentaire de Yopyop le 04/07/2006 18:55:34

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 ;)

Commentaire de Yopyop le 04/07/2006 20:33:12

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

Commentaire de apacheswiss le 04/07/2006 20:46:19

si tu utilise la recursivité, c'est que tu n'as que le nom qui est sur la porte.. mais pas la rue.. donc pour trouver cette porte tu dois te taper toutes les rues

Commentaire de apacheswiss le 04/07/2006 20:55:44

je pense aussi...
moi je voulais juste débatre sur.
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 ;)

qui ne veut pas dire grand chose à part arrêter tout une fois qu'on a trouvé ce qu'on cherche...

Commentaire de apacheswiss le 04/07/2006 21:36:38

désolé......
mais lors d'un return dans ta fonction recursive, tu sort de ta récursivité...
tu tu rappelle ta fonction, c'est récursif...

je ne vois pas ou tu évite...

je suis d'accord avec toi au sujet de l'arbre... si tu cherche d'abord la branche, et ensuite tu parcoours la branche, ce n'est plus récursif.. tu ne fais que 2 boucle.

Commentaire de Yopyop le 04/07/2006 22:00:13

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();
}

Commentaire de apacheswiss le 04/07/2006 22:46:07

je verrais un truc du genre:
ne sais pas si ca fonctionne, pas tester... merci de me dire mes erreurs... j'apprends tjs.


internal static Control getControlFromClientID(Page page, String ClientID)
        {
            _clientID = ClientID;
  
            Control c = page.FindControl(ClientID);
            if (c != null)
                return c;
  
            return getControlFromClientIDInternal(page);
        }
  
        /// <summary>
        /// Obtain a control from a container
        /// </summary>
        /// <param name="Container"></param>
        /// <returns>use recursivity</returns>
        /// <remarks>the _clientID params is extern to not put into stack the value each call : better performance</remarks>
        private static Control getControlFromClientIDInternal(Control Container)
        {
            Control c;
            if (_clientID.Length > Container.ClientID.Length)
            {
foreach (Control child in Container.Controls)
             {
                 if (child.Controls.Count > 0)
                 {
if (_clientID.Contains(child.ClientId)
                     {
    getControlFromClientIDInternal(child);
                       
                     }
}
                }
            }
    elseif(_clientID == Container.ClientID)
    {
return container;
    
            }
    else
    {
           return null;
    }
        }

Commentaire de apacheswiss le 04/07/2006 22:55:56

il doit manquer un return null a la fin du foreach (Control inexistant)

Commentaire de Yopyop le 04/07/2006 23:48:42

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

Commentaire de Yopyop le 06/07/2006 02:28:36

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 ?

Commentaire de Yopyop le 06/07/2006 12:57:45

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

Commentaire de Yopyop le 06/07/2006 13:38:35

oki, donc environs 5000 contrôles...

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

yopyop