Contenu du HttpContext.Current

Encore merci à Calagan99 pour sa réponse sur le sujet.
Maintenant que j'ai récupéré le bousin et que mes variables de session arrivent bien, je me suis dit que je pouvais récupérer le reste de ma page. Mais visiblement je fus bien présomptueux.

Dans l'explication du HttpContext dans la MSDN je vois plein de trucs interressant, mais pas celui que je veux. J'ai vu le Response, le Server, le Request et toutiquanti. Mais je trouve pas la Page, est ce que c'est normal ?

Parce que, en fait, ce que j'aimerais bien faire c'est de pouvoir envoyer le contenu de ma page dans ma classe Externe. Les variables de session, c'est bien, ça me permt de d'avoir des paramettre pour me requête. Mais je pouvais récupérer les contrôle de ma page, genre capter la TextBox machin et lui faire plein de truc dégoutant. Ou alors renvoyer une valeur dans un Label ou une TextBox.

Vu qu'on arrive à envoyer des contrôles dans la page, on doit bien pouvoir les récupérer, surtout si on connait leur ID.

Voyez vous ce que je veux dire ?
Merci pour votre aide.

Bah c'est dans le Response tout ça

C'est sûrement possible, mais de tête ca ne me vient pas.
Par contre, un remarque, si tu utilises de l'objet tu n'as plus ce problème. Car là tu es obligé de passer des controles en parametres de tes classes pour pouvoir faire tes traitements.

En utilisant une approche objet, il te suffirait d'instancier un nouvel objet coté page, d'affecter les valeurs de tes textbox par exemple, aux propriétés publiques de ton objet, et de faire tes traitements dans ta classe avec les données contenues dans ces memes propriétés.

Peut etre que ca vaut le coup d'essayer.

OK, merci à tous les deux, je cherche dans ce sens, enfin dans les deux sens que vous exprimez.

Juste le temps de poster un autre truc, mon chef vient de me poser une colle et j'ai pas trouvé.

Alors j'ai regardé du côté du Response. Je trouve pas le moyen d'interroger un contrôle donné. J'ai pas de FindControl et je vois pas d'autre méthode qui pourrais faire pareil.

Sinon, le coup des propriétés, ouias, empiriquement c'est une super idée. Sauf que, mais bidule est trés dynamaique, donc je ne maitrise pas les contrôles présent dans la page. Et puis l'idée c'était jsutement de ne pas envoyer plein de paramettre. le bidule en question gère une formulaire d'inscription sur les sites, avec 22 informations au total (et encore, on pourra en rajouter en focntion des besoins). Mais l'utilisateur, en focntion du site qu'il gère, peut choisir d'afficher ou pas certaines informations.

J'ai réussi à simplifier le truc en partant d'une <asp:table. Je la pose dan ma page côté HTML et dans le CodeBehind j'appelle la fonction de construction du formulaire dans ma classe Externe.

Ensuite, j'ai une autre fonction qui va gérer l'enregistrement des donnée dans la BDD et je lui repasse la table. A partir de là, je peux faire un matable.findControl et trouver les éléments de mon formulaire. Mais je trouve un peu lourd le faire d'envoyer la table complète, j'ai peur de saturer les ressource du serveur en cas de forte fréquentation du site.

Qu'en pensez vous ?

Response ne contiendra que le buffer envoyé au client.
Tu peux le récupérer sous forme de string mais après c'est à toi de le parser, il n'y a plus de notion de control ou autre

OK, donc, à part envoyer un contrôle qui contient les autres, je n'ai aps vraiment d'autre solution si je veux manipuler tous mes contrôles tranquillou.

Si c'est ça qui faut faire, pas de souci. Mais, que ce soit cete solution ou celle de faire un objet avec plein de propriété, est ce que cela ne risque pas de saturer le serveur ?

Si tu bosses pas sur un Duron 600MHz, devrait pas y avoir de problème :D

OK, merci, je boucle le sujet.

quelle solution retiens tu finalement ?

Un mix de ton idée et de l'envoi d'un contrôle contenant les autres.

Pour le cas qui m'occupe précisément j'envoi ma fameuse <asp:table et je récupère tout ce que je veux dedans. Et je l'envoi en tant que paramettre d'une méthode que j'ai fait dans ma classe externe.

Pour les prochains composants, je verrais l'intérêt et la facilité soit de faire des propriété, soit d'envoyer un contrôle contenant le reste, où seulement ce dont j'ai besoins.

En fait, je préfère éviter de faire des Classes Externe et tenté de faire une maximum de Composants Utilisateurs. Mais certains cas sont compliqués. Là, apr exemple, il fallait que j'insère un formulaire de détail d'un membre dans le CreateWizardUser. Vu que mon composant Utilisateur servait autant àla création qu'à la modification, c'était pas simple. Donc une Classe Extern et hop, j'appelle les méthodes come je veux.

mais bon, je préfère faire un maximum de Coposant Utilisateur car le reste du sytème que j'ai mis en place repose dessus. Il faut savoir, subsidiairement, que j'arrive à gérer autant de site que je veux (au sens DNS du terme) sur une seule et unique page ASPX. Tout le reste se fait par appel de la base avec un paramettre en QueryString qui permet de savoir quel Coposant il faut mettre dans quel trou de la MAsterPage, cette dernière étant totalement dynamaique en fonction du DNS et/ou de l'utilisateur connecté.
Bref, je crois que j'ai attient la limite de souplesse de ce que peut permetre .NET.

Et je suis trop content......

ca doit quand meme etre bien gourmand une page faite uniquement de composants utilisateurs...
Je ne connais que trés peu cette techno, a vrai dire je crois n'en avoir jamais codé.
Et plus j'avance, plus je vois l'interet d'une programmation objet. C'est certes moins reutilisable, mais le vitesse de développement est sans commune mesure avec le bon vieux procédural...

Citation:

---

Envoyé par calagan99

. C'est certes moins reutilisable,

---

Non, ce l'est beaucoup plus justement.

Citation:

---

Envoyé par calagan99

Et plus j'avance, plus je vois l'interet d'une programmation objet. C'est certes moins reutilisable, mais le vitesse de développement est sans commune mesure avec le bon vieux procédural...

---

L'un des grands principes de la POO est la réutilisabiltié du code 8O

Entièrement d'accord avec LuteceFalco, la POO permet une réutilisation à outrance, s'en est presque indescent, autant de facilité.

Mais, dans mon cas, c'est pas toujours ce qu'il y a de mieux.
Parce que, mon petit secret, c'est mettre dans mon Web.Config tous mes Coposant Utilisteur. Ensuite, dans ma base de donnée, je stocke leur nom sous forme de chaine et dans ma page je remonte une chaine de caractère qui va appeller directement le composant et l'ajouter à un ContentPlaceHolder (par exemple)

Ca fait un truc dans ce gout là :

Code:

---

1 2 3 4

compo = "<CompoSite:" & r.Item("Nom_Compo") & " ID='" & r.Item("Id_Compo") & "' " compo &= "runat='server' />" ctrl = ParseControl(compo)

---

Et puis entre les deux je peux ajouter des options selon les éventuelles propriétés que j'ai rajouter dans le composant.

Donc, je dois jongler entre pur objet et comosant. Et donc, faut je manoeuvre délicatement pour la récupération des contrôles de base (genre TextBox ou DropDownList) et leur manipulation.