Re: •Re: Sub call isn't returning values

Thank you for your suggestions. You are, without question, correct. This code is kludgy (at best). However, it does work in every instance but the one described. Given my deadline (which has passed, and testing is to begin with my customers on March 17th), it was the best I could come up with (as a beginner) and still make the boss happy.

I did try to use CGI::Session but had difficulty in getting that to work (see previous posts). I've been told not to use cookies or put the variables in the URL... so that left me with hidden variables (for now). Once the dust settles, I hope to drop back in to looking at a better way of maintaining persistence with these variables I need to track.

Believe me, I'm embarrassed by the lack of elegance of the code. I am very aware of how ugly and hard-to-maintain it is right now.

The variables involve numerous fields (we call them attributes) that appear on each page, plus a lot of them are used to narrow down the SQL criteria for subsequent database calls. If I had more time and more knowledge, I think I'll be able to improve the code to something a little less of an embarrassing first attempt.

The &call_vars sub was my attempt to bundle all my variables in a concatenated string to pass from page to page via a hidden field. I don't know how create a hash ref and treat the values as a bundle as you suggested.

Lori

Comment on Re: •Re: Sub call isn't returning values

Replies are listed 'Best First'.
Re: Re: •Re: Sub call isn't returning values by Grygonos (Chaplain) on Mar 02, 2004 at 19:16 UTC
The following code creates a hash and its reference. It prints from both showing that it is in fact referencing the hash. You should check perldata to get started `#!/usr/bin/perl use strict; use warnings; my %hidden = (var_name1 => 'var_value1', var_name2 => 'var_value2'); my $hidden_ref = \%hidden; print $$hidden_ref{var_name1}; print $hidden{var_name1};` [download] Grygonos	[reply] [d/l]