Wrox Programmer Forums
| Search | Today's Posts | Mark Forums Read
ASP.NET 1.0 and 1.1 Professional For advanced ASP.NET 1.x coders. Beginning-level questions will be redirected to other forums. NOT for "classic" ASP 3 or the newer ASP.NET 2.0 and 3.5
Welcome to the p2p.wrox.com Forums.

You are currently viewing the ASP.NET 1.0 and 1.1 Professional section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old July 1st, 2005, 09:21 AM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
Default

Great! Glad it worked out for you.

Yeah, the designer glitch is a pain. Sometimes it doesn't happen. It's strange. I have found that it doesn't get in the way much. Also, I'm finding that it has forced me to remember control propertie names so now I just hand write in the changes I need and it's much faster than loading the designer, then the properties toolbox for the control, finding the property and changing it there.

You can still use the session for overall managment from page to page of the values like I described in the article. That works well when combined with a CommonMembers BasePage property.

-Peter
 
Old July 1st, 2005, 09:35 AM
Registered User
 
Join Date: Jun 2005
Location: , , .
Posts: 8
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Yes, session can still be very usefull for some tasks, although for passing variables between pages it might be risky I guess (although you probably didn't mean that).

Btw, I noticed that using just public variables has the same behavior in this situation as using properties. What is the advantage here for using property variables instead of public variables?

Also, I think this situation is being resolved by ASP.NET 2.0 with Masterpages from what I read so far, but I'm not sure, maybe it's just for layout...

 
Old July 1st, 2005, 02:31 PM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
Default

I'm not sure why you think using the session for transporting values between pages is risky. Aside from querstring values, how else would you do it? I use session values for carrying around information that needs to persist during a user's session. When I need to carry something simple to another page to complete some operation then I use querystring vars. The way I see it, the values that we would put in our CommonMembers class are those that you want to persist in the session.

There is little technically different between public vars and public properties. I have just made a habit of building classes with public vars to expose values.

Yes, the core idea discussed in the article that focuses on creating a layout framework will be replaced by masterpages. However, the concept of a CommonMembers class and BasePage property for it is not replaced. I have still yet to see this technique used or offered by anyone.

-Peter
 
Old July 25th, 2005, 02:44 AM
Registered User
 
Join Date: Jun 2005
Location: , , .
Posts: 8
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Just to get back on this (took a while...), what I meant by passing variables between pages and it being risky with session variables: imagine you have one page with client id's and when clicking on one it should redirect to another page where the client id is used to display data from the client. If you use session variables it's risky because if the session times out the passing id variable is gone and the display page doesn't know what to display. Logical would be to use querystring variables then, but what if you don't want to expose such id's to the users? Serverside variables like using server.transfer? Disadvantage there is that there pagename on the client doesn't change. So I guess there is never a really ideal situation in the case you want to hide id's from your users and don't want to use sessions for timeout reasons. What do you think?

 
Old July 30th, 2005, 07:56 AM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
Default

You raise a valid point about session expiration. However, in pratice I don't see how this is really going to happen. If the user is sitting on the "Client List" page, and they then click on one client to see the "Details" page, how is their session going to time out? Only if they leave the browser sitting on the list page for the length of timeout. Remember that the session is a rolling timeout. Ever page hit resets it. It's seems reasonable to think that if their session times out, they'll have other problems. Perhaps they will have to be re-authenticated. Plus, you can design your details page to catch the problem of a missing session value.

An alternative to switching between pages is to build a form that has both the list view and the details view. You can put each in a panel control and change the visibility of them as you switch between views. Then you don't have to pass any information around at all because it will all be within the scope of a single page.

-Peter
 
Old July 30th, 2005, 11:09 AM
Registered User
 
Join Date: Jun 2005
Location: , , .
Posts: 8
Thanks: 0
Thanked 0 Times in 0 Posts
Default

You are completely right, I didn't look at it this way! Session variables are indeed a good way to pass variables to other pages in this way.

Only thing I would be a little bit concerned about is the scalability of it, if many users use the application at the same time, I guess it would be best to empty the session variables in the receiving page immediately using Session("MyValue") = Nothing or Session.Remove("MyValue") (not sure which one is better...), and also the contents of the session variables should be as short/little as possible, like for example only a client ID.

 
Old August 1st, 2005, 07:55 AM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
Default

Exactly. Rule of thumb with session variables: store only what you absolutely need. Instead of storing an object, store the pieces of the object and reconstruct the object when you need to. If you wanted to store a reference to something from a database it might be better from a performance perspective to store a reference to the data (recordID/key) and retrieve the record again on the page that needs it instead of carrying the object around in the session which will just chew up memory.

-Peter




Similar Threads
Thread Thread Starter Forum Replies Last Post
Properties In User Controls - A Tip And Trick Muhammad Zeeshan ASP.NET 2.0 Basics 0 November 23rd, 2007 03:51 AM
Properties In User Controls - A Tip And Trick Muhammad Zeeshan ASP.NET 2.0 Professional 0 September 20th, 2007 10:49 PM
Accessing the Controls of a User Control? Aaron Edwards ASP.NET 2.0 Basics 6 June 16th, 2006 07:22 PM
Accessing Properties in User Controls andyj00 Classic ASP Professional 1 May 21st, 2005 02:52 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.