I've been looking at the problem with param that I have below. I
downgraded both CGI to 2.77 and CGI::App to 2.0, but to no avail.
It looks like there's a function in CGI.pm called rearrange() that
moves the parameters around, and that's where the problem seems to
be. What's happening appears to be that there are 3 parameters passed
in originally (to param) and instead of shifting to self the original
reference, it's just assigned to a local variable, so that when the
tests are done on the function's input, that third parameter figures
into the logic.
Essentially, it's taking the second parameter ($key) as both the $key
and $value, instead of assigning the third parameter to value.
It appears on or about 294 - 296 in CGI.pm:
>>>>>>>>>>>>>CGI::param
#### Method: param
# Returns the value(s)of a named parameter.
# If invoked in a list context, returns the
# entire list. Otherwise returns the first
# member of the list.
# If name is not provided, return a list of all
# the known parameters names available.
# If more than one argument is provided, the
# second and subsequent arguments are used to
# set the value of the parameter.
####
sub param {
my($self,@p) = self_or_default(@_);
return $self->all_parameters unless @p;
my($name,$value,@other);
# For compatibility between old calling style and use_named_parameters() style,
# we have to special case for a single parameter present.
if (@p > 1) {
($name,$value,@other) = rearrange([NAME,[DEFAULT,VALUE,VALUES]],@p);
#****>>>>>> Here $name and $value get the wrong values.
Anybody have any ideas about this or is it a known problem?
Thanks,
=Eric.
Steve Comrie: [Wednesday 21-November]:
> Hrm, I'm not sure exactly what's going on here. I heard there's been a
> change to the way param() functions in the 2.1 version of CGI::App, so it
> might be my fault for not testing App::Login and App::Session on the latest
> version of CGI::App (I think I'm still running 1.3 or something).
>
> Try going back to CGI::App v2.0 and see if the problem persists, then we can
> have a better idea of where exactly the problem is occuring.
>
> btw. Glad you like the App::Login & App::Session modules. If more people
> start using them I'll tidy of the code and the object interface, add more
> documentation and release them officially.
>
> ===
> steve comrie :: senior developer
> www.shrinkingplanet.ca
>
> ----- Original Message -----
> From: "Eric Berg" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Tuesday, November 20, 2001 11:25 PM
> Subject: [cgiapp] Problem setting session_dir
>
>
> > Steven, Jesse & Friends,
> >
> > I'm having a problem using the param() method from CGI::Application as
> > inherited by CGI::Application::Session and CGI::Application::Login.
> >
> > Basically, in the following example, I'm having a problem, because
> > though the internal data reflects a correct value for the
> > 'session_dir' parameter as set below, the param('session_dir) method
> > returns 'session_dir'.
> >
> > * Put the following line in the cgiapp_init() function for your main
> program app:
> >
> > $self->param( 'session_dir' => '/dir/to/save/session/files' );
> > print STDERR Dumper($self), "\n"
> > unless ( $self->init_session( 'name_of_cookie' ) ) {
> > $self->header_type('redirect');
> > $self->header_props( -location =>
> 'http://location/of/login.cgi' );
> > return;
> > }
> >
> >
> > I used Dumper above from my beloved Data::Dumper module to dump $self,
> > and come up with a correct value for session_dir:
> >
> > '__PARAMS' => {
> > 8<8<8<
> > 'session_dir' => '/tmp/sessions',
> > ...
> >
> > Which is great, but I can't get the value of 'session_dir'. Does it
> > happen with other parameters, not sure...I just checked 'user' and
> > it's happening for that one too.
> >
> > I'm using $CGI::Application::VERSION = '2.1'; and the version of the
> > CGI::Application::Session and Login stff that's up on the site today
> > (20 Nov 2001).
> >
> > So, I'm pretty sure there's something wanky with param() not returning
> > the right value, but I can't figure out why.
> >
> > i've got to show my client something tomorrow, and I'd love it to
> > contain the login stuff. I think this module is cool. It was easy to
> > use my AuthenticatedUser.pm, populate my user object based on the
> > username passed in on the form, and validate the form password against
> > the database password. Cake! Thanks.....er...but what's going on.
> >
> > Now, it's sleep or beer, then sleep. I think it's beer, then sleep.
> >
> > Thanks, folks.
> >
> > -Eric.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
