Chad Perrin wrote:
: On Thu, Jun 22, 2006 at 03:07:32AM -0500, Charles K. Clarkson wrote:
::
::: OK, so here is the task. The first row I want to turn into
::: variable names. Machine, PurgeSuccess, etc.
::
:: You probably don't want to do that. You may end up needing
:: symbolic references to access those variables. Using symbolic
:: references is frowned on. Another approach might use a hash which
:: has keys that match the column names. The values associated with
:: those keys would reference arrays of values from all the records.
:
: I must be missing something. Please explain the sentence "You
: may end up needing symbolic references to access those variables."
Ralph wants to create variables named as columns. Since each
variable will hold an array, he will probably go with these.
@Machine,
@PurgeSuccess,
@PurgePrepared,
@PurgeStarted,
@PurgeCauseFaultID,
@PurgeModId,
@PurgeStopModId,
@ModIdJobCfg,
@NameJobCfg,
@Full_cfg,
@FinisherCfg,
@plex,
@PPM,
@PropID,
@AtreeNodeID,
@JobID,
@MediaID,
@Width,
@Height,
@Color, and
@Weight
Assume Ralph writes a generic program which allows the user to
define searches using column names. Problem: How do we use the
variable with only the column name? Assuming the column name is in
variable named $column_name, this comes to mind. Note that
@ModIdJobCfg cannot be lexically scoped. Neither can the other 20
variables above.
# For testing. Normally comes from user.
my $column_name = 'ModIdJobCfg';
# For testing. This data would normally come from a file.
our @ModIdJobCfg = 1 .. 3;
{
no strict 'refs';
print "$_\n" foreach @{ $column_name };
}
If we used a hash of arrays, we would be able to avoid
symbolic references. Note that we can also test for column name
availability easier with the hash as well.
# For testing. Normally comes from user.
my $column_name = 'ModIdJobCfg';
# For testing. This data would normally come from a file and
# contain more keys.
my %jobs = (
ModIdJobCfg => [ 1 .. 3 ],
);
print "$_\n" foreach @{ $jobs{ $column_name } };
: : Are you going to rewrite the script for each different
: : record search? How often will different searches be needed?
: : Who decides the need for new searches (you, the boss, other
: : programmers, users, etc.)?
:
: Why would he need to rewrite the script?
To do a significantly different search. If he's not rewriting
the script than he is creating his own query lanqage.
: Why couldn't it just loop through input data to (for instance)
: create an array containing each row, starting with the column
: headings row, then shift from each array to name new arrays from
: the column headings row and populate it in order from the other
: rows?
I was asking questions, not making statements. If the searches
are going to change regularly and if non perl programmers are
going to do the searches, then Ralph is basically creating his
own SQL language and a database may be a better solution. If only
perl programmers are going to do the searches then they can just
rewrite the script each time they do new search. I don't know what
Ralph needs, hence the reason for my questions.
: I'm not saying that's necessarily the best way to do it, but it
: seems like a reasonable example of how the script could just
: dynamically handle different data from each run if need be
: without having to rewrite it each time. Some search functions
: could be created that simply take input that allows for search
: terms to be specified when the script is run. Voila, it works.
: Did I misunderstand your point?
I wasn't making a point. I was asking for more information.
That's why all the sentences had question marks at the end.
HTH,
Charles K. Clarkson
--
Mobile Homes Specialist
Free Market Advocate
Web Programmer
254 968-8328
Don't tread on my bandwidth. Trim your posts.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
