Re: [cgiapp] CGI::Application and CGI::Session

[Cees Hek]

On Thu, 10 Mar 2005 14:54:50 -0800, Peter Fogg [EMAIL PROTECTED] wrote:
 The only reason that I didn't use CGI::Application::Plugin::Session in
 the first place
 is the fact that it is an alpha version as opposed to a 3+ version
 for CGI::Session. However, on your recommendation I will take a very
 close look at the plugin
 version to solve my problem.

I'll bump up the the version number on the next release.  I have had a
few comments about people not wanting to use the module because of the
low version number...  Also, I'll remove that warning in the docs,
since the module has stabilized and I have not heard of anyone having
any problems in the last year (the warning was really only a CYA thing
anyway ;) )

So, what version should I go up to?  Version 0.10, 1.00, or should I
follow in Uri Guttman's footsteps and go straight to version .0
[1]!

Cheers,

Cees

[1] http://search.cpan.org/~uri/File-Slurp-.07/

-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
  http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] CGI::Application and CGI::Session

[Sean Davis]

On Mar 9, 2005, at 9:52 PM, Peter Fogg wrote:
Hello all,
This module was written to help me understand the use of CGI::Session
with the context of a CGI::Application object. The problem is that
when I store the reference to the CGI::Session object that I have
created in the CGI::Application object, I cannot retrieve the reference
to the CGI::Session object so that I may delete it.
I have enclosed the pertinent parts of the create_set and destroy
subs in ##s.
Being new to Perl and Web site implementation using Perl modules, I am
sure that I have written code that does not conform to best practices;
please feel free to comment, I need all the help I can get! BTW, I know
that there is some redundant code here!!
CUT
#
# I thought that this would store the session id in the application 
object
# so that it would be available later in the destroy sub.
#
#  	$self-param('_SESSION', $session-id());
#
#


If you want to store the session object, then this is probably what you 
want:

$self-param('_SESSION',$session);
This stores the reference to the session object.

#
# This works, the session id appears on the template page.
#
#   $page-param('-sessionref' = $self-param('_SESSION'));
#
#
As it should, but you are only getting the session id from 
$self-param('_SESSION') as you have it currently coded.  Instead, if 
you make the change noted above, you could (to make it transparent) do:

my $session = $self-param('_SESSION');
$page-param('-sessionref' = $session-id());

elf, @args) = @_;
#
# This is what I am trying to do. These lines are currently commented 
out.
#
# # my $session = $self-param('_SESSION');
# # $session-delete();
# # $session-flush();
#
#

These should work with the first change noted above.
As a general comment, I would suggest using plugins whenever possible 
when working with CGI::Application.  These offer standard methods for 
dealing with various objects commonly needed for web development 
(sessions, database handles, templates, etc.).  For example, it is 
possible that you could create several connections to the database as 
you have written here.  Using the DBH plugin, your application can set 
up one database handle (if needed, otherwise not) and share it 
throughout.  The session plugin will only create a session if a session 
is needed; again, it makes the session object available throughout your 
application as $self-session.  I at first thought--I can this just as 
well, but I learned that it was better to use these plugin modules 
until I ran into a barrier that could not be overcome, then just build 
on what was available.  It is a great learning experience to see what 
others have done, as it is (at least for me), usually amazing how small 
these modules actually are, just cleverly and thoughtfully coded.  And 
most of the developers have given thought to running under a mod_perl 
environment, where caching and singleton behaviors can be used.

Hope this helps
Sean
-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
 http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] CGI::Application and CGI::Session

[Peter Fogg]

On Mar 10, 2005, at 3:12 AM, Sean Davis wrote:
On Mar 9, 2005, at 9:52 PM, Peter Fogg wrote:
Hello all,
This module was written to help me understand the use of CGI::Session
with the context of a CGI::Application object. The problem is that
when I store the reference to the CGI::Session object that I have
created in the CGI::Application object, I cannot retrieve the 
reference
to the CGI::Session object so that I may delete it.

