Include &/or option in flatfile db query..

Discussion in 'Perl Misc' started by Oeln, Nov 17, 2003.

  1. Oeln

    Oeln Guest

    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
     
    Oeln, Nov 17, 2003
    #1
    1. Advertising

  2. (Oeln) wrote in news:ffde43bc.0311162254.298c4521
    @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?

    --
    A. Sinan Unur

    Remove dashes for address
    Spam bait: mailto:
     
    A. Sinan Unur, Nov 19, 2003
    #2
    1. Advertising

  3. Oeln

    Oeln Guest

    "A. Sinan Unur" <> wrote in message news:<Xns9437DD2BD3BC6asu1cornelledu@132.236.56.8>...
    > (Oeln) wrote in news:ffde43bc.0311162254.298c4521
    > @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.. ;)

    > > 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?
    >


    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.

    > > $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?
    >


    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..

    > >
    > > 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.


    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..
     
    Oeln, Nov 19, 2003
    #3
  4. Oeln <> wrote:
    > "A. Sinan Unur" <> wrote in message news:<Xns9437DD2BD3BC6asu1cornelledu@132.236.56.8>...
    >> (Oeln) wrote in news:ffde43bc.0311162254.298c4521
    >> @posting.google.com:


    >> > &output_header;
    >> > &output_open;

    >>
    >> 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.



    perldoc perlsub

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


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


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Nov 19, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ike
    Replies:
    5
    Views:
    3,216
  2. Bruce
    Replies:
    1
    Views:
    977
    Roedy Green
    Mar 21, 2006
  3. Julien ROUZIERES

    g++ -pg option and -shared option

    Julien ROUZIERES, Dec 21, 2004, in forum: C++
    Replies:
    1
    Views:
    774
    GianGuz
    Dec 21, 2004
  4. Andreas Bogenberger
    Replies:
    3
    Views:
    1,006
    Andreas Bogenberger
    Feb 22, 2008
  5. Randy
    Replies:
    5
    Views:
    123
Loading...

Share This Page