Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday July 25, 2003
01:40 PM

Session Namespaces

[ #13691 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Wow, that's slick. I admit, I've barely got my feet wet with CGI::Session, but I can already see where that could be really handy.
  • Seems interesting. Can we expect code and documentation to appear on a public website? :)
    • 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 ses

      • 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.