I have enclosed the pertinent parts of the create_set and destroy
subs in ##s.
Being new to Perl and Web site implementation using Perl modules, I am
sure that I have written code that does not conform to best practices;
please feel free to comment, I need all the help I can get! BTW, I 
know
that there is some redundant code here!!

CUT
#
# I thought that this would store the session id in the application 
object
# so that it would be available later in the destroy sub.
#
#  	$self-param('_SESSION', $session-id());
#
#


If you want to store the session object, then this is probably what 
you want:

$self-param('_SESSION',$session);
This stores the reference to the session object.


#
# This works, the session id appears on the template page.
#
#   $page-param('-sessionref' = $self-param('_SESSION'));
#
#
As it should, but you are only getting the session id from 
$self-param('_SESSION') as you have it currently coded.  Instead, if 
you make the change noted above, you could (to make it transparent) 
do:

my $session = $self-param('_SESSION');
$page-param('-sessionref' = $session-id());

elf, @args) = @_;
#
# This is what I am trying to do. These lines are currently commented 
out.
#
# # my $session = $self-param('_SESSION');
# # $session-delete();
# # $session-flush();
#
#

These should work with the first change noted above.
Originally, I tried $self-param('_SESSION',$session);. It didn't 
work so I tried $self-param('_SESSION', $session-id());, it didn't 
work either. At your suggestion, I changed back to 
$self-param('_SESSION',$session); and uncommented the my $session 
..., ...delete and ...flush lines of code above. I am still 
getting this message: Error executing run mode '3': Can't call method 
delete on an undefined value at . 

As a general comment, I would suggest using plugins whenever possible 
when working with CGI::Application.  These offer standard methods for 
dealing with various objects commonly needed for web development 
(sessions, database handles, templates, etc.).  For example, it is 
possible that you could create several connections to the database as 
you have written here.  Using the DBH plugin, your application can set 
up one database handle (if needed, otherwise not) and share it 
throughout.  The session plugin will only create a session if a 
session is needed; again, it makes the session object available 
throughout your application as $self-session.  I at first thought--I 
can this just as well, but I learned that it was better to use these 
plugin modules until I ran into a barrier that could not be overcome, 
then just build on what was available.  It is a great learning 
experience to see what others have done, as it is (at least for me), 
usually amazing how small these modules actually are, just cleverly 
and thoughtfully coded.  And most of the developers have given thought 
to running under a mod_perl environment, where caching and singleton 
behaviors can be used.

Hope this helps
Sean

It does indeed help. I will definitely take a look at the 
session-management plugin.

Thanks again for the help.
Peter -
-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
 http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] CGI::Application and CGI::Session

[Sean Davis]

On Mar 10, 2005, at 9:52 AM, Peter Fogg wrote:
On Mar 10, 2005, at 3:12 AM, Sean Davis wrote:
On Mar 9, 2005, at 9:52 PM, Peter Fogg wrote:
Hello all,
This module was written to help me understand the use of CGI::Session
with the context of a CGI::Application object. The problem is that
when I store the reference to the CGI::Session object that I have
created in the CGI::Application object, I cannot retrieve the 
reference
to the CGI::Session object so that I may delete it.

I have enclosed the pertinent parts of the create_set and destroy
subs in ##s.
Being new to Perl and Web site implementation using Perl modules, I 
am
sure that I have written code that does not conform to best 
practices;
please feel free to comment, I need all the help I can get! BTW, I 
know
that there is some redundant code here!!

CUT
#
# I thought that this would store the session id in the application 
object
# so that it would be available later in the destroy sub.
#
#  	$self-param('_SESSION', $session-id());
#
#


If you want to store the session object, then this is probably what 
you want:

$self-param('_SESSION',$session);
This stores the reference to the session object.


#
# This works, the session id appears on the template page.
#
#   $page-param('-sessionref' = $self-param('_SESSION'));
#
#
As it should, but you are only getting the session id from 
$self-param('_SESSION') as you have it currently coded.  Instead, if 
you make the change noted above, you could (to make it transparent) 
do:

