Bonjour,
je viens d'isoler un problème dans le framework que j'utilise dans une
application.
Nous utilisons une méthode de transfert permettant de passer des
paramètres d'une page a l'autre, cette méthode repose sur
HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
Quand je passe d'une page a l'autre je récupère bien mes paramètres,
pas de problème a ce niveau...
Mon problème survient lorsque j'arrive sur une page par le biais d'un
Server.Transfer, je modifie (affectation) alors des propriétés stockées
dans le viewstate (après le oninit et avant le render), mais lors d'un
postback occasionné par un bouton (par exemple), mon viewstate est
complètement vide.
Avez vous connaissance de ce problème? (bug d'ASP.NET?)
Connaissez vous un moyen de le contourner/corriger?
Je me suis toujours méfié du ViewState mais je suis dans l'obligation
d'utiliser le framework existant utilisant le Server.Transfer et le
passage de paramètres pour le développement de mon application. Un
nombre consequent de pages stockent leur propriétés dans le viewstate
mais celle ci ne sont pas utilisable après un Server.Transfer.
Merci pour votre aide.
Gauthier Segay
Bonjour,
je viens d'isoler un problème dans le framework que j'utilise dans une
application.
Nous utilisons une méthode de transfert permettant de passer des
paramètres d'une page a l'autre, cette méthode repose sur
HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
Quand je passe d'une page a l'autre je récupère bien mes paramètres,
pas de problème a ce niveau...
Mon problème survient lorsque j'arrive sur une page par le biais d'un
Server.Transfer, je modifie (affectation) alors des propriétés stockées
dans le viewstate (après le oninit et avant le render), mais lors d'un
postback occasionné par un bouton (par exemple), mon viewstate est
complètement vide.
Avez vous connaissance de ce problème? (bug d'ASP.NET?)
Connaissez vous un moyen de le contourner/corriger?
Je me suis toujours méfié du ViewState mais je suis dans l'obligation
d'utiliser le framework existant utilisant le Server.Transfer et le
passage de paramètres pour le développement de mon application. Un
nombre consequent de pages stockent leur propriétés dans le viewstate
mais celle ci ne sont pas utilisable après un Server.Transfer.
Merci pour votre aide.
Gauthier Segay
Bonjour,
je viens d'isoler un problème dans le framework que j'utilise dans une
application.
Nous utilisons une méthode de transfert permettant de passer des
paramètres d'une page a l'autre, cette méthode repose sur
HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
Quand je passe d'une page a l'autre je récupère bien mes paramètres,
pas de problème a ce niveau...
Mon problème survient lorsque j'arrive sur une page par le biais d'un
Server.Transfer, je modifie (affectation) alors des propriétés stockées
dans le viewstate (après le oninit et avant le render), mais lors d'un
postback occasionné par un bouton (par exemple), mon viewstate est
complètement vide.
Avez vous connaissance de ce problème? (bug d'ASP.NET?)
Connaissez vous un moyen de le contourner/corriger?
Je me suis toujours méfié du ViewState mais je suis dans l'obligation
d'utiliser le framework existant utilisant le Server.Transfer et le
passage de paramètres pour le développement de mon application. Un
nombre consequent de pages stockent leur propriétés dans le viewstate
mais celle ci ne sont pas utilisable après un Server.Transfer.
Merci pour votre aide.
Gauthier Segay
le viewstate étant un champ caché dans la source html d'une page, il
n'appartient qu'a cette page. en fesant un server.transfer il est
tout à fait normal que le viewstate de la nouvelle page soit vide.
Avez-vous penser au variables session?
"Gauthier Segay" a écrit dans le message de
news: %23r%
> Bonjour,
>
> je viens d'isoler un problème dans le framework que j'utilise dans
> une application.
>
> Nous utilisons une méthode de transfert permettant de passer des
> paramètres d'une page a l'autre, cette méthode repose sur
> HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
>
> Quand je passe d'une page a l'autre je récupère bien mes paramètres,
> pas de problème a ce niveau...
>
> Mon problème survient lorsque j'arrive sur une page par le biais
> d'un Server.Transfer, je modifie (affectation) alors des propriétés
> stockées dans le viewstate (après le oninit et avant le render),
> mais lors d'un postback occasionné par un bouton (par exemple), mon
> viewstate est complètement vide.
>
> Avez vous connaissance de ce problème? (bug d'ASP.NET?)
>
> Connaissez vous un moyen de le contourner/corriger?
>
> Je me suis toujours méfié du ViewState mais je suis dans
> l'obligation d'utiliser le framework existant utilisant le
> Server.Transfer et le passage de paramètres pour le développement
> de mon application. Un nombre consequent de pages stockent leur
> propriétés dans le viewstate mais celle ci ne sont pas utilisable
> après un Server.Transfer.
>
> Merci pour votre aide.
>
> Gauthier Segay
le viewstate étant un champ caché dans la source html d'une page, il
n'appartient qu'a cette page. en fesant un server.transfer il est
tout à fait normal que le viewstate de la nouvelle page soit vide.
Avez-vous penser au variables session?
"Gauthier Segay" <gauthier@spammed.org> a écrit dans le message de
news: %23r%23XI4PnFHA.1044@tk2msftngp13.phx.gbl...
> Bonjour,
>
> je viens d'isoler un problème dans le framework que j'utilise dans
> une application.
>
> Nous utilisons une méthode de transfert permettant de passer des
> paramètres d'une page a l'autre, cette méthode repose sur
> HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
>
> Quand je passe d'une page a l'autre je récupère bien mes paramètres,
> pas de problème a ce niveau...
>
> Mon problème survient lorsque j'arrive sur une page par le biais
> d'un Server.Transfer, je modifie (affectation) alors des propriétés
> stockées dans le viewstate (après le oninit et avant le render),
> mais lors d'un postback occasionné par un bouton (par exemple), mon
> viewstate est complètement vide.
>
> Avez vous connaissance de ce problème? (bug d'ASP.NET?)
>
> Connaissez vous un moyen de le contourner/corriger?
>
> Je me suis toujours méfié du ViewState mais je suis dans
> l'obligation d'utiliser le framework existant utilisant le
> Server.Transfer et le passage de paramètres pour le développement
> de mon application. Un nombre consequent de pages stockent leur
> propriétés dans le viewstate mais celle ci ne sont pas utilisable
> après un Server.Transfer.
>
> Merci pour votre aide.
>
> Gauthier Segay
le viewstate étant un champ caché dans la source html d'une page, il
n'appartient qu'a cette page. en fesant un server.transfer il est
tout à fait normal que le viewstate de la nouvelle page soit vide.
Avez-vous penser au variables session?
"Gauthier Segay" a écrit dans le message de
news: %23r%
> Bonjour,
>
> je viens d'isoler un problème dans le framework que j'utilise dans
> une application.
>
> Nous utilisons une méthode de transfert permettant de passer des
> paramètres d'une page a l'autre, cette méthode repose sur
> HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
>
> Quand je passe d'une page a l'autre je récupère bien mes paramètres,
> pas de problème a ce niveau...
>
> Mon problème survient lorsque j'arrive sur une page par le biais
> d'un Server.Transfer, je modifie (affectation) alors des propriétés
> stockées dans le viewstate (après le oninit et avant le render),
> mais lors d'un postback occasionné par un bouton (par exemple), mon
> viewstate est complètement vide.
>
> Avez vous connaissance de ce problème? (bug d'ASP.NET?)
>
> Connaissez vous un moyen de le contourner/corriger?
>
> Je me suis toujours méfié du ViewState mais je suis dans
> l'obligation d'utiliser le framework existant utilisant le
> Server.Transfer et le passage de paramètres pour le développement
> de mon application. Un nombre consequent de pages stockent leur
> propriétés dans le viewstate mais celle ci ne sont pas utilisable
> après un Server.Transfer.
>
> Merci pour votre aide.
>
> Gauthier Segay
Norm wrote:
> le viewstate étant un champ caché dans la source html d'une page, il
> n'appartient qu'a cette page. en fesant un server.transfer il est
> tout à fait normal que le viewstate de la nouvelle page soit vide.
> Avez-vous penser au variables session?
>
> "Gauthier Segay" a écrit dans le message de
> news: %23r%
> > Bonjour,
> >
> > je viens d'isoler un problème dans le framework que j'utilise dans
> > une application.
> >
> > Nous utilisons une méthode de transfert permettant de passer des
> > paramètres d'une page a l'autre, cette méthode repose sur
> > HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
> >
> > Quand je passe d'une page a l'autre je récupère bien mes paramètres,
> > pas de problème a ce niveau...
> >
> > Mon problème survient lorsque j'arrive sur une page par le biais
> > d'un Server.Transfer, je modifie (affectation) alors des propriétés
> > stockées dans le viewstate (après le oninit et avant le render),
> > mais lors d'un postback occasionné par un bouton (par exemple), mon
> > viewstate est complètement vide.
> >
> > Avez vous connaissance de ce problème? (bug d'ASP.NET?)
> >
> > Connaissez vous un moyen de le contourner/corriger?
> >
> > Je me suis toujours méfié du ViewState mais je suis dans
> > l'obligation d'utiliser le framework existant utilisant le
> > Server.Transfer et le passage de paramètres pour le développement
> > de mon application. Un nombre consequent de pages stockent leur
> > propriétés dans le viewstate mais celle ci ne sont pas utilisable
> > après un Server.Transfer.
> >
> > Merci pour votre aide.
> >
> > Gauthier Segay
Merci pour la précision sur le medium de persitance du viewstate (input
hidden encodé en base64...) et sur le fait qu'il ne soit dédié qu'au
stockage d'information entre 2 postback sur la même page, je suis bien
conscient de ces points; mais cela ne répond pas à ma question.
Je précise (dans le cas ou ce ne serait pas clair dans ma courte
description) que mon cas se produit sur un postback subsquent au
Server.Transfer, je ne cherche bien entendu pas a obtenir des valeurs
du ViewState dans ma page de destination, je les affecte après le
Server.Transfer, et cherche a les obtenir sur le postback suivant mais
le ViewState ne contient alors plus rien.
Un petit scenario d'exemple vaut beacoup mieux :)
========8<============8<=========== > Page1:
[STEP1] Page_Init...Page_Load...Page_Render... l'utilisateur clique sur
Btn1
[STEP2] Page_Init...Btn1_Click...Server.Transfer
Page2:
[STEP3] Page_Init...Page_Load...Page_Render... l'utilisateur clique sur
Btn1
[STEP4] Page_Init...Btn1_Click... plus rien dans le ViewState
click sur button1 -> Server.Transfer vers Page1
========8<============8<=========== >
Clairement, si j'affecte quoi que ce soit dans le viewstate dans le
step3, je n'ai plus rien dans le step4, et ce sans avoir changé de page
entre step3 et step4.
A mes yeux, cela est un bug d'ASP.NET.
Comment y remedier?
Quand a la solution de stocker les valeurs en session, ce sera vraiment
en dernier recours si le bug n'est pas contournable autrement,
principalement car cela souleve pas mal de problème (performances et
load-balancing, a quel moment supprimer les informations...).
Merci pour votre aide,
Gauthier Segay
Norm wrote:
> le viewstate étant un champ caché dans la source html d'une page, il
> n'appartient qu'a cette page. en fesant un server.transfer il est
> tout à fait normal que le viewstate de la nouvelle page soit vide.
> Avez-vous penser au variables session?
>
> "Gauthier Segay" <gauthier@spammed.org> a écrit dans le message de
> news: %23r%23XI4PnFHA.1044@tk2msftngp13.phx.gbl...
> > Bonjour,
> >
> > je viens d'isoler un problème dans le framework que j'utilise dans
> > une application.
> >
> > Nous utilisons une méthode de transfert permettant de passer des
> > paramètres d'une page a l'autre, cette méthode repose sur
> > HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
> >
> > Quand je passe d'une page a l'autre je récupère bien mes paramètres,
> > pas de problème a ce niveau...
> >
> > Mon problème survient lorsque j'arrive sur une page par le biais
> > d'un Server.Transfer, je modifie (affectation) alors des propriétés
> > stockées dans le viewstate (après le oninit et avant le render),
> > mais lors d'un postback occasionné par un bouton (par exemple), mon
> > viewstate est complètement vide.
> >
> > Avez vous connaissance de ce problème? (bug d'ASP.NET?)
> >
> > Connaissez vous un moyen de le contourner/corriger?
> >
> > Je me suis toujours méfié du ViewState mais je suis dans
> > l'obligation d'utiliser le framework existant utilisant le
> > Server.Transfer et le passage de paramètres pour le développement
> > de mon application. Un nombre consequent de pages stockent leur
> > propriétés dans le viewstate mais celle ci ne sont pas utilisable
> > après un Server.Transfer.
> >
> > Merci pour votre aide.
> >
> > Gauthier Segay
Merci pour la précision sur le medium de persitance du viewstate (input
hidden encodé en base64...) et sur le fait qu'il ne soit dédié qu'au
stockage d'information entre 2 postback sur la même page, je suis bien
conscient de ces points; mais cela ne répond pas à ma question.
Je précise (dans le cas ou ce ne serait pas clair dans ma courte
description) que mon cas se produit sur un postback subsquent au
Server.Transfer, je ne cherche bien entendu pas a obtenir des valeurs
du ViewState dans ma page de destination, je les affecte après le
Server.Transfer, et cherche a les obtenir sur le postback suivant mais
le ViewState ne contient alors plus rien.
Un petit scenario d'exemple vaut beacoup mieux :)
========8<============8<=========== > Page1:
[STEP1] Page_Init...Page_Load...Page_Render... l'utilisateur clique sur
Btn1
[STEP2] Page_Init...Btn1_Click...Server.Transfer
Page2:
[STEP3] Page_Init...Page_Load...Page_Render... l'utilisateur clique sur
Btn1
[STEP4] Page_Init...Btn1_Click... plus rien dans le ViewState
click sur button1 -> Server.Transfer vers Page1
========8<============8<=========== >
Clairement, si j'affecte quoi que ce soit dans le viewstate dans le
step3, je n'ai plus rien dans le step4, et ce sans avoir changé de page
entre step3 et step4.
A mes yeux, cela est un bug d'ASP.NET.
Comment y remedier?
Quand a la solution de stocker les valeurs en session, ce sera vraiment
en dernier recours si le bug n'est pas contournable autrement,
principalement car cela souleve pas mal de problème (performances et
load-balancing, a quel moment supprimer les informations...).
Merci pour votre aide,
Gauthier Segay
Norm wrote:
> le viewstate étant un champ caché dans la source html d'une page, il
> n'appartient qu'a cette page. en fesant un server.transfer il est
> tout à fait normal que le viewstate de la nouvelle page soit vide.
> Avez-vous penser au variables session?
>
> "Gauthier Segay" a écrit dans le message de
> news: %23r%
> > Bonjour,
> >
> > je viens d'isoler un problème dans le framework que j'utilise dans
> > une application.
> >
> > Nous utilisons une méthode de transfert permettant de passer des
> > paramètres d'une page a l'autre, cette méthode repose sur
> > HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
> >
> > Quand je passe d'une page a l'autre je récupère bien mes paramètres,
> > pas de problème a ce niveau...
> >
> > Mon problème survient lorsque j'arrive sur une page par le biais
> > d'un Server.Transfer, je modifie (affectation) alors des propriétés
> > stockées dans le viewstate (après le oninit et avant le render),
> > mais lors d'un postback occasionné par un bouton (par exemple), mon
> > viewstate est complètement vide.
> >
> > Avez vous connaissance de ce problème? (bug d'ASP.NET?)
> >
> > Connaissez vous un moyen de le contourner/corriger?
> >
> > Je me suis toujours méfié du ViewState mais je suis dans
> > l'obligation d'utiliser le framework existant utilisant le
> > Server.Transfer et le passage de paramètres pour le développement
> > de mon application. Un nombre consequent de pages stockent leur
> > propriétés dans le viewstate mais celle ci ne sont pas utilisable
> > après un Server.Transfer.
> >
> > Merci pour votre aide.
> >
> > Gauthier Segay
Merci pour la précision sur le medium de persitance du viewstate (input
hidden encodé en base64...) et sur le fait qu'il ne soit dédié qu'au
stockage d'information entre 2 postback sur la même page, je suis bien
conscient de ces points; mais cela ne répond pas à ma question.
Je précise (dans le cas ou ce ne serait pas clair dans ma courte
description) que mon cas se produit sur un postback subsquent au
Server.Transfer, je ne cherche bien entendu pas a obtenir des valeurs
du ViewState dans ma page de destination, je les affecte après le
Server.Transfer, et cherche a les obtenir sur le postback suivant mais
le ViewState ne contient alors plus rien.
Un petit scenario d'exemple vaut beacoup mieux :)
========8<============8<=========== > Page1:
[STEP1] Page_Init...Page_Load...Page_Render... l'utilisateur clique sur
Btn1
[STEP2] Page_Init...Btn1_Click...Server.Transfer
Page2:
[STEP3] Page_Init...Page_Load...Page_Render... l'utilisateur clique sur
Btn1
[STEP4] Page_Init...Btn1_Click... plus rien dans le ViewState
click sur button1 -> Server.Transfer vers Page1
========8<============8<=========== >
Clairement, si j'affecte quoi que ce soit dans le viewstate dans le
step3, je n'ai plus rien dans le step4, et ce sans avoir changé de page
entre step3 et step4.
A mes yeux, cela est un bug d'ASP.NET.
Comment y remedier?
Quand a la solution de stocker les valeurs en session, ce sera vraiment
en dernier recours si le bug n'est pas contournable autrement,
principalement car cela souleve pas mal de problème (performances et
load-balancing, a quel moment supprimer les informations...).
Merci pour votre aide,
Gauthier Segay
"Gauthier Segay" wrote in message
news:#
> Norm wrote:
>
> > le viewstate étant un champ caché dans la source html d'une page,
> > il n'appartient qu'a cette page. en fesant un server.transfer il
> > est tout à fait normal que le viewstate de la nouvelle page soit
> > vide. Avez-vous penser au variables session?
> >
> > "Gauthier Segay" a écrit dans le message de
> > news: %23r%
> > > Bonjour,
> > >
> > > je viens d'isoler un problème dans le framework que j'utilise
> > > dans une application.
> > >
> > > Nous utilisons une méthode de transfert permettant de passer des
> > > paramètres d'une page a l'autre, cette méthode repose sur
> > > HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
> > >
> > > Quand je passe d'une page a l'autre je récupère bien mes
> > > paramètres, pas de problème a ce niveau...
> > >
> > > Mon problème survient lorsque j'arrive sur une page par le biais
> > > d'un Server.Transfer, je modifie (affectation) alors des
> > > propriétés stockées dans le viewstate (après le oninit et avant
> > > le render), mais lors d'un postback occasionné par un bouton
> > > (par exemple), mon viewstate est complètement vide.
> > >
> > > Avez vous connaissance de ce problème? (bug d'ASP.NET?)
> > >
> > > Connaissez vous un moyen de le contourner/corriger?
> > >
> > > Je me suis toujours méfié du ViewState mais je suis dans
> > > l'obligation d'utiliser le framework existant utilisant le
> > > Server.Transfer et le passage de paramètres pour le
> > > développement de mon application. Un nombre consequent de pages
> > > stockent leur propriétés dans le viewstate mais celle ci ne
> > > sont pas utilisable après un Server.Transfer.
> > >
> > > Merci pour votre aide.
> > >
> > > Gauthier Segay
>
> Merci pour la précision sur le medium de persitance du viewstate
> (input hidden encodé en base64...) et sur le fait qu'il ne soit
> dédié qu'au stockage d'information entre 2 postback sur la même
> page, je suis bien conscient de ces points; mais cela ne répond pas
> à ma question.
>
> Je précise (dans le cas ou ce ne serait pas clair dans ma courte
> description) que mon cas se produit sur un postback subsquent au
> Server.Transfer, je ne cherche bien entendu pas a obtenir des
> valeurs du ViewState dans ma page de destination, je les affecte
> après le Server.Transfer, et cherche a les obtenir sur le postback
> suivant mais le ViewState ne contient alors plus rien.
>
> Un petit scenario d'exemple vaut beacoup mieux :)
> ========8<============8<=========== > > Page1:
> [STEP1] Page_Init...Page_Load...Page_Render... l'utilisateur clique
> sur Btn1
> [STEP2] Page_Init...Btn1_Click...Server.Transfer
>
> Page2:
> [STEP3] Page_Init...Page_Load...Page_Render... l'utilisateur clique
> sur Btn1
> [STEP4] Page_Init...Btn1_Click... plus rien dans le ViewState
> click sur button1 -> Server.Transfer vers Page1
> ========8<============8<=========== > >
> Clairement, si j'affecte quoi que ce soit dans le viewstate dans le
> step3, je n'ai plus rien dans le step4, et ce sans avoir changé de
> page entre step3 et step4.
>
Avez-vous vérifié que vous ne modifiez pas la structure de la page2
entre le rendering de l'étape 3 et le traitement des évènement de
l'étape 4 ?
Ne lisez-vous pas trop tôt dans le cycle de vie de la page à l'étape
4 pour avoir accès au ViewStates ?
> A mes yeux, cela est un bug d'ASP.NET.
>
Avant de dire que c'est un problème ASP.NET, je pense qu'il faut
faire un peu plus de recherche ;-).
> Comment y remedier?
>
> Quand a la solution de stocker les valeurs en session, ce sera
> vraiment en dernier recours si le bug n'est pas contournable
> autrement, principalement car cela souleve pas mal de problème
> (performances et
C'est à vérifier en situation et pas avant. Le Design doit permet de
l'utiliser ou non en fonction des goulots d'étranglement détecté sur
la plate-forme de dimensionnement.
> load-balancing, a quel moment supprimer les informations...).
Il y a des mode de gestion des variables de sessions qui sont
parfaitement load-balancing aware (mode service ou mode SQL par
exemple) Supprimer les informations de session à la fin d'une session
me semble logique, que cette fin soit volontaire via un bouton de
déconnection ou involontaire via un timeout configurable d'ASP.NET.
>
> Merci pour votre aide,
>
> Gauthier Segay
"Gauthier Segay" <gauthier@spammed.org> wrote in message
news:#Sn7cHUnFHA.1148@TK2MSFTNGP12.phx.gbl...
> Norm wrote:
>
> > le viewstate étant un champ caché dans la source html d'une page,
> > il n'appartient qu'a cette page. en fesant un server.transfer il
> > est tout à fait normal que le viewstate de la nouvelle page soit
> > vide. Avez-vous penser au variables session?
> >
> > "Gauthier Segay" <gauthier@spammed.org> a écrit dans le message de
> > news: %23r%23XI4PnFHA.1044@tk2msftngp13.phx.gbl...
> > > Bonjour,
> > >
> > > je viens d'isoler un problème dans le framework que j'utilise
> > > dans une application.
> > >
> > > Nous utilisons une méthode de transfert permettant de passer des
> > > paramètres d'une page a l'autre, cette méthode repose sur
> > > HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
> > >
> > > Quand je passe d'une page a l'autre je récupère bien mes
> > > paramètres, pas de problème a ce niveau...
> > >
> > > Mon problème survient lorsque j'arrive sur une page par le biais
> > > d'un Server.Transfer, je modifie (affectation) alors des
> > > propriétés stockées dans le viewstate (après le oninit et avant
> > > le render), mais lors d'un postback occasionné par un bouton
> > > (par exemple), mon viewstate est complètement vide.
> > >
> > > Avez vous connaissance de ce problème? (bug d'ASP.NET?)
> > >
> > > Connaissez vous un moyen de le contourner/corriger?
> > >
> > > Je me suis toujours méfié du ViewState mais je suis dans
> > > l'obligation d'utiliser le framework existant utilisant le
> > > Server.Transfer et le passage de paramètres pour le
> > > développement de mon application. Un nombre consequent de pages
> > > stockent leur propriétés dans le viewstate mais celle ci ne
> > > sont pas utilisable après un Server.Transfer.
> > >
> > > Merci pour votre aide.
> > >
> > > Gauthier Segay
>
> Merci pour la précision sur le medium de persitance du viewstate
> (input hidden encodé en base64...) et sur le fait qu'il ne soit
> dédié qu'au stockage d'information entre 2 postback sur la même
> page, je suis bien conscient de ces points; mais cela ne répond pas
> à ma question.
>
> Je précise (dans le cas ou ce ne serait pas clair dans ma courte
> description) que mon cas se produit sur un postback subsquent au
> Server.Transfer, je ne cherche bien entendu pas a obtenir des
> valeurs du ViewState dans ma page de destination, je les affecte
> après le Server.Transfer, et cherche a les obtenir sur le postback
> suivant mais le ViewState ne contient alors plus rien.
>
> Un petit scenario d'exemple vaut beacoup mieux :)
> ========8<============8<=========== > > Page1:
> [STEP1] Page_Init...Page_Load...Page_Render... l'utilisateur clique
> sur Btn1
> [STEP2] Page_Init...Btn1_Click...Server.Transfer
>
> Page2:
> [STEP3] Page_Init...Page_Load...Page_Render... l'utilisateur clique
> sur Btn1
> [STEP4] Page_Init...Btn1_Click... plus rien dans le ViewState
> click sur button1 -> Server.Transfer vers Page1
> ========8<============8<=========== > >
> Clairement, si j'affecte quoi que ce soit dans le viewstate dans le
> step3, je n'ai plus rien dans le step4, et ce sans avoir changé de
> page entre step3 et step4.
>
Avez-vous vérifié que vous ne modifiez pas la structure de la page2
entre le rendering de l'étape 3 et le traitement des évènement de
l'étape 4 ?
Ne lisez-vous pas trop tôt dans le cycle de vie de la page à l'étape
4 pour avoir accès au ViewStates ?
> A mes yeux, cela est un bug d'ASP.NET.
>
Avant de dire que c'est un problème ASP.NET, je pense qu'il faut
faire un peu plus de recherche ;-).
> Comment y remedier?
>
> Quand a la solution de stocker les valeurs en session, ce sera
> vraiment en dernier recours si le bug n'est pas contournable
> autrement, principalement car cela souleve pas mal de problème
> (performances et
C'est à vérifier en situation et pas avant. Le Design doit permet de
l'utiliser ou non en fonction des goulots d'étranglement détecté sur
la plate-forme de dimensionnement.
> load-balancing, a quel moment supprimer les informations...).
Il y a des mode de gestion des variables de sessions qui sont
parfaitement load-balancing aware (mode service ou mode SQL par
exemple) Supprimer les informations de session à la fin d'une session
me semble logique, que cette fin soit volontaire via un bouton de
déconnection ou involontaire via un timeout configurable d'ASP.NET.
>
> Merci pour votre aide,
>
> Gauthier Segay
"Gauthier Segay" wrote in message
news:#
> Norm wrote:
>
> > le viewstate étant un champ caché dans la source html d'une page,
> > il n'appartient qu'a cette page. en fesant un server.transfer il
> > est tout à fait normal que le viewstate de la nouvelle page soit
> > vide. Avez-vous penser au variables session?
> >
> > "Gauthier Segay" a écrit dans le message de
> > news: %23r%
> > > Bonjour,
> > >
> > > je viens d'isoler un problème dans le framework que j'utilise
> > > dans une application.
> > >
> > > Nous utilisons une méthode de transfert permettant de passer des
> > > paramètres d'une page a l'autre, cette méthode repose sur
> > > HttpServer.Transfer et sur le dictionnaire HttpContext.Items.
> > >
> > > Quand je passe d'une page a l'autre je récupère bien mes
> > > paramètres, pas de problème a ce niveau...
> > >
> > > Mon problème survient lorsque j'arrive sur une page par le biais
> > > d'un Server.Transfer, je modifie (affectation) alors des
> > > propriétés stockées dans le viewstate (après le oninit et avant
> > > le render), mais lors d'un postback occasionné par un bouton
> > > (par exemple), mon viewstate est complètement vide.
> > >
> > > Avez vous connaissance de ce problème? (bug d'ASP.NET?)
> > >
> > > Connaissez vous un moyen de le contourner/corriger?
> > >
> > > Je me suis toujours méfié du ViewState mais je suis dans
> > > l'obligation d'utiliser le framework existant utilisant le
> > > Server.Transfer et le passage de paramètres pour le
> > > développement de mon application. Un nombre consequent de pages
> > > stockent leur propriétés dans le viewstate mais celle ci ne
> > > sont pas utilisable après un Server.Transfer.
> > >
> > > Merci pour votre aide.
> > >
> > > Gauthier Segay
>
> Merci pour la précision sur le medium de persitance du viewstate
> (input hidden encodé en base64...) et sur le fait qu'il ne soit
> dédié qu'au stockage d'information entre 2 postback sur la même
> page, je suis bien conscient de ces points; mais cela ne répond pas
> à ma question.
>
> Je précise (dans le cas ou ce ne serait pas clair dans ma courte
> description) que mon cas se produit sur un postback subsquent au
> Server.Transfer, je ne cherche bien entendu pas a obtenir des
> valeurs du ViewState dans ma page de destination, je les affecte
> après le Server.Transfer, et cherche a les obtenir sur le postback
> suivant mais le ViewState ne contient alors plus rien.
>
> Un petit scenario d'exemple vaut beacoup mieux :)
> ========8<============8<=========== > > Page1:
> [STEP1] Page_Init...Page_Load...Page_Render... l'utilisateur clique
> sur Btn1
> [STEP2] Page_Init...Btn1_Click...Server.Transfer
>
> Page2:
> [STEP3] Page_Init...Page_Load...Page_Render... l'utilisateur clique
> sur Btn1
> [STEP4] Page_Init...Btn1_Click... plus rien dans le ViewState
> click sur button1 -> Server.Transfer vers Page1
> ========8<============8<=========== > >
> Clairement, si j'affecte quoi que ce soit dans le viewstate dans le
> step3, je n'ai plus rien dans le step4, et ce sans avoir changé de
> page entre step3 et step4.
>
Avez-vous vérifié que vous ne modifiez pas la structure de la page2
entre le rendering de l'étape 3 et le traitement des évènement de
l'étape 4 ?
Ne lisez-vous pas trop tôt dans le cycle de vie de la page à l'étape
4 pour avoir accès au ViewStates ?
> A mes yeux, cela est un bug d'ASP.NET.
>
Avant de dire que c'est un problème ASP.NET, je pense qu'il faut
faire un peu plus de recherche ;-).
> Comment y remedier?
>
> Quand a la solution de stocker les valeurs en session, ce sera
> vraiment en dernier recours si le bug n'est pas contournable
> autrement, principalement car cela souleve pas mal de problème
> (performances et
C'est à vérifier en situation et pas avant. Le Design doit permet de
l'utiliser ou non en fonction des goulots d'étranglement détecté sur
la plate-forme de dimensionnement.
> load-balancing, a quel moment supprimer les informations...).
Il y a des mode de gestion des variables de sessions qui sont
parfaitement load-balancing aware (mode service ou mode SQL par
exemple) Supprimer les informations de session à la fin d'une session
me semble logique, que cette fin soit volontaire via un bouton de
déconnection ou involontaire via un timeout configurable d'ASP.NET.
>
> Merci pour votre aide,
>
> Gauthier Segay
