Comment, dans ASP.NET, traitez-vous des sessions et plusieurs onglets?

Question

J'ai écrit une application en ASP.net, conçue pour permettre à l'utilisateur d'ajouter des enregistrements à une base de données. La page est configurée de manière à ce que lorsqu'un utilisateur ajoute un enregistrement, le numéro d'identification de l'enregistrement nouvellement ajouté soit défini en session, la page Response.Redirects à un message "Merci d'avoir envoyé". page, puis redirige vers la page d'origine pour permettre d'autres modifications. Les utilisateurs peuvent également utiliser le bouton Précédent de cet écran pour revenir à la page d’ajout de l’enregistrement initial, ce qui leur permet d’éditer les données.

Cependant, j’ai constaté que le stockage de l’ID en session n’était pas une très bonne solution, puisqu'un utilisateur pouvait essayer de créer deux documents dans des onglets ou des fenêtres différents. J'ai également essayé de définir l'ID dans un contrôle littéral, mais cela pose le problème suivant: lorsque l'utilisateur utilise le bouton Précédent, le contrôle littéral n'est pas défini sur l'ID et de nouveaux enregistrements sont ajoutés au lieu d'un en cours de modification.

Existe-t-il une solution pour cela?

Answer 1

Question idiote, pourquoi l’utilisateur peut-il utiliser le bouton Précédent pour modifier les données que l’on vient d’accepter dans un message?

Si la modification des données précédemment publiées est un scénario courant, pourquoi ne pas simplement rediriger vers une page lorsque les données sont acceptées, leur permettant de la modifier. Ensuite, si vous appuyez sur le bouton de retour, ils reviennent à l’original "nettoyer". insérer / ajouter une nouvelle page de données.

Ceci donnerait les flux suivants Ajouter- > [Post] - > Modifier- > ..... Ajouter- > [Post] - > Modifier- > [bouton Précédent] - > Ajouter- > [Post] - > Modifier- > [Post] - > Editer ....

Answer 2

Je vous conseillerais de stocker votre identifiant dans QueryString. Une fois l’enregistrement ajouté, redirigez-le vers votre & than; thankyou " Je suppose que la page contient un lien vers le formulaire de modification que vous allez générer avec l’ID dans la chaîne de requête. Lorsque ce lien est suivi, la page d'édition doit extraire l'ID de la chaîne de requête afin de charger le bon enregistrement à modifier.

Votre formulaire d'ajout et de modification peut même être la même page. Lorsqu'un identifiant est fourni dans la chaîne de requête, votre formulaire sait comment modifier cet enregistrement. Sinon, votre formulaire ajoute un nouvel enregistrement.

Answer 3

Avez-vous essayé d’ajouter l’ID dans la chaîne de requête? Ensuite, vous pouvez le lire et l’ajouter à la session en fonction des besoins (par exemple, lorsque vous cliquez sur le bouton Précédent).

Cela ressemble à beaucoup de problèmes pour pouvoir éditer un objet dans une page rendue en utilisant le bouton Précédent. Serait-ce trop de leur donner un bouton d'édition à la place?

Answer 4

Les commandes enregistrent leur état dans ViewState. Si vous choisissez d’utiliser SessionState au lieu de ViewState pour stocker les informations, les contrôles enregistrent leur état dans l’état de la session et cela ne fonctionnera pas correctement avec plusieurs onglets.

Je n'ai pas encore trouvé le moyen de contourner ce problème tout en utilisant SessionState. Notre solution consistait à utiliser le ViewState normal.

Answer 5

J'ai essayé de stocker l'ID dans la chaîne de requête (ce qui convient généralement à l'édition), mais le problème réside dans le fait que les informations sont stockées dans une session lorsque le bouton Précédent est utilisé. Si l'utilisateur fait ce qui suit:

1. L'utilisateur crée un enregistrement (1er enregistrement), l'identifiant est transmis dans la chaîne de requête et stocké temporairement dans la session.
2. L'utilisateur crée un autre enregistrement (2ème enregistrement), l'identifiant est transmis dans la chaîne de requête, stocké temporairement dans la session.
3. L'utilisateur utilise le bouton Précédent du premier enregistrement pour accéder à la page sans chaîne de requête.

C'est probablement un scénario tiré par les cheveux, mais c'est un scénario qui peut arriver. La seule solution que j'ai est de bloquer l'utilisation du bouton Précédent pour revenir à la page d'ajout, en utilisant window.history.forward () en JavaScript. Mais cette solution est terrible.

Answer 6

Ma question est la suivante: pourquoi enregistrez-vous quelque chose dans la session? Si vous pouvez éviter de stocker quoi que ce soit dans la session, je pense que vous serez mieux lotis.

Answer 7

Après avoir réfléchi à cela, est-ce que ce qui suit s’avère être une solution décente au problème que je viens d’évoquer?

• Lorsque vous ajoutez un enregistrement pour la première fois, enregistrez un horodatage du moment où la page d'ajout a été utilisée dans un champ masqué.
• Cet horodatage est transmis au cours de la session lorsque l'utilisateur clique sur Enregistrer. Avec l'ID.
• Si l'utilisateur ouvre simultanément un autre onglet et enregistre, l'horodatage de la nouvelle page est transmis via la session.
• Si l'utilisateur essaie d'accéder à la page d'ajout du premier enregistrement (à l'aide du bouton Précédent), le système cherche la session et voit s'il existe un horodatage et s'il correspond à celui du champ masqué de cette page.
• S'il ne correspond pas, l'utilisateur reçoit une invite et lui dit de modifier l'enregistrement correctement.

Cela semble-t-il raisonnable ou trop complexe?