Hi BenRifkah, Thank you for your thorough reply!
BenRifkah Bergsten-Buret wrote: > I think you're on the right track by considering global variables but > you have to be careful. See comments below. I see...I was minimizing my use of global variables because I thought it was bad practice (as it is in some languages), but I guess I was just being stubborn. :-) > A global variable is one that is available from all components and it's > value may persist across all requests served by the same perl > interpreter/web server process. Ah, excellent, succinct definition; thanks! > If your apache configuration only spawns one process to handle requests > then the memory will persist for all requests and all users and relying > on this will not necessarily be foolish. But this type of configuration > can be perhaps a different kind of foolishness in a high traffic > configuration. This explains a lot...I am using a default set-up and it seems there are 8 or so processes. Also, I'm developing a new system, so I'm the only user. I was debugging my code and most of the time, it all worked well but occasionally, things wouldn't work especially if I left my computer and came back. I suspected it was how I was using global variables...your message confirms what I guessed was going on. Thanks! > Declaring a variable using local creates a blank version of a variable. > This guarantees that code following the 'local' declaration will have a > clean slate. This is a fairly standard way to use global variables. In > my experience there is a top level autohandler or system handler which > clears out every global variable that exists. I see. Honestly, I've never used local before despite having used Perl for many years. I just searched through Google and I know why; one web page says that beginners and intermediates should stick with "my" and leave local alone. :-) Mind you, until now, I guess I never had a "Perl project" that was as large as a web site... > With all this in mind you can use a combination of cookies and global > variables to store your id. Storing the id in a cookie ensures that the > browser will send the value with each request. Your code can store the > value of the cookie in a (cleared out) global variable which will be > accessible by any component for the duration of the request. I see. Another thing I didn't realize was that cookies are sent to a web server at every request. For some reason, I thought I only have "one chance" to get it, so storing it in a global variable at the first request so that it lasts across all of the user's requests was the way to go. I can see now how flawed was that thinking! :-) > If you have the time I would recommend looking into the Apache::Session > module. This allows you to store various information about a user > session in a location that will persist for the same user across > requests. The storage location can be in a relational database or other > server side persistent container (e.g.: file) At the moment, that is overkill [I really have only one value to store], but that might change as I continue to expand the web site. Thank you very much for your explanation! Exactly what I needed and cleared up many things for me! Ray ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
