Screams lookup table to me ...

sub validate { return ($_[0] < $_[1]) }

%lookup = {
             '0000'  => &validate($start,$end),
             '0001'  => false,
             '0010'  => false,
                .
                .
                .
             '1111'  => &validate($start,$end)
          };
   .
   .
   .

if ($lookup{$switch_binary})
{
   # Result is valid
}  
else
{
   # Call user a pudding-head
}
[download]

As for testing the menus ... You have 5 valid states. Either you're in a valid state or you're not. Test for the five valid states using if-elsif, and else for your invalid states. Something like:

if ( --VALID STATE 1, 0000--) {
    # Do something here
}
elsif ( --VALID STATE 2, 1000--) {
    # Do something here
}
elsif ( -- And so on for your 5 valid states) {
}
else {
    # This is where your 11 INVALID states drop down.
    # Does it really matter *which* invalid state it is?
}
[download]

If you need more help, please don't hesitate to ask for clarification.

if (valid_state($pull_downs) && $start_time < $end_time) {
    # okay; put processing here
} else {
    # not okay: yell at user.
}
[download]

For this to work, we need to satisfy some conditions. First, we need to bump all the pull-downs together; and second, we need the start and end times to be in some comparible format. Fortunately, these are both easy tasks. Then we have to write the valid_state functions, which isn't hard either.

# put this before the if mentioned above
my $pull_downs = join "", $pull_down1, $pull_down2, $pull_down3, $pull
+_down4;

# or, if you're using CGI.pm, something like this:
my $pull_down = join "", map { $query->param("pull_down$_") } 1 .. 4;

# (whatever works; just mash them together. $pull_downs now looks like
+ your binary numbers.


# And this returns true only if the number is one of your valid ones:

{
  my $valid = qr/^(0000|1000|1010|1100|1111)$/;
  sub valid_state {
    return shift =~ $valid;
  |
}
[download]

You may need to do a little extra work to binarify the data from the pull-down to your internal format, but that shouldn't be too daunting by now. As for the times, a good way of making them compatible is to translating them (say, with DateTime) to epoch seconds. These are simply two numbers, the bigger one represents a later time.

$is_valid = ($a ? ($d ? $b && $c : !$b && !$c || !$b && $c || $b && !$
+c) : !($b && $c && $d);
[download]

Use a hash as a state table.

You'll have to fill in how you get your 0s and 1s and concatenate them, and getting your times into comparable format (seconds since...).

#! perl -slw
use strict;

my %states = (
    0000 => 1, 0001 => 0, 0010 => 0, 0011 => 0,
    0100 => 0, 0101 => 0, 0110 => 0, 0111 => 0,
    1000 => 1, 1001 => 0, 1010 => 1, 1011 => 0,
    1100 => 1, 1101 => 0, 1110 => 0, 1111 => 1,
);

my $state = ....; ## Get state from wherever?

if( $states{ $state } ) {
    ## Validate values
    my( $startTime, $endTime ) = ...; ## Get times
    if( $startTime < $endTime ) {
        ## Do it
    }
    else {
        ## Reject.
    }
else {
    ## Reject.
}
[download]

BTB. If specifying just start and end hour is valid, why isn't specifying start hr/min and just end hr (1110) also valid? Eg. Start:10:45 * End: 11

# Tests the start_hour, start_minute, end_hour, and end_minute
# pulldowns to verify that a consistent set of them have been
# specified, and that the start time (if specified) is before
# the end time.
sub validate_date_pulldowns {
  if (defined(param('end_hour'))) {
    return 0 unless defined(param('start_hour'));
    return 0 if param('start_hour') > param('end_hour');
  }
  if (defined(param('start_minute'))) {
    return 0 unless defined(param('start_hour'));
  }
  if (defined(param('end_minute'))) {
    return 0 unless defined(param('start_minute'));
    return 0 unless defined(param('end_hour'));
    return 0
      if param('start_hour') == param('end_hour') and
         param('start_minute') > param('end_minute');
  }
  return 1;
}
[download]

Update: Note that the key idea is my strategy of turning many combinations of conditions into a set of "guard conditions" on which you exit early. I've found that this strategy often converts deep nested decision trees into a series of fairly straightforward decisions (as above).

Toward this purpose I created Set::CrossProduct. Instead of figuring out all the combinations, I have a bunch of anonymous arrays that specify possible values for each input. The module handles everything and hands me one set of inputs at a time. You call them "guard conditions" and I call them "boundary conditions".

In this case, there are only 16 combinations, but I've been able to work with thousands of combinations without making the test code huge.

--
brian d foy <bdfoy@cpan.org>

Automation is good. It would have avoided the bug that I had in my code above. (If end_minute is not defined, you aren't allowed to have both start_minute and end_hour defined.)

Binary isn't normally good for scheduling (I've done a bunch with pulldowns recently) because what if you want to add quarter-hour resolution, etc. Anyway, assuming we have to deal with this binary code and you have it nicely padded so it is always 4 digits. So we have yummy binary! This says to me:

Valid states:
0000 0
1000 8
1010 10
1100 12
1111 15

So I parsed the binary and broke it into bits. Intentionally left no comments so you can learn from it in case this is homework. As for bounds checking, if you only need to check time0 < time1 then why not convert hours to minutes? (Not done here)

#!/usr/bin/perl -w

use strict;
my $str;
my @test = ("0000","0001","0010","0011",
        "0100","0101","0110","0111",
        "1000","1001","1010","1011",
        "1100","1101","1110","1111");
my @accepted = (0,8,10,12,15);

for my $t (@test) {
  print "Input: $t\tTested: ";
  print "[" . parsebin($t) . "] " ;
  print validinput($t,\@accepted);
  print "\n";
}

sub validinput {
  my $in = shift;
  my $r = shift;
  return 1 if xinset(parsebin($in),$r);
  return 0;
}

sub xinset {
  my $x = shift;
  my $set = shift;
  #print "X $x SET" . join(" / ",@$set). "\n";
  for my $y (@$set) {
    return 1 if $x == $y;
  }
  return 0;
}

sub parsebin {
  # parse a string of ones and zeroes
  my $str = shift;
  my $total = 0;
  my $power = 0;
  for my $i (1..length($str)) {
    $total += 2 ** $power if substr($str,-1 * $i,1);
    $power++;
  }

  return $total;
}
[download]

Anything done in Javasript in a browser can and will be subverted by a malicious user, or will break on certain browsers, or will simply not be executed when users have disabled Javascript, or will get blocked by content filters, or ...

Sure, use Javascript if you want to be nice and friendly and give instant feedback on errors, but TEST TEST TEST so that it doesn't break hideously in browsers other than the one you habitually use. And even then, you must also validate the data on the server, lest you have a nasty user like me trying to break your data. Of course, using Javascript means you need to do at least twice as much work - you need to write and test and maintain Javascript as well as writing and testing and maintaining perl. Does your employer really want you to do that?