Cees:
That is odd, as it usually works out of the box without requiring any
configuration.
You're absolutely right. I was just trying too hard. After commenting out
session_config and having it work, I successfully added back in:
$self-session_config( DEFAULT_EXPIRY = '+15m');
As I
On 2005-12-17, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
sub cgiapp_postrun {
my $self = shift;
$self-set_session(); #set the session
}
sub set_session {
my $self = shift;
$self-session-param(user_name = $user_name);
$self-session-param(user_id = $user_id);
Mark,
I recommended using postrun for this, becaues it runs after every run
mode in the module, but is only needed one once: After you have logged
in. I would find it more efficient and logicial to then call
set_session() at the end of the login processing run mode.
Thanks, I didn't realize
On 2005-12-17, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
postrun tends to be rarely used my experience.
The one related thing I have done is to call $self-session-flush()
in the teardown() phase. I think that should happen automatically.
Are you saying flush happens automatically and not
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 17, 2005 2:29 PM
To: Mark Stosberg
Cc: cgiapp@lists.erlbaum.net
Subject: Re: [cgiapp] Re: C::A::P::Session not 'remembering' session
Mark,
I recommended using postrun for this,
I'm writing a medium-sized web-based financial application that will have up
to 50 run modes between presenting empty forms, saving, editing, updating,
and deleting from them. Run modes *could* be broken down into groups, e.g.,
these 4 deal with managing users, these 6 deal with managing project
Brad Cathey wrote:
I'm writing a medium-sized web-based financial application that will have up
to 50 run modes between presenting empty forms, saving, editing, updating,
and deleting from them. Run modes *could* be broken down into groups, e.g.,
these 4 deal with managing users, these 6
Thank you Michael, that was very helpful. Unfortunately it uncovered areas
I'm unfamiliar with, that a good study of OO will help.
Brad Cathey wrote:
I'm writing a medium-sized web-based financial application that will have up
to 50 run modes between presenting empty forms, saving, editing,
On 2005-12-17, Michael Peters [EMAIL PROTECTED] wrote:
Brad Cathey wrote:
I'm writing a medium-sized web-based financial application that will have up
to 50 run modes between presenting empty forms, saving, editing, updating,
and deleting from them. Run modes *could* be broken down into
There was a thread here in October with a request for an example of a
simple implementation of CGI::App and Ajax. But then it went on and got
a little too complicated -- at least I don't see any implementations
simple enough for my skills in the followup posts :-) I'd particularly
like to see
I agree wholeheartedly with Mark. I've found this very helpful.
A discussion and some examples of the base and apps classes in use would be
great as well.
Brad
50 is definitely too much. There isn't a hard rule to follow for what is too
much, but I think there can never be too few. I usually
On Dec 17, 2005, at 1:48 PM, Bruce McKenzie wrote:
There was a thread here in October with a request for an example of a
simple implementation of CGI::App and Ajax. But then it went on and
got a little too complicated -- at least I don't see any
implementations simple enough for my skills in
Thanks. I didn't have any trouble getting the dox examples running.
What has me flummoxed is getting an onClick event attached to a submit
button that will do what I want it to -- not submit the form, but rather
send the changed fields to an external perl script (run mode?) and
confirm that the
On Sat, 17 Dec 2005 14:48:37 -0500, Bruce McKenzie wrote:
Hi Bruce
There was a thread here in October with a request for an example of
a simple implementation of CGI::App and Ajax. But then it went on
and got a little too complicated -- at least I don't see any
Yes, that's a pity.
I suggest
Thanks Fred -- that looks straightforward enough. However, the reason
I'm attracted to CGI::Ajax (formerly Perljax) is that (as I understand
the dox) you can do Ajax without knowing Javascript or XML :-)
The module is quite new, so if I manage to figure this out, maybe I'll
post my solution.
On 2005-12-18, Ron Savage [EMAIL PROTECTED] wrote:
On Sat, 17 Dec 2005 14:48:37 -0500, Bruce McKenzie wrote:
Hi Bruce
There was a thread here in October with a request for an example of
a simple implementation of CGI::App and Ajax. But then it went on
and got a little too complicated -- at
On 12/17/05, Brad Cathey [EMAIL PROTECTED] wrote:
I'm writing a medium-sized web-based financial application that will have up
to 50 run modes between presenting empty forms, saving, editing, updating,
and deleting from them. Run modes *could* be broken down into groups, e.g.,
these 4 deal
Ron Savage wrote:
o The synopsis has:
input type=text name=val1 id=val1
onkeyup=exported_func( ['val1'], ['resultdiv'] );
I think it would have been clearer to say:
name = some_name
so that you do not get the wrong idea about the usage of id.
Spot on, Ron! I got this note from
18 matches
Mail list logo
