> A priori :
- si la deuxième fenêtre est ouverte à partir de l'instance existante
c'est la même session
- si la deuxième fenêtre est ouverte en double cliquant sur l'icône d'IE,
sera une nouvelle instance d'IE et une nouvelle session
Difficile à dire sans le contexte exact, mais si les utilisateurs ont
de se connecter en même temps sous des comptes différents, j'aurais
à voir si cela ne serait pas à intégrer dans l'application. Dans les
messageries, il est généralement possible de donner des droitds à d'autre
utilisateurs sur une boîte pour qu'ils puissent agir au nom d'un
utilisateur. A priori ils peuvent faire cela sans se
déconnecter/reconnecter.
> A priori :
- si la deuxième fenêtre est ouverte à partir de l'instance existante
c'est la même session
- si la deuxième fenêtre est ouverte en double cliquant sur l'icône d'IE,
sera une nouvelle instance d'IE et une nouvelle session
Difficile à dire sans le contexte exact, mais si les utilisateurs ont
de se connecter en même temps sous des comptes différents, j'aurais
à voir si cela ne serait pas à intégrer dans l'application. Dans les
messageries, il est généralement possible de donner des droitds à d'autre
utilisateurs sur une boîte pour qu'ils puissent agir au nom d'un
utilisateur. A priori ils peuvent faire cela sans se
déconnecter/reconnecter.
> A priori :
- si la deuxième fenêtre est ouverte à partir de l'instance existante
c'est la même session
- si la deuxième fenêtre est ouverte en double cliquant sur l'icône d'IE,
sera une nouvelle instance d'IE et une nouvelle session
Difficile à dire sans le contexte exact, mais si les utilisateurs ont
de se connecter en même temps sous des comptes différents, j'aurais
à voir si cela ne serait pas à intégrer dans l'application. Dans les
messageries, il est généralement possible de donner des droitds à d'autre
utilisateurs sur une boîte pour qu'ils puissent agir au nom d'un
utilisateur. A priori ils peuvent faire cela sans se
déconnecter/reconnecter.
À ce que je sache il est impossible d'être certain qu'une nouvelle fenêtre
sera dans la même session ou non. Avant IE 5.5 il y avait une
possible à cet effet: lancer les nouvelles fenêtre dans le même "process"
(désolé, je ne me souviens pas de la dernière fois où j'ai utilisé Windows
en français). Nous pouvions ainsi garantir que les sessions étaient
utilisées dans toutes les fenêtres. Depuis IE 5.5 Windows décide si les
fenêtre sont lancées dans le même process ou non (selon les ressources
disponibles si je ne m'abuse).
À ce que je sache il est impossible d'être certain qu'une nouvelle fenêtre
sera dans la même session ou non. Avant IE 5.5 il y avait une
possible à cet effet: lancer les nouvelles fenêtre dans le même "process"
(désolé, je ne me souviens pas de la dernière fois où j'ai utilisé Windows
en français). Nous pouvions ainsi garantir que les sessions étaient
utilisées dans toutes les fenêtres. Depuis IE 5.5 Windows décide si les
fenêtre sont lancées dans le même process ou non (selon les ressources
disponibles si je ne m'abuse).
À ce que je sache il est impossible d'être certain qu'une nouvelle fenêtre
sera dans la même session ou non. Avant IE 5.5 il y avait une
possible à cet effet: lancer les nouvelles fenêtre dans le même "process"
(désolé, je ne me souviens pas de la dernière fois où j'ai utilisé Windows
en français). Nous pouvions ainsi garantir que les sessions étaient
utilisées dans toutes les fenêtres. Depuis IE 5.5 Windows décide si les
fenêtre sont lancées dans le même process ou non (selon les ressources
disponibles si je ne m'abuse).
les utilisateurs utilisent un seul et meme compte.
les utilisateurs utilisent un seul et meme compte.
les utilisateurs utilisent un seul et meme compte.
> Si ils utilisent un seul et même compte dans deux fenêtres différentes,
est le problème posé par le fait que la session est la même dans les deux
fenêtres ?
Je ne vois guère comme problème que d'utiliser un même nom pour deux usages
différents. Par exemple si on met en cache les données toujours sous le
nom "MesDonnéesEnCache" cela posera problème. Par contre si l'on utilise
"Annuaire" d'une part et "Pays" d'autre part, les deux pages utiliseront
chacune la donnée en cache qui l'intéresse sans se marcher sur les pieds
> Si ils utilisent un seul et même compte dans deux fenêtres différentes,
est le problème posé par le fait que la session est la même dans les deux
fenêtres ?
Je ne vois guère comme problème que d'utiliser un même nom pour deux usages
différents. Par exemple si on met en cache les données toujours sous le
nom "MesDonnéesEnCache" cela posera problème. Par contre si l'on utilise
"Annuaire" d'une part et "Pays" d'autre part, les deux pages utiliseront
chacune la donnée en cache qui l'intéresse sans se marcher sur les pieds
> Si ils utilisent un seul et même compte dans deux fenêtres différentes,
est le problème posé par le fait que la session est la même dans les deux
fenêtres ?
Je ne vois guère comme problème que d'utiliser un même nom pour deux usages
différents. Par exemple si on met en cache les données toujours sous le
nom "MesDonnéesEnCache" cela posera problème. Par contre si l'on utilise
"Annuaire" d'une part et "Pays" d'autre part, les deux pages utiliseront
chacune la donnée en cache qui l'intéresse sans se marcher sur les pieds
> Si ils utilisent un seul et même compte dans deux fenêtres différentes,
quel
> est le problème posé par le fait que la session est la même dans les
> fenêtres ?
°¿°
Supposons que l'utilisateur veut créer une facture dans la fenetre 1. et
dans la fenetre 2, il veut créer une autre facture.
Les deux fenetres utilisent la meme page .aspx. lorsque je saverais dans
fenetre 2, les données serait mélangées avec la fenêtre1.
un exemple aprmis tant d'autres qui arrivent plus que fréquemment.
>Je ne vois guère comme problème que d'utiliser un même nom pour deux
>différents. Par exemple si on met en cache les données toujours sous le
même
>nom "MesDonnéesEnCache" cela posera problème. Par contre si l'on utilise
>"Annuaire" d'une part et "Pays" d'autre part, les deux pages utiliseront
>chacune la donnée en cache qui l'intéresse sans se marcher sur les pieds
Et que faites vous du cas que c'est la même page dans les deux
Annuaire dans un et Annuaire dans l'autre dans ce cas.
C'est pourquoi l'option envisagée sera propablement de concaténé une
date(date ouverture de la page) dans le nom des variables sessions. Ainsi,
pour une meme session, chaque aurait ses variables sessions qui lui sont
propres.
> Si ils utilisent un seul et même compte dans deux fenêtres différentes,
quel
> est le problème posé par le fait que la session est la même dans les
> fenêtres ?
°¿°
Supposons que l'utilisateur veut créer une facture dans la fenetre 1. et
dans la fenetre 2, il veut créer une autre facture.
Les deux fenetres utilisent la meme page .aspx. lorsque je saverais dans
fenetre 2, les données serait mélangées avec la fenêtre1.
un exemple aprmis tant d'autres qui arrivent plus que fréquemment.
>Je ne vois guère comme problème que d'utiliser un même nom pour deux
>différents. Par exemple si on met en cache les données toujours sous le
même
>nom "MesDonnéesEnCache" cela posera problème. Par contre si l'on utilise
>"Annuaire" d'une part et "Pays" d'autre part, les deux pages utiliseront
>chacune la donnée en cache qui l'intéresse sans se marcher sur les pieds
Et que faites vous du cas que c'est la même page dans les deux
Annuaire dans un et Annuaire dans l'autre dans ce cas.
C'est pourquoi l'option envisagée sera propablement de concaténé une
date(date ouverture de la page) dans le nom des variables sessions. Ainsi,
pour une meme session, chaque aurait ses variables sessions qui lui sont
propres.
> Si ils utilisent un seul et même compte dans deux fenêtres différentes,
quel
> est le problème posé par le fait que la session est la même dans les
> fenêtres ?
°¿°
Supposons que l'utilisateur veut créer une facture dans la fenetre 1. et
dans la fenetre 2, il veut créer une autre facture.
Les deux fenetres utilisent la meme page .aspx. lorsque je saverais dans
fenetre 2, les données serait mélangées avec la fenêtre1.
un exemple aprmis tant d'autres qui arrivent plus que fréquemment.
>Je ne vois guère comme problème que d'utiliser un même nom pour deux
>différents. Par exemple si on met en cache les données toujours sous le
même
>nom "MesDonnéesEnCache" cela posera problème. Par contre si l'on utilise
>"Annuaire" d'une part et "Pays" d'autre part, les deux pages utiliseront
>chacune la donnée en cache qui l'intéresse sans se marcher sur les pieds
Et que faites vous du cas que c'est la même page dans les deux
Annuaire dans un et Annuaire dans l'autre dans ce cas.
C'est pourquoi l'option envisagée sera propablement de concaténé une
date(date ouverture de la page) dans le nom des variables sessions. Ainsi,
pour une meme session, chaque aurait ses variables sessions qui lui sont
propres.
> Pour l'exemple des factures je ne vois pas toujours pas trop comment le
mélange peut intervenir :
- les données saisies dans la page 2 sont "postées" vers le serveur
la page est validée. Les données saisies dans la page 1 ne seront
pas envoyés vers le serveur lors de la validation de la page 2 donc pas de
mélange.
Si des variables de session sont utilisés transitoirement dans le
des pages, je rejoins avec modération l'avis de Michel. Les variables de
session ne sont pas mauvaises en soi mais peuvent effectivement poser
problème selon la façon dont on les utilise (notamment si elles sont
utilisées pour "cacher" des données en lecture/écriture ou par exemple
passer des données d'une page à l'autre). Décrit éventuellement leur usage
si tu souhaites continuer la conversation (par exemple tu en as quand tu
valides une facture ?)
> Pour l'exemple des factures je ne vois pas toujours pas trop comment le
mélange peut intervenir :
- les données saisies dans la page 2 sont "postées" vers le serveur
la page est validée. Les données saisies dans la page 1 ne seront
pas envoyés vers le serveur lors de la validation de la page 2 donc pas de
mélange.
Si des variables de session sont utilisés transitoirement dans le
des pages, je rejoins avec modération l'avis de Michel. Les variables de
session ne sont pas mauvaises en soi mais peuvent effectivement poser
problème selon la façon dont on les utilise (notamment si elles sont
utilisées pour "cacher" des données en lecture/écriture ou par exemple
passer des données d'une page à l'autre). Décrit éventuellement leur usage
si tu souhaites continuer la conversation (par exemple tu en as quand tu
valides une facture ?)
> Pour l'exemple des factures je ne vois pas toujours pas trop comment le
mélange peut intervenir :
- les données saisies dans la page 2 sont "postées" vers le serveur
la page est validée. Les données saisies dans la page 1 ne seront
pas envoyés vers le serveur lors de la validation de la page 2 donc pas de
mélange.
Si des variables de session sont utilisés transitoirement dans le
des pages, je rejoins avec modération l'avis de Michel. Les variables de
session ne sont pas mauvaises en soi mais peuvent effectivement poser
problème selon la façon dont on les utilise (notamment si elles sont
utilisées pour "cacher" des données en lecture/écriture ou par exemple
passer des données d'une page à l'autre). Décrit éventuellement leur usage
si tu souhaites continuer la conversation (par exemple tu en as quand tu
valides une facture ?)
"Michel Thiffault" a écrit dans le message de
news:
> À ce que je sache il est impossible d'être certain qu'une nouvelle
> sera dans la même session ou non. Avant IE 5.5 il y avait une
configuration
> possible à cet effet: lancer les nouvelles fenêtre dans le même
> (désolé, je ne me souviens pas de la dernière fois où j'ai utilisé
> en français). Nous pouvions ainsi garantir que les sessions étaient
> utilisées dans toutes les fenêtres. Depuis IE 5.5 Windows décide si les
> fenêtre sont lancées dans le même process ou non (selon les ressources
> disponibles si je ne m'abuse).
C'est la conclusion à laquelle j'arrive également.
http://support.microsoft.com/?kbid$0928
Si l'ordinateur dispose de moins de 32 mégaoctets (Mo) de mémoire vive,
paramètre est désactivé et toutes les instances d'Internet Explorer
partagent le même processus. Si l'ordinateur présente 32 Mo de RAM ou
le paramètre est activé et les nouvelles instances d'Internet Explorer
génèrent la création de nouveaux processus.
Merci de votre aide.
Je trouve une façon de contourner le problème de session etje vous en fait
part.
"Michel Thiffault" <mtifo@h.ot_m.ai_l.com> a écrit dans le message de
news:eO3JjjRWEHA.1144@TK2MSFTNGP10.phx.gbl...
> À ce que je sache il est impossible d'être certain qu'une nouvelle
> sera dans la même session ou non. Avant IE 5.5 il y avait une
configuration
> possible à cet effet: lancer les nouvelles fenêtre dans le même
> (désolé, je ne me souviens pas de la dernière fois où j'ai utilisé
> en français). Nous pouvions ainsi garantir que les sessions étaient
> utilisées dans toutes les fenêtres. Depuis IE 5.5 Windows décide si les
> fenêtre sont lancées dans le même process ou non (selon les ressources
> disponibles si je ne m'abuse).
C'est la conclusion à laquelle j'arrive également.
http://support.microsoft.com/?kbid$0928
Si l'ordinateur dispose de moins de 32 mégaoctets (Mo) de mémoire vive,
paramètre est désactivé et toutes les instances d'Internet Explorer
partagent le même processus. Si l'ordinateur présente 32 Mo de RAM ou
le paramètre est activé et les nouvelles instances d'Internet Explorer
génèrent la création de nouveaux processus.
Merci de votre aide.
Je trouve une façon de contourner le problème de session etje vous en fait
part.
"Michel Thiffault" a écrit dans le message de
news:
> À ce que je sache il est impossible d'être certain qu'une nouvelle
> sera dans la même session ou non. Avant IE 5.5 il y avait une
configuration
> possible à cet effet: lancer les nouvelles fenêtre dans le même
> (désolé, je ne me souviens pas de la dernière fois où j'ai utilisé
> en français). Nous pouvions ainsi garantir que les sessions étaient
> utilisées dans toutes les fenêtres. Depuis IE 5.5 Windows décide si les
> fenêtre sont lancées dans le même process ou non (selon les ressources
> disponibles si je ne m'abuse).
C'est la conclusion à laquelle j'arrive également.
http://support.microsoft.com/?kbid$0928
Si l'ordinateur dispose de moins de 32 mégaoctets (Mo) de mémoire vive,
paramètre est désactivé et toutes les instances d'Internet Explorer
partagent le même processus. Si l'ordinateur présente 32 Mo de RAM ou
le paramètre est activé et les nouvelles instances d'Internet Explorer
génèrent la création de nouveaux processus.
Merci de votre aide.
Je trouve une façon de contourner le problème de session etje vous en fait
part.
> Si des variables de session sont utilisés transitoirement dans le
traitement des pages, je rejoins avec modération l'avis de Michel.
> Si des variables de session sont utilisés transitoirement dans le
traitement des pages, je rejoins avec modération l'avis de Michel.
> Si des variables de session sont utilisés transitoirement dans le
traitement des pages, je rejoins avec modération l'avis de Michel.
Voyons le pourquoi je garde ça en session.
Supposons que j'ai dix lignes (dans un datagrid) de factures créer pour la
premiere facture, mais qu'elles ne sont pas sauvegardés encore.
Comment faire pour garder ces lignes entre chaque postback.
Ce que je fais c'est de garder un dataset en session et de le réaffecter
datasource du datagrid au besoin, par exemple apres un edit d'une ligne du
datagrid.
-Solution envisagés : Garder le dataset dans le viewstate. (mauvais car
augmente la grosseur de la page apsx)
Garder en session(mauvais car sessions
partagées, d'où mon post)
Voyons le pourquoi je garde ça en session.
Supposons que j'ai dix lignes (dans un datagrid) de factures créer pour la
premiere facture, mais qu'elles ne sont pas sauvegardés encore.
Comment faire pour garder ces lignes entre chaque postback.
Ce que je fais c'est de garder un dataset en session et de le réaffecter
datasource du datagrid au besoin, par exemple apres un edit d'une ligne du
datagrid.
-Solution envisagés : Garder le dataset dans le viewstate. (mauvais car
augmente la grosseur de la page apsx)
Garder en session(mauvais car sessions
partagées, d'où mon post)
Voyons le pourquoi je garde ça en session.
Supposons que j'ai dix lignes (dans un datagrid) de factures créer pour la
premiere facture, mais qu'elles ne sont pas sauvegardés encore.
Comment faire pour garder ces lignes entre chaque postback.
Ce que je fais c'est de garder un dataset en session et de le réaffecter
datasource du datagrid au besoin, par exemple apres un edit d'une ligne du
datagrid.
-Solution envisagés : Garder le dataset dans le viewstate. (mauvais car
augmente la grosseur de la page apsx)
Garder en session(mauvais car sessions
partagées, d'où mon post)
> Si des variables de session sont utilisés transitoirement dans le
> traitement des pages, je rejoins avec modération l'avis de Michel.
J'admet avoir un point de vue extrême sur les variables sessions. Disons
lorsque nos applications ont commencé à être utilisées par quelques
d'utilisateur nous avons dû repasser tous le code pour les remplacer pour
être compatible avec des web farms (pas agréable du tout!).
Pour en revenir au problème de notre collègue Norm il semble que le
viewstate devient de plus en plus intéressant dans son cas.
> Si des variables de session sont utilisés transitoirement dans le
> traitement des pages, je rejoins avec modération l'avis de Michel.
J'admet avoir un point de vue extrême sur les variables sessions. Disons
lorsque nos applications ont commencé à être utilisées par quelques
d'utilisateur nous avons dû repasser tous le code pour les remplacer pour
être compatible avec des web farms (pas agréable du tout!).
Pour en revenir au problème de notre collègue Norm il semble que le
viewstate devient de plus en plus intéressant dans son cas.
> Si des variables de session sont utilisés transitoirement dans le
> traitement des pages, je rejoins avec modération l'avis de Michel.
J'admet avoir un point de vue extrême sur les variables sessions. Disons
lorsque nos applications ont commencé à être utilisées par quelques
d'utilisateur nous avons dû repasser tous le code pour les remplacer pour
être compatible avec des web farms (pas agréable du tout!).
Pour en revenir au problème de notre collègue Norm il semble que le
viewstate devient de plus en plus intéressant dans son cas.
