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
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
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
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
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
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
I ran into this, too and thought it would make a great infusion for the
Perl Webdev community.
I'm still trying to get my head around it, but having it supported in
cgiapp would be great, perhaps as a Plugin or something.
Here are some other ideas:
1) HTML::Template
In the PHP example, they
Very Fine Work.
Thanks for contributing this to the community.
Cheers
--Fred
-Original Message-
From: Steve Comrie [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 10, 2005 10:54 AM
To: cgiapp@lists.erlbaum.net
Subject: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX
Good
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
Hi Steve,
-Original Message-
If you haven't heard of XMLHTTPReqeust aka Remote Scripting aka AJAX it's
basically a way for web pages to communicate with the server and return
information through JavaScript without having to refresh the page.
Very cool stuff indeed.
I converted
Jason,
IMHO, what the folks at SAJAX were trying to do (with including the
javascript code inside the Sajax.pm module) and calling SAJAX::functions
from inside your perl code is just way to complicated for no noticeable (at
least at first look) reason.
I'm sure for more complicated
Hi,
I am using Class::DBI in my CGI::Application apps now with no
problem when I use on my web host's server. I installed all
needed modules locally in my account there and I have had no
problems.
The problem is using it in any way whatsoever on my home pc.
I am now using Red Hat Linux running
On Mar 10, 2005, at 5:17 PM, [EMAIL PROTECTED] wrote:
Hi,
I am using Class::DBI in my CGI::Application apps now with no
problem when I use on my web host's server. I installed all
needed modules locally in my account there and I have had no
problems.
The problem is using it in any way whatsoever
[EMAIL PROTECTED] wrote:
perl -e 'print $_\n for @INC'
The 5.8.0 directories do not show up.
If I do the equivalent listing of @INC from a cgi script, they
do show up.
Sounds like you have multiple perl installations on your box and your
scripts are using a different one that you have in your
A wild guess - From memory, I believe the RH RPM installs Perl in /usr/bin,
but if you compiled Perl from source without changing the defaults, it will
most likely have installed in /usr/local/bin - so you may have two Perls
installed, and your code may be pointing to the old one...
Do you see a
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
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
Hi all,
If you haven't heard of XMLHTTPReqeust aka Remote Scripting aka AJAX
it's basically a way for web pages to communicate with the server and
return information through JavaScript without having to refresh the
page.
For those interested in using JavaScript to update parts of the page
Steve Comrie [EMAIL PROTECTED] wrote:
If you haven't heard of XMLHTTPReqeust aka Remote Scripting aka AJAX
it's basically a way for web pages to communicate with the server and
return information through JavaScript without having to refresh the
page.
You can read more about it here:
It's true:
my new Perl (5.8.6) is at /usr/local/bin/perl
That was the whole problem.
Another problem that came up after was the lack of DBD-
mysql. The rpm would not work. It was crazy. If I tried
to install it said it was already installed. If I tried to
remove, it said it was not
20 matches
Mail list logo