my $session = $self-param('_SESSION');
$page-param('-sessionref' = $session-id());

elf, @args) = @_;
#
# This is what I am trying to do. These lines are currently 
commented out.
#
# # my $session = $self-param('_SESSION');
# # $session-delete();
# # $session-flush();
#
#

These should work with the first change noted above.
Originally, I tried $self-param('_SESSION',$session);. It didn't 
work so I tried $self-param('_SESSION', $session-id());, it didn't 
work either. At your suggestion, I changed back to 
$self-param('_SESSION',$session); and uncommented the my $session 
..., ...delete and ...flush lines of code above. I am still 
getting this message: Error executing run mode '3': Can't call method 
delete on an undefined value at . 

Oops, my bad.  Note that in order to have access to your session 
object, it must be created first.  It looks like in run_mode 3, a 
session object hasn't been created.  Remember that the run_modes do not 
run in order (and, typically only 1 run_mode runs per request).  In 
order to set up your session for use later, set it up in setup and 
store the session object at that point.  Then you can call 
$self-param('_SESSION') in any of your run_modes.

Sean
-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
 http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] CGI::Application and CGI::Session

[Peter Fogg]

Originally, I tried $self-param('_SESSION',$session);. It didn't  
work so I tried $self-param('_SESSION', $session-id());, it  
didn't work either. At your suggestion, I changed back to  
$self-param('_SESSION',$session); and uncommented the my $session  
..., ...delete and ...flush lines of code above. I am still  
getting this message: Error executing run mode '3': Can't call  
method delete on an undefined value at . 

Oops, my bad.  Note that in order to have access to your session  
object, it must be created first.  It looks like in run_mode 3, a  
session object hasn't been created.  Remember that the run_modes do  
not run in order (and, typically only 1 run_mode runs per request).   
In order to set up your session for use later, set it up in setup and  
store the session object at that point.  Then you can call  
$self-param('_SESSION') in any of your run_modes.

Sean
.
.
.
sub create_set
{
my ($self, @args) = @_;

my $data_source = 'DBI:mysql:db_gokart';
my $db_Username = 'go_kart';
my $db_Password = 'N5q23B';

my $dbh = DBI-connect($data_source, $db_Username, $db_Password,

{RaiseError = 1,  PrintError = 0})
or die Can't 
connect to $data_source: $DBI::errstr;
###
# Session created here
#
#  my $session = CGI::Session-new(driver:MySQL, undef,  
{Handle=$dbh});
#
###

  $session-param(-name = '_IS_LOGGED_ON', -value = '1');
###
# Session stored in CGI::Application instance here
#
#  $self-param('_SESSION', $session);
#
###
	my $cgi = $self-query();
	my $sid_cookie = $cgi-cookie($session-name(), $session-id());
  $self-header_props(-type='text/html', -cookie=$sid_cookie);	
	my $page = HTML::Template-new(filename =  
'/Library/WebServer/CGI-Executables/_TEST_/session/ 
sessionTest_MySQL_create_set.tmpl');

###
# Session is successfully retrieved here
#
#   $page-param('-sessionref' = $self-param('_SESSION'));
#
###
return $page-output();
}
sub destroy
{
my ($self, @args) = @_;
###
# Session is not successfully retrieved here
#   
#   my $session = $self-param('_SESSION');
#
###
	$session-delete();
	$session-flush();
	
	my $page = HTML::Template-new(filename =  
'/Library/WebServer/CGI-Executables/_TEST_/session/ 
sessionTest_MySQL_destroy.tmpl');
#	$page-param('-sessionref' = $self-param('_SESSION'));
	return $page-output();
}

.
.
.
You are absolutely right that the session has not been created in sub  
destroy. However, I ALWAYS call sub create_set before I call sub  
destroy. My thinking is that if I create the session object in sub  
create_set and save it in the application object that the session  
object should be available in the application object when I  
subsequently call sub destroy. BTW, the way my application works is  
that I display a page with three links. The second link calls sub  
create_set and displays a message that a session object has been  
created. A link on that page takes one back to the original page. The  
third link calls sub destroy expecting to find the session object  
available in the application object which doesn't seem to be the case.  
It seems that the session object is going out of scope before sub  
destroy is called. 

Peter -
-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
 http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] CGI::Application and CGI::Session

[Michael Peters]

Peter Fogg wrote:
You are absolutely right that the session has not been created in sub  
destroy. However, I ALWAYS call sub create_set before I call sub  
destroy. My thinking is that if I create the session object in sub  
create_set and save it in the application object that the session  
object should be available in the application object when I  
subsequently call sub destroy. BTW, the way my application works is  
that I display a page with three links. The second link calls sub  
create_set and displays a message that a session object has been  
created. A link on that page takes one back to the original page. The  
third link calls sub destroy expecting to find the session object  
available in the application object which doesn't seem to be the case.  
It seems that the session object is going out of scope before sub  
destroy is called. 
I think there might be some confusion about how 'param' works. Once a 
run mode returns content to the browser, anything in $self-param is 
gone (actuall everything except cookies is 'gone' since HTTP is 
stateless). It does not maintain state (that's what sessions are for :). 
So you can't store anything in there and expect it to still be there 
after you deliver a page to the user.

Others have suggested it before so I'm just following up... Have you 
looked at CGI::Application::Plugin::Session? It's about the easiest way 
in the world to use sessions with C::A.

--
Michael Peters
Developer
Plus Three, LP
-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
 http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] CGI::Application and CGI::Session

[Peter Fogg]

On Mar 10, 2005, at 9:10 AM, Sean Davis wrote:
You are absolutely right that the session has not been created in sub 
destroy. However, I ALWAYS call sub create_set before I call sub 
destroy. My thinking is that if I create the session object in sub 
create_set and save it in the application object that the session 
object should be available in the application object when I 
subsequently call sub destroy. BTW, the way my application works is 
that I display a page with three links. The second link calls sub 
create_set and displays a message that a session object has been 
created. A link on that page takes one back to the original page. The 
third link calls sub destroy expecting to find the session object 
available in the application object which doesn't seem to be the 
case. It seems that the session object is going out of scope before 
sub destroy is called. 

If you click on a link on a page, that reruns the script--the 
application object is not stored between clicks.  By the time the 
page is generated in the browser, the application object is gone.  You 
cannot then click on a link to go to another run_mode and find what 
was stored in the application object.  Make sense?

Sean
Boy, is my understanding of objects in this environment WAY off base!! 
I think of objects as staying resident in the server memory until I 
destroy them. Your comment above makes sense and really turned on a 
light for me! So every request for my application results in the 
creation of a new application object, execution of the requested sub, 
submission of the resulting page to the browser and destruction of the 
application object. The request from the browser includes the 
previously set session id which I use to retrieve that session object 
from whatever storage system was used when the session was created. I 
would then use the data that is retrieved from the storage system to 
recreate a session object for the duration of the current request just 
as a new application object was created.

Is this correct?
Peter -

-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
 http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] CGI::Application and CGI::Session

[Sean Davis]

On Mar 10, 2005, at 12:56 PM, Peter Fogg wrote:
On Mar 10, 2005, at 9:10 AM, Sean Davis wrote:
You are absolutely right that the session has not been created in 
sub destroy. However, I ALWAYS call sub create_set before I call 
sub destroy. My thinking is that if I create the session object in 
sub create_set and save it in the application object that the 
session object should be available in the application object when I 
subsequently call sub destroy. BTW, the way my application works 
is that I display a page with three links. The second link calls sub 
create_set and displays a message that a session object has been 
created. A link on that page takes one back to the original page. 
The third link calls sub destroy expecting to find the session 
object available in the application object which doesn't seem to be 
the case. It seems that the session object is going out of scope 
before sub destroy is called. 

If you click on a link on a page, that reruns the script--the 
application object is not stored between clicks.  By the time the 
page is generated in the browser, the application object is gone.  
You cannot then click on a link to go to another run_mode and find 
what was stored in the application object.  Make sense?

