Much fun was had today. I needed some session management for a site with vague specs and I'm not sure what data to capture. I generally don't enjoy stuffing too much data into a session, but I needed to get this stuff running quickly, with the caveat that other pages on this site might want to share the session id to avoid setting multiple cookies. But if I do that, how do easily prevent accidentally overwriting session data in the database?
My sessions now have their own namespaces. It's based on CGI::Session and is mostly transparent to the programmer. You can have 28 different programs setting a session parameter named "total", all of them using the same session, but each maintaining a distinct total, if necessary. But if they need to share the data? Create a new session object explicitly naming the namespace from which you want to get the data:
my $session = My::Session->new($cgi, 'some_namespace');
If you leave the namespace off, it defaults to sprintf("%s::%s", $0, $calling_package);.
I'm not entirely sure that's a great idea, but it's quite handy.
Re:Code availability?
Ovid on 2003-07-27T19:56:09
It's not likely for a couple of reasons. First, this code was written on someone else's dime and has some customization for their needs. It belongs to them. I'd have to reimplement it from scratch. To make it a more general tool, I'd still need to change a few things about it.
The other reason is a bit odd: many people abuse how cookies are used and making them a more flexible tool might encourage that abuse. Using a cookie this way can make it easier for a domain to set only one cookie (with the session id) rather than the multiple cookies that many domains currently set. This is a good thing. However, this also would encourage people to use cookie data as "global variables" and just shover everything in them without giving it much thought. That's similar to how many programmers -- including me -- have a bad habit of shoving everything and the kitchen sink into a hashref and then blessing that and pretending that their code is object oriented. The idea isn't a bad one but it would be very easy to abuse.
Easy to Abuse
chromatic on 2003-07-29T16:12:58
Maybe the problem isn't that you could stick all of your data in a hashref and bless it. Maybe the problem is that you don't pull it into saner pieces when you need it to be in saner pieces.
