SitePoint Sponsor

User Tag List

Results 1 to 8 of 8
  1. #1
    SitePoint Member
    Join Date
    Apr 2003
    Location
    netherlands
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    persistent values?

    I'm a (moderate) newbie to and I'm building an ASP/VB db-driven site where the user selects a brand from a menu, this determines the contents for another menu with models. Selecting a model displays details about that model. Nothing too original here Its a small low traffic site with no ecommerce elements - just window shopping.

    My questions is : I need to know on all pages what the current brand and model are (and modify these when the user changes them).
    From what I understand there are 3 (?) methods: server vars, session vars or hidden fields. Which should I use for this purpose and can anyone point me to some good related examples/tutorials? (I've read the stuff on this site of course).

    Thanks in advance,

    Lokey

  2. #2
    SitePoint Guru
    Join Date
    Sep 1999
    Location
    Singapore
    Posts
    854
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Looks like query strings would do fine actually.

  3. #3
    SitePoint Zealot Wilmot's Avatar
    Join Date
    Feb 2000
    Location
    Brisbane, Queensland, Australia
    Posts
    187
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As duckie pointed out, the QueryString is probably the best option for this type of thing. Basically, the query string is all the info after the ? in a URL. So... if you look at the URL for this page .../showthread.php?threadid=106034 the query string is "threadid=106034".

    You could use this method to pass a brandID to the models page. ie http://www.yoursite.com/models.asp?brandID=brand1

    I'm sure there are a number of tutorials available for doing this kind of thing on the net. Try searching google for things like "asp querystring" "asp state management"

    I have a book called "Teach Yourself E-Commerce Programming with ASP in 21 Days" by SAMS publishing which discusses these things too.

    At a higher level, as you mentioned there are a few different methods you can use to make information available between pages. These are:

    1. Server Application variables - Created when the web server is booted up, and last until the server is restarted.

    2. Server Session variables - Created when a new session is established with the server, and lasts until the session is terminated or expires (these use cookies with standard ASP implementations, so may not be the best option if your visitors disable cookies). Often used to store info like "is the user logged in?"

    3. QueryString - As discussed above, information is passed in the URL between pages. Often used to store info like "product IDs", "sub-categories" etc.

    4. Hidden form variables - These make use of the <input type=hidden> HTML tag to pass information within the source code of pages. This is only useful if you are submitting HTML forms between different pages. Also note it is only hidden from display in the browser. All info is still in plain text in the page source code, so it is no good for passwords etc.

    There are a few more advanced options that can be used for fully blown e-commerce sites. These include storing state info in a database, and using a separate state server to handle state info.

    ASP.NET makes it much easier to handle state information, but if you are using plain ASP the above four options are your best bet.

    Hope this clears up some of the options you have!
    Brad Culbert
    SQL Server 2005 Books
    www.SQLServer2005Books.com - Reader-rated SQL Server 2005 Books

  4. #4
    SitePoint Enthusiast
    Join Date
    Apr 2003
    Location
    .vu
    Posts
    50
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It is good practice to avoid Session Variables whenever you can.

  5. #5
    SitePoint Zealot Wilmot's Avatar
    Join Date
    Feb 2000
    Location
    Brisbane, Queensland, Australia
    Posts
    187
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    vurton: I have heard this before, and from what I can gather one of the reasons is that session variables rely on cookies. Is there any other reasons that you know of why session variables are best avoided?
    Brad Culbert
    SQL Server 2005 Books
    www.SQLServer2005Books.com - Reader-rated SQL Server 2005 Books

  6. #6
    Bangarang! Karloff's Avatar
    Join Date
    Mar 2003
    Location
    Manchester, United Kingdom
    Posts
    236
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Session variables do not perform well when it gets busy. The session requires ~10 KB memory in addition to whatever you store in it. Session variables slow down requests marginally. Session variables are relatively unreliable as they depend on client-enabled cookies. They usually hang around longer than necessary until their timeout is reached. Session variable compatibility forces serialized frameset content requests. Session variables are not persisted to disk - crash the app, loose all sessions. Most importantly, however, if you plan to grow or already have a webfarm, sessions do not scale well - use a load balancer and watch sessions topple your application as users get directed from one physical machine to another (note: F5 Networks offer sticky sessions with a performance hit on their balancers... probably others do too).

    Session variables are responsible for worldwide inflation, the greenhouse effect and they drink away your coffee when you desperately needed it late at night while working
    Karl


    I'm desperately trying to figure out why Kamikaze pilots wore helmets. - George Carlin

  7. #7
    SitePoint Enthusiast
    Join Date
    Apr 2003
    Location
    .vu
    Posts
    50
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Karloff
    Session variables are responsible for worldwide inflation, the greenhouse effect and they drink away your coffee when you desperately needed it late at night while working
    That's very correct.

    Some say they are the work of the devil.

  8. #8
    SitePoint Member
    Join Date
    Apr 2003
    Location
    netherlands
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks Wilmot et al for the reply. I had meanwhile figured out how to solve it using hidden fields and querystrings.
    Up next: images from db, security and performance. If I bump into any more problems I know where to ask for help.

    Regards,

    Lokey


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •