views:

137

answers:

3

Example

I have a gridview having multiple customers. When a user clicks on the customer link then the CustomerId is stored in the Session "CustomerId".

if i open multiple customer details on multiple tabs then the Session "CustomerId" is overwritten. so it does not make sense to store customerid in the Session.

I just want to store customerids for different tabs

Is there a way by which i can store the customerid in the viewstate of the masterpage? (Assuming there is a single master page and multiple content pages.)

+1  A: 

I usually try to use the URL for page-specific state info. Using session or some other shared storage can easily get messy. If the amount of state data is a bit much for being passed around in the URL, one way could be to rework the way you store the info in the session. by creating a class for holding the needed data, store several such objects in the session and identifying them by some generated request id. This request id can then be passed in the url to allow the page to pick up the correct state info from the session object.

Fredrik Mörk
+1, Agree. It should be in the url. Of course, changing from session to url means tracking all links and posts, but it has to be done.
Kobi
I don't want to use the querystring as the user can easily manipulate the id.
Suresh Dayma
@unknown user - Fredrik specifically addressed this issue - the user can only mess with IDs of object in her session, not directly with CustomerID. This makes it a safe method.
Kobi
A: 

No. The master page does not "live" between requests to different pages, you will have the same effect as storing the value in the page's viewstate.

Kobi
A: 

I would normally use the querystring for this kind of thing, primarily so that the pages are bookmarkable (if you use sessionstate or form values instead, it's impossible to bookmark the page). As you say in your comment to Fredrik's answer, this does mean that users can manipulate the URL to view different customers, but this isn't a problem provided you're checking that the user is allowed to access the specified customer.

If you really don't want to use the querystring, I'd go with hidden form fields to pass the ID around. You should still be checking whether the user is allowed to see the customer though, rather than just blindly assuming that all's fine.

Chris