Sean
Boy, is my understanding of objects in this environment WAY off base!! 
I think of objects as staying resident in the server memory until I 
destroy them. Your comment above makes sense and really turned on a 
light for me! So every request for my application results in the 
creation of a new application object, execution of the requested sub, 
submission of the resulting page to the browser and destruction of the 
application object. The request from the browser includes the 
previously set session id which I use to retrieve that session object 
from whatever storage system was used when the session was created. I 
would then use the data that is retrieved from the storage system to 
recreate a session object for the duration of the current request just 
as a new application object was created.

Is this correct?
Yep.  Just be clear that YOU have to set assure that the session id is 
available at the next invocation of your script, either by way of a 
cookie value, a hidden field paramater, or a parameter in the URL.  The 
browser does not handle this on its own (unlike for basic 
authentication, for example, but that is another issue).  Really, try 
using cgi::app::plugin::session.  Then, look at the code to see how it 
works.  Like a good little module, it is VERY well documented (within 
the code itself), so you can literally read it for understanding

Sean
-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
 http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] CGI::Application and CGI::Session

[Peter Fogg]

On Mar 10, 2005, at 11:13 AM, Sean Davis wrote:
On Mar 10, 2005, at 12:56 PM, Peter Fogg wrote:
On Mar 10, 2005, at 9:10 AM, Sean Davis wrote:
You are absolutely right that the session has not been created in 
sub destroy. However, I ALWAYS call sub create_set before I 
call sub destroy. My thinking is that if I create the session 
object in sub create_set and save it in the application object 
that the session object should be available in the application 
object when I subsequently call sub destroy. BTW, the way my 
application works is that I display a page with three links. The 
second link calls sub create_set and displays a message that a 
session object has been created. A link on that page takes one back 
to the original page. The third link calls sub destroy expecting 
to find the session object available in the application object 
which doesn't seem to be the case. It seems that the session object 
is going out of scope before sub destroy is called. 

If you click on a link on a page, that reruns the script--the 
application object is not stored between clicks.  By the time the 
page is generated in the browser, the application object is gone.  
You cannot then click on a link to go to another run_mode and find 
what was stored in the application object.  Make sense?

Sean
Boy, is my understanding of objects in this environment WAY off 
base!! I think of objects as staying resident in the server memory 
until I destroy them. Your comment above makes sense and really 
turned on a light for me! So every request for my application results 
in the creation of a new application object, execution of the 
requested sub, submission of the resulting page to the browser and 
destruction of the application object. The request from the browser 
includes the previously set session id which I use to retrieve that 
session object from whatever storage system was used when the session 
was created. I would then use the data that is retrieved from the 
storage system to recreate a session object for the duration of the 
current request just as a new application object was created.

Is this correct?
Yep.  Just be clear that YOU have to set assure that the session id is 
available at the next invocation of your script, either by way of a 
cookie value, a hidden field paramater, or a parameter in the URL.  
The browser does not handle this on its own (unlike for basic 
authentication, for example, but that is another issue).  Really, try 
using cgi::app::plugin::session.  Then, look at the code to see how it 
works.  Like a good little module, it is VERY well documented (within 
the code itself), so you can literally read it for understanding

Sean

