Include &/or option in flatfile db query..

[Oeln]

I've got a flat text file db (tab delimited) & a form that lets one
query it online. In its current incarnation, it only lets one input a
term to look for in the file, & outputs the lines in the file which
include that term. If the input 'term' incldes ' ', it considers it
one term. I'd like to increase its functionality by including the &/or
option (&, of course, therefore identifying each term input to the
form individually).

The form that includes the query option:

<form method="post" action="cgi-bin/odb.pl">
<input type="text" name="input">
<input type="hidden" name="oper" value="query">
<input type="submit" value="Okay">
<input type="reset" value="Clear">
</form>

In odb.pl I've got the following in order to parse the form itself:

if ($ENV{'REQUEST_METHOD'} eq 'POST') {
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs)
{
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$contents{$name} = $value;
}
}

I've then got, in order to do the query, the following:

if ($contents{'oper'} eq "query") {
open (FILE, "$odb") || do {&no_open;};
&output_header;
&output_open;
$count=0;
@ordered = sort(<FILE>);

foreach $pair (@ordered) {
if ($pair =~ /$contents{'input'}/gi) {
$count++;
@item = split(/\t/, $pair);
&output_item;
}
}
if ($count==0) {
# print " ";
}
close(FILE);
&output_close;
&output_footer;
exit;
}

It works fine like this: I've got no issues with it other than it's
lack of the &/or option. In order to offer this, I'd obviously include
in the form itself an 'option' field, in order to let one indicate
&/or: i.e.,

<form method="post" action="cgi-bin/odb.pl">
<input type="text" name="input">
<input type="radio" name="option" value="and">&amp;
<input type="radio" name="option" value="or">or
<input type="hidden" name="oper" value="query">
<input type="submit" value="Okay">
<input type="reset" value="Clear">
</form>

I've gone over the original code I've got, & changed it to be the
following instead:

if ($contents{'oper'} eq "query") {

@inputs = split(/\s+/, $contents{'input'});

# $odb file location is identified elsewhere
open(FILE,"$odb") || do {&no_open;};
@ordered = sort(<FILE>);

foreach $pair (@ordered) {
# &
if ($contents{'option'} eq "and") {
foreach $input (@inputs) {
if (!($pair =~ /$input/i)) {
$include{$pair} = 'no';
last;
} else {
$include{$pair} = 'yes';
}
}
# or
} elsif ($contents{'option'} eq "or") {
foreach $input (@inputs) {
if ($pair =~ /$input/i) {
$include{$pair} = 'yes';
last;
} else {
$include{$pair} = 'no';
}
}
}
}

&output_header;
&output_open;

foreach $key (keys %include) {
if ($include{$key} eq 'yes') {
$count++;
@item = split(/\t/, $pair);
&output_item;
}
}
if ($count == 0) {
# print " ";
}

&output_close;
&output_footer;

close(FILE);
exit;
}

I'd imagine this would identify the individual terms in the 'input'
field, & then, for each line in the file it would look for an
occurence of one of the input terms. If the option indicated were
'and', it would look for an instance of a term not incl. in the line &
if it found one, it would not include that line in output (the
opposite would then occur for 'or') in order for it to be a little bit
faster than looking for each term. I guess for now though I'm less
interested in it being fast than in getting it to work.

The interesting thing is this: I've got the following it &output_item:

sub output_item {
print <<"OUTPUT";
<tr>
<td>$item[0]</td>
<td>$item[1]</td>
<td>$item[2]</td>
</tr>
OUTPUT
}

In the output I'm getting now, there is an increase in table cells if
I've input a term that ought to be found in the text file. If I input
a term that it won't find, it gives me no table cells. I'm getting
this impression by looking at the table border outline cells in the
output - it's like it's finding the items in the file & outputting
empty table cells like I've indicated if it finds a term; but it's not
including the text in $item[0], $item[1], etc. I've got no idea why,
or where the issue is, if I'm overlooking the obviuos or not..

- Noel

 

[A. Sinan Unur]

(e-mail address removed) (Oeln) wrote in @posting.google.com:

I've got a flat text file db (tab delimited) & a form that lets one
query it online. In its current incarnation, it only lets one input a
term to look for in the file, & outputs the lines in the file which
include that term. If the input 'term' incldes ' ', it considers it
one term. I'd like to increase its functionality by including the &/or
option (&, of course, therefore identifying each term input to the
form individually).

The form that includes the query option:

<form method="post" action="cgi-bin/odb.pl">
<input type="text" name="input">
<input type="hidden" name="oper" value="query">
<input type="submit" value="Okay">
<input type="reset" value="Clear">
</form>

In odb.pl I've got the following in order to parse the form itself:

if ($ENV{'REQUEST_METHOD'} eq 'POST') {
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs)
{
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$contents{$name} = $value;
}
}

Hmmmm ... Gunnar, if you need any more proof that my objection this code
from the "arrange form data in same order as on form" thread was based on
the fact that it seems to be very prolifically copied and pasted by
clueless people, look no further.

I've then got, in order to do the query, the following:

