You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Nathan Wiger <na...@west.sun.com> on 2000/07/07 01:07:49 UTC
Apache::Session::Object
Hi-
I've created an object interface to Apache::Session. It's a simple
module that I've called Apache::Session::Object (seemed pretty
intuitive) that presents the following interface:
# Create new session using the default File store
use Apache::Session::Object;
my $session = new Apache::Session::Object;
my $id = $session->session_id; # get session_id
$session->{visa_number} = "4441 2001 2039 1100";
$session->param('visa_number') = "4441 2001 2039 1100"; # same
# Open existing session in the DB_File store
use Apache::Session::Object;
my $session2 = new Apache::Session::Object
($id, {Store => 'DB_File', Transaction => 1});
print $session2->_session_id; # leading _ ok
# yet another way to skin the same cat
$session->visa_number("4441 2001 2039 1100");
print $session2->visa_number;
Any comments on this? I wanted to write it to make a more consistent
interface with the other modules. It might also make sense to integrate
this with the existing Apache::Session module. The module itself is
pretty simple, just playing some tricks with new() and AUTOLOAD() to
provide a virtual OOP interface.
Thanks,
Nate
Re: Apache::Session::Object
Posted by Gunther Birznieks <gu...@extropia.com>.
This is somewhat off the topic of your original post, but I have to admit
that I really am a tad alarmed at the interest in storing a credit card
number in a local session.
Usually CC numbers should at most either be emailed (PGPed) directly to the
customer without any temp file creation or passed through to a payment
gateway. That way there is no persistence of that sort of customer
information stored anywhere on the server.
At 04:50 PM 7/6/00 -0700, Nathan Wiger wrote:
>Perrin-
>
> > Is there a reason you can't use the OO interface that Apache::Session
> > comes with?
> >
> > $session->STORE('visa_number') = '7';
> > print $session->FETCH('visa_number');
> > $session->DELETE('visa_number');
>
>This isn't really a documented interface - it's an overloading of the
>tie methods so that the tied hash interface works. You can't find this
>by reading the manpage for Apache::Session, only by reading through the
>module itself or knowing enough about tie to know it's there.
>
> > If your module is using the tied interface to Apache::Session to do its
> > work, you're getting the worst of both worlds in terms of performance.
>
>Not sure quite what you mean, maybe you can clarify? Won't You always
>need to tie %session to Apache::Session::____ to create the initial
>object, unless I'm missing something? Are you just referring to using
>FETCH, STORE, and DELETE directly inside the methods (i.e., rather than
>$session{'param'} use $session->FETCH('param') ?)
>
> > AUTOLOAD methods can be an additional slowdown if you don't cache
> > AUTOLOADed methods (i.e. if AUTOLOAD has to resolve the methods every
> > time).
>
>Good point.
>
> > I can see reasons for creating an OO module that subclasses
> > Apache::Session, but I would do it to add methods that don't map directly
> > to a single hash key.
>
>Exactly why I'm doing it:
>
> $session->visa_number(501);
> $session->visa_number;
>
>same function, but it maps to a combination of FETCH and STORE depending
>on the arguments.
>
>-Nate
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: Apache::Session::Object
Posted by Nathan Wiger <na...@west.sun.com>.
Perrin-
> modifying Apache::Session to support both interfaces and sending Jeffrey
> the patch.
This is a good suggestion. I'll try modifying Apache::Session first and
sending Jeff the patch. If he doesn't want to integrate it I'll package
it as a separate module.
-Nate
Re: Apache::Session::Object
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 6 Jul 2000, Nathan Wiger wrote:
> > $session->STORE('visa_number') = '7';
> > print $session->FETCH('visa_number');
> > $session->DELETE('visa_number');
>
> This isn't really a documented interface - it's an overloading of the
> tie methods so that the tied hash interface works. You can't find this
> by reading the manpage for Apache::Session, only by reading through the
> module itself or knowing enough about tie to know it's there.
I guess I just figured most people knew that was how tie works. I suppose
it's not an officially supprted interface though.
> > If your module is using the tied interface to Apache::Session to do its
> > work, you're getting the worst of both worlds in terms of performance.
>
> Not sure quite what you mean, maybe you can clarify?
Using tie-d methods is slower than using normal methods, so if you have a
method that in turn calls a tie-d method, you're going to have significant
overhead versus just calling the STORE/FETCH methods directly.
> Won't You always need to tie %session to Apache::Session::____ to
> create the initial object, unless I'm missing something?
You can call the TIEHASH method directly to get an object back.
> Are you just referring to using FETCH, STORE, and DELETE directly
> inside the methods (i.e., rather than $session{'param'} use
> $session->FETCH('param') ?)
That would certainly be faster.
> > I can see reasons for creating an OO module that subclasses
> > Apache::Session, but I would do it to add methods that don't map directly
> > to a single hash key.
>
> Exactly why I'm doing it:
>
> $session->visa_number(501);
> $session->visa_number;
>
> same function, but it maps to a combination of FETCH and STORE depending
> on the arguments.
I was thinking of a situation where calling the visa_number method also
sets 'validated' to 0 and 'card_type' to 'visa', or something like that.
Anyway, I don't want to discourage you from making an Apache::Session
subclass (it's another rite of passage that many a mod_perler has gone
through), but if all you want is method access to the functionality
already there I'd suggest either calling the TIE methods directly or
modifying Apache::Session to support both interfaces and sending Jeffrey
the patch. Otherwise you'll definitely be adding some performance
penalties that might limit the usefulness of your additions for people
with busy sites.
- Perrin
Re: Apache::Session::Object
Posted by Nathan Wiger <na...@west.sun.com>.
Perrin-
> Is there a reason you can't use the OO interface that Apache::Session
> comes with?
>
> $session->STORE('visa_number') = '7';
> print $session->FETCH('visa_number');
> $session->DELETE('visa_number');
This isn't really a documented interface - it's an overloading of the
tie methods so that the tied hash interface works. You can't find this
by reading the manpage for Apache::Session, only by reading through the
module itself or knowing enough about tie to know it's there.
> If your module is using the tied interface to Apache::Session to do its
> work, you're getting the worst of both worlds in terms of performance.
Not sure quite what you mean, maybe you can clarify? Won't You always
need to tie %session to Apache::Session::____ to create the initial
object, unless I'm missing something? Are you just referring to using
FETCH, STORE, and DELETE directly inside the methods (i.e., rather than
$session{'param'} use $session->FETCH('param') ?)
> AUTOLOAD methods can be an additional slowdown if you don't cache
> AUTOLOADed methods (i.e. if AUTOLOAD has to resolve the methods every
> time).
Good point.
> I can see reasons for creating an OO module that subclasses
> Apache::Session, but I would do it to add methods that don't map directly
> to a single hash key.
Exactly why I'm doing it:
$session->visa_number(501);
$session->visa_number;
same function, but it maps to a combination of FETCH and STORE depending
on the arguments.
-Nate
Re: Apache::Session::Object
Posted by Perrin Harkins <pe...@primenet.com>.
On Thu, 6 Jul 2000, Nathan Wiger wrote:
> I've created an object interface to Apache::Session. It's a simple
> module that I've called Apache::Session::Object (seemed pretty
> intuitive) that presents the following interface:
>
> # Create new session using the default File store
> use Apache::Session::Object;
> my $session = new Apache::Session::Object;
>
> my $id = $session->session_id; # get session_id
> $session->{visa_number} = "4441 2001 2039 1100";
> $session->param('visa_number') = "4441 2001 2039 1100"; # same
>
>
> # Open existing session in the DB_File store
> use Apache::Session::Object;
> my $session2 = new Apache::Session::Object
> ($id, {Store => 'DB_File', Transaction => 1});
>
> print $session2->_session_id; # leading _ ok
>
> # yet another way to skin the same cat
> $session->visa_number("4441 2001 2039 1100");
> print $session2->visa_number;
Is there a reason you can't use the OO interface that Apache::Session
comes with?
$session->STORE('visa_number') = '7';
print $session->FETCH('visa_number');
$session->DELETE('visa_number');
If your module is using the tied interface to Apache::Session to do its
work, you're getting the worst of both worlds in terms of performance.
AUTOLOAD methods can be an additional slowdown if you don't cache
AUTOLOADed methods (i.e. if AUTOLOAD has to resolve the methods every
time).
I can see reasons for creating an OO module that subclasses
Apache::Session, but I would do it to add methods that don't map directly
to a single hash key.
- Perrin