Two questions and a comment and I'll be out of your hair!
So I get the session id sent by the browser and do a $session = 
CGI::session-new( ... with the retrieved session id as the second 
parameter. The method will retrieve
the session variables stored in the storage medium. Do I have that 
right?

What is the feeling about the merits of the driver being File or 
DB_File or MySQL?

The only reason that I didn't use CGI::Application::Plugin::Session in 
the first place
is the fact that it is an alpha version as opposed to a 3+ version 
for CGI::Session. However, on your recommendation I will take a very 
close look at the plugin
version to solve my problem.

Many thanks for the help that I received from you and Michael Peters.
Regards,
Peter -
-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
 http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [cgiapp] CGI::Application and CGI::Session

[Sean Davis]

On Mar 10, 2005, at 5:54 PM, Peter Fogg wrote:
On Mar 10, 2005, at 11:13 AM, Sean Davis wrote:
On Mar 10, 2005, at 12:56 PM, Peter Fogg wrote:
On Mar 10, 2005, at 9:10 AM, Sean Davis wrote:
You are absolutely right that the session has not been created in 
sub destroy. However, I ALWAYS call sub create_set before I 
call sub destroy. My thinking is that if I create the session 
object in sub create_set and save it in the application object 
that the session object should be available in the application 
object when I subsequently call sub destroy. BTW, the way my 
application works is that I display a page with three links. The 
second link calls sub create_set and displays a message that a 
session object has been created. A link on that page takes one 
back to the original page. The third link calls sub destroy 
expecting to find the session object available in the application 
object which doesn't seem to be the case. It seems that the 
session object is going out of scope before sub destroy is 
called. 

If you click on a link on a page, that reruns the script--the 
application object is not stored between clicks.  By the time the 
page is generated in the browser, the application object is gone.  
You cannot then click on a link to go to another run_mode and find 
what was stored in the application object.  Make sense?

Sean
Boy, is my understanding of objects in this environment WAY off 
base!! I think of objects as staying resident in the server memory 
until I destroy them. Your comment above makes sense and really 
turned on a light for me! So every request for my application 
results in the creation of a new application object, execution of 
the requested sub, submission of the resulting page to the browser 
and destruction of the application object. The request from the 
browser includes the previously set session id which I use to 
retrieve that session object from whatever storage system was used 
when the session was created. I would then use the data that is 
retrieved from the storage system to recreate a session object for 
the duration of the current request just as a new application object 
was created.

Is this correct?
Yep.  Just be clear that YOU have to set assure that the session id 
is available at the next invocation of your script, either by way of 
a cookie value, a hidden field paramater, or a parameter in the URL.  
The browser does not handle this on its own (unlike for basic 
authentication, for example, but that is another issue).  Really, try 
using cgi::app::plugin::session.  Then, look at the code to see how 
it works.  Like a good little module, it is VERY well documented 
(within the code itself), so you can literally read it for 
understanding

Sean

Two questions and a comment and I'll be out of your hair!
So I get the session id sent by the browser and do a $session = 
CGI::session-new( ... with the retrieved session id as the second 
parameter. The method will retrieve
the session variables stored in the storage medium. Do I have that 
right?
Yep.
What is the feeling about the merits of the driver being File or 
DB_File or MySQL?

I like relational databases, but that is just me.  There are bound to 
be strong feelings one way or the other, particularly in terms of 
performance, so I would say until you have a problem, just pick one for 
experimentation purposes.

The only reason that I didn't use CGI::Application::Plugin::Session in 
the first place
is the fact that it is an alpha version as opposed to a 3+ version 
for CGI::Session. However, on your recommendation I will take a very 
close look at the plugin
version to solve my problem.
One of the (many) reasons that I like CGI::Application and its plugins 
is that all of the authors are on this list constantly, answering 
questions, responding (in a meaningful way) to bug reports or concerns, 
giving tips and tricks about how to best use the software.  Therefore, 
I think that although CGI::App::plugin:: is likely to not be as 
battle-tested as something like CGI::Session or CGI itself, that 
doesn't mean it is full of bugs.  And, even if it is, the author is 
likely to be on this list and can answer questions within minutes of 
your asking.  Not many CPAN modules have this level of fast and 
personal support, I think.  So, I would just use them all, but 
certainly if you have questions about one of the plugins, ask here--it 
is a very personable forum.  In fact, I can remember a question coming 
up on the list (I think it was about sharing database handles 
throughout the application), and within less than 24 hours, someone had 
made a plugin to do just that.  That is user support!

Many thanks for the help that I received from you and Michael Peters.
Regards,
Peter -
Let us know how it goes.
-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
 http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, 

[cgiapp] CGI::Application and CGI::Session

[Peter Fogg]

Hello all,
This module was written to help me understand the use of CGI::Session
with the context of a CGI::Application object. The problem is that
when I store the reference to the CGI::Session object that I have
created in the CGI::Application object, I cannot retrieve the reference
to the CGI::Session object so that I may delete it.
I have enclosed the pertinent parts of the create_set and destroy
subs in ##s.
Being new to Perl and Web site implementation using Perl modules, I am
sure that I have written code that does not conform to best practices;
please feel free to comment, I need all the help I can get! BTW, I know
that there is some redundant code here!!
Thanks in advance for any help tendered.
Peter -
package SessionTest_MySQL;
use base 'CGI::Application';
use DBI;
use HTML::Template;
use CGI::Session qw(-ip-match);
use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
use strict;
use warnings;
sub setup
{
my ($self, @args) = @_;

$self-mode_param('test');
$self-run_modes(
start = 'show_options',
'1'   = 'create_expire',
'2'   = 'create_set',
'3'   = 'destroy'
);
}
sub show_options
{
my ($self, @args) = @_;
	my $page = HTML::Template-new(filename =  
'/Library/WebServer/CGI-Executables/		_TEST_/session/ 
sessionTest_MySQL_options.tmpl');
	return $page-output();
}

sub create_expire
{
	my ($self, @args) = @_;
	
	my $data_source = 'DBI:mysql:db_gokart';
	my $db_Username = 'go_kart';
	my $db_Password = 'N5q23B';
		
	my $dbh = DBI-connect($data_source, $db_Username, $db_Password,
{RaiseError = 1,  PrintError = 0})
			or die Can't connect to $data_source: $DBI::errstr;
  	my $session = CGI::Session-new(driver:MySQL, undef,  
{Handle=$dbh});
  	$session-expire(+5m);

my $cgi = $self-query();
my $sid_cookie = $cgi-cookie($session-name(), $session-id());
$self-header_props(-type='text/html', -cookie=$sid_cookie);
	my $page = HTML::Template-new(filename =  
'/Library/WebServer/CGI-Executables/		_TEST_/session/ 
sessionTest_MySQL_create_expire.tmpl');
	return $page-output();
}

sub create_set
{
	my ($self, @args) = @_;
	
	my $data_source = 'DBI:mysql:db_gokart';
	my $db_Username = 'go_kart';
	my $db_Password = 'N5q23B';
		
	my $dbh = DBI-connect($data_source, $db_Username, $db_Password,
{RaiseError = 1,  PrintError = 0})or die Can't  
connect to $data_source: $DBI::errstr;
  	my $session = CGI::Session-new(driver:MySQL, undef,  
{Handle=$dbh});
  	$session-param(-name = '_IS_LOGGED_ON', -value = '1');

#
# I thought that this would store the session id in the application  
object
# so that it would be available later in the destroy sub.
#
#  	$self-param('_SESSION', $session-id());
#
#

my $cgi = $self-query();
my $sid_cookie = $cgi-cookie($session-name(), $session-id());
$self-header_props(-type='text/html', -cookie=$sid_cookie); 
	my $page = HTML::Template-new(filename =  
'/Library/WebServer/CGI-Executables/		_TEST_/session/ 
sessionTest_MySQL_create_set.tmpl');

#
# This works, the session id appears on the template page.
#
#   $page-param('-sessionref' = $self-param('_SESSION'));
#
#
return $page-output();
}
sub destroy
{
my ($self, @args) = @_;
#
# This is what I am trying to do. These lines are currently commented  
out.
#
# # my $session = $self-param('_SESSION');
# # $session-delete();
# # $session-flush();
#
#
	
	my $page = HTML::Template-new(filename =  
'/Library/WebServer/CGI-Executables/		_TEST_/session/ 
sessionTest_MySQL_destroy.tmpl');

#
# This doesn't work, the session id does not appear on the template  
page.
#
#	$page-param('-sessionref' = $self-param('_SESSION'));
#
#

return $page-output();
}
1;
-
Web Archive:  http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
 http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]