if ($contents{'oper'} eq "query") {
open (FILE, "$odb") || do {&no_open;};
&output_header;
&output_open;

Do you know why you have an ampersand preceding the function calls?

$count=0;
@ordered = sort(<FILE>);

Is reading the whole file in really a good idea? And, if you are going to
read the whole file in and, still go through each item, why are you sorting
the lines?

foreach $pair (@ordered) {
if ($pair =~ /$contents{'input'}/gi) {
$count++;
@item = split(/\t/, $pair);
&output_item;
}
}

This is the point I get impatient and frustruted and ignore the rest of
your post. Instead of writing in a prose style and expecting your readers
to figure out how multiple bits of code relate to each other, you should
try to include self contained code and data others can try out to see
what's happening as well as what expect the code to do etc etc. Please see
the posting guidelines posted here regularly.

perldoc -q intersection

might help.

The interesting thing is this: I've got the following it &output_item:

sub output_item {
print <<"OUTPUT";
<tr>
<td>$item[0]</td>
<td>$item[1]</td>
<td>$item[2]</td>
</tr>
OUTPUT
}

In the output I'm getting now, there is an increase in table cells if
I've input a term that ought to be found in the text file. If I input
a term that it won't find, it gives me no table cells. I'm getting
this impression by looking at the table border outline cells in the
output - it's like it's finding the items in the file & outputting
empty table cells like I've indicated if it finds a term; but it's not
including the text in $item[0], $item[1], etc. I've got no idea why,
or where the issue is, if I'm overlooking the obviuos or not..

who knows?

do you have

use strict;

and

use warnings;

at the top of your code?

 

[Oeln]

(e-mail address removed) (Oeln) wrote in @posting.google.com:

I've got a flat text file db (tab delimited) & a form that lets one
query it online. In its current incarnation, it only lets one input a
term to look for in the file, & outputs the lines in the file which
include that term. If the input 'term' incldes ' ', it considers it
one term. I'd like to increase its functionality by including the &/or
option (&, of course, therefore identifying each term input to the
form individually).

The form that includes the query option:

<form method="post" action="cgi-bin/odb.pl">
<input type="text" name="input">
<input type="hidden" name="oper" value="query">
<input type="submit" value="Okay">
<input type="reset" value="Clear">
</form>

In odb.pl I've got the following in order to parse the form itself:

if ($ENV{'REQUEST_METHOD'} eq 'POST') {
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs)
{
($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$contents{$name} = $value;
}
}

Hmmmm ... Gunnar, if you need any more proof that my objection this code
from the "arrange form data in same order as on form" thread was based on
the fact that it seems to be very prolifically copied and pasted by
clueless people, look no further.

I'm inferring there's an issue with this code? It could be..it was in
the original code I was given & I've not changed it; but I'm not
certain if that's what you're implying or not. I'll own up to being
clueless - it's my intent to overcome the ignorance that incited my
inquiry..

Do you know why you have an ampersand preceding the function calls?

I figured it was only to indicate it was a function call. Otherwise,
no. I'd be interested though; I'll look for info on that.

Is reading the whole file in really a good idea? And, if you are going to
read the whole file in and, still go through each item, why are you sorting
the lines?

It's the only option I'm even a little bit familiar with I guess. It's
a flatfile - if it got too large it would no longer be a good idea
inherently; therefore, I guess it's not overly important to me if its
optimized or not (I'd only ever go with a flatfile in the first place
if I intended for it not to get too large).

It orders the output - I'd like to offer this as an option, too (i.e.,
"identify the field to order by"); but I've not gotten that far with
it yet..

This is the point I get impatient and frustruted and ignore the rest of
your post. Instead of writing in a prose style and expecting your readers
to figure out how multiple bits of code relate to each other, you should
try to include self contained code and data others can try out to see
what's happening as well as what expect the code to do etc etc. Please see
the posting guidelines posted here regularly.

I've looked at the guidelines from 11/18. If I'm not clear on them,
it's not that I'm not intentionally ignoring them. I'd be fully open
to clarification; but I intended certainly to offer "enough [but not]
too much information", & to identify the issue (& the objective) I've
got in a concise, intelligible way. I'd be glad to include the whole
file; but I figured that would be inconsiderate in comparison to
isolating the code in which I'd guessed the issue was. Instead of
this, I could include links to the files instead (including an example
of the flatfile itself)? I'm not certain if that would be considered
ideal, or inconvenient, by others..

perldoc -q intersection

might help.

Only info I got from that was example code, compared to an 'xor
operation'. It could be that I'm not getting it, of course; but I'd
guess it isn't what I'm going for..

The interesting thing is this: I've got the following it &output_item:

sub output_item {
print <<"OUTPUT";
<tr>
<td>$item[0]</td>
<td>$item[1]</td>
<td>$item[2]</td>
</tr>
OUTPUT
}

In the output I'm getting now, there is an increase in table cells if
I've input a term that ought to be found in the text file. If I input
a term that it won't find, it gives me no table cells. I'm getting
this impression by looking at the table border outline cells in the
output - it's like it's finding the items in the file & outputting
empty table cells like I've indicated if it finds a term; but it's not
including the text in $item[0], $item[1], etc. I've got no idea why,
or where the issue is, if I'm overlooking the obviuos or not..

who knows?

do you have

use strict;

and

use warnings;

at the top of your code?

I increasingly feel like I ought to include the whole code in order to
be informative - it's only that it's long enough that I'd be inclined
not to if it that were an option. One way or the other, I'll look for
further info on this first. I'm not interested in wasting others'
time.

Thanks for the input..

 

[Tad McClellan]

I figured it was only to indicate it was a function call. Otherwise,
no. I'd be interested though; I'll look for info on that.

perldoc perlsub

&NAME; # Makes current @_ visible to called subroutine.


Did you _want_ to make the current @_ visible to called subroutines?