Checking lots of conditions...ORed and ANDed

I have been working on a rather complex system recently, which lead me to talking to a lot of my collegues. Here is a piece that I got from those talks. :)

Problem: generate and display a complex interface/menu, which varies from user to user and depends on a number of options. There are plenty of conditions to check and there are multiple combinations of conditions that can produce the same result. The number of conditions and their combinations can grow and change over time. Heh, even describing this is complex. :)

Example:

if ($not_in_shift) {
  if ($current || !$past) {
    print "Register for shift\n";
  }
}
else {
  if ($current) {
    print "Confirm in shift\n";
    print "Remove from shift\n";
  }
  if ($past) {
    print "Confirm in shift\n";
  }
}
[download]

Even as it is, it already looks ugly. Adding few more conditions and combinations brings code to a real mess and makes it unmaintainable.

Solution: first the code, then explanation.

#!/usr/bin/perl -w
use strict;

# These can be filled by some function
my %conditions = (
    Current => 1,
    Not_in_shift => 1,
    Past => 0,
);

# Menu item to print if any set of conditions satisfies
my %menu =
            (
                'Add Self' => [
                    "Current,Not_in_shift",
                    "!Past,Not_in_shift",
                ],
            );

# No need to touch this stuff ever
for my $item ( keys %menu ) {
    for my $set ( @{$menu{$item}} ) {
        my $result = 1;
        for my $condition ( split(/,/,$set) ) {
            # Negating condition is a convenient thing to have
            if (substr($condition,0,1) eq '!') {
                substr($condition,0,1,'');
                ($result &&= !$conditions{$condition}) || last;
            }
            else {
                ($result &&= $conditions{$condition}) || last;
            }
        }
        if ($result) {
            add_menu_item($item);
            last;
        }
    }
}

# Whatever we want to do with the menu item
sub add_menu_item {
    my $item = shift;
    print "$item\n";
}
[download]

Basically, here we have a %conditions hash that contains the current status. It can be updated by a separate function. %menu contains all menu items that can be displayed. For each item, there is a list of combinations (strings). Each combination lists conditions that must true (or false, with negation) to satisfy. Any combination that satisfies all conditions causes the menu item to appear.

The good side of this solution is that it is obvious under which conditions which menu item will get displayed. It is easy to add more items, edit or delete existing ones, or temporarily hide menu items. Chances of making a mistake are lower and it is also possible to store the whole thing outside the code (like in the database or config file) and provide GUI menu editing functionlity. The possibilities are endless. :)

Update: One picture is a thousand words. Here is a screenshot from the running system.

Leonid Mamtchenkov aka TVSET

Comment on Checking lots of conditions...ORed and ANDed Select or Download Code

Replies are listed 'Best First'.
Re: Checking lots of conditions...ORed and ANDed by dragonchild (Archbishop) on Jun 08, 2004 at 01:53 UTC
I've put together the design for something similar and am waiting for project go-ahead at work to implement it. The design takes a different tack. There is a set of authorities which define every action a given user can take. Each user has a given set of authorities assigned to them. There is a given set of menu items which are all the items that can be put into a menu. Each menu item knows what authority(s) are necessary to have it displayed. A controller will have every menu item query the user object for its specific authority(s). The menu item determines if it should be displayed. So, when you create a new menu item, you have it (and only it) know which authority combination is required for it to be displayable. If you don't want a menu item to be shown, you simply have the controller not put it in the list for querying. Simple. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^2: Checking lots of conditions...ORed and ANDed by TVSET (Chaplain) on Jun 08, 2004 at 02:16 UTC
In my case, menus are very dynamic, depend on many factors and can change several times during the day. Consider managing a schedule for few people for few shifts (24x7 network operations center). Checking who is allowed to do what, has been already done. It is one level above this code. ;) Leonid Mamtchenkov aka TVSET	[reply]
Re^3: Checking lots of conditions...ORed and ANDed by dragonchild (Archbishop) on Jun 08, 2004 at 11:50 UTC
Ok. So, have the menu item know what factors affect its ability to display itself. shrugs Just because you've handled the problem I describe solving doesn't mean the algorithm wouldn't be helpful in solving what you're looking to do. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re^4: Checking lots of conditions...ORed and ANDed by TVSET (Chaplain) on Jun 08, 2004 at 20:07 UTC
Re: Checking lots of conditions...ORed and ANDed by baruch (Beadle) on Jun 08, 2004 at 03:06 UTC
I hesitate to mention it, but this is an ideal situation for using Boolean algebra to reduce the number of conditions. It sounds terrible, but the rules aren't all that difficult, and it's well worth the effort of learning (assuming you'll be doing much of this sort of complicated work with conditionals). רוּךבּ	[reply]
Re^2: Checking lots of conditions...ORed and ANDed by hardburn (Abbot) on Jun 08, 2004 at 12:37 UTC
Boolean algebra would simplify the conditions. Polymorphisim could obliviate them all together. I'm not entirely certain how it would apply to this specific information (as I suspect I do not fully understand the OP's problem), but this is generally the case. Still, you get a ++ from me for bringing up a concept which is significantly undervalued. Besides, Boolean algebra is fun :) ---- send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.	[reply]
Re^3: Checking lots of conditions...ORed and ANDed by TVSET (Chaplain) on Jun 08, 2004 at 20:22 UTC
as I suspect I do not fully understand the OP's problem One picture is a thousand words. Here is the screenshot of the actual system. I have opened one of the menus also. Menus differ with each cell. This should help you understand better what I mean. :) Leonid Mamtchenkov aka TVSET	[reply]
Re^2: Checking lots of conditions...ORed and ANDed by tbone1 (Monsignor) on Jun 08, 2004 at 12:30 UTC
I'll back Baruch on this. It's compact, quick, and fairly flexible. Remember, there are times when code has to be complex. The world is complex and sometimes you just have to deal with it. -- tbone1, YAPS (Yet Another Perl Schlub) And remember, if he succeeds, so what. - Chick McGee	[reply]
Re: Checking lots of conditions...ORed and ANDed by NetWallah (Canon) on Jun 08, 2004 at 17:12 UTC
You might want to take a look at Deterministic Finite Automata. I have not used this in perl, but the concept is simple and logical, and avoids a lot of programming errors - config errors are discovered and corrected easier than hard-coded condition errors. Offense, like beauty, is in the eye of the beholder, and a fantasy. By guaranteeing freedom of expression, the First Amendment also guarantees offense.	[reply]
Re: Checking lots of conditions...ORed and ANDed by stvn (Monsignor) on Jun 08, 2004 at 17:38 UTC
I have to agree with NetWallah, this sounds like a you need a state-machine. Which is really what you have started doing already, although in a highly specific way. Your approach and code can only benefit from reading some of the theory about it, since it is a rather highly developed concept. There are a number of resources on the web for such things, and surely there is a CPAN module out there which would suit your needs. -stvn	[reply]
Re: Checking lots of conditions...ORed and ANDed by Solo (Deacon) on Jun 09, 2004 at 16:21 UTC
If you're conditions are simple enough, turning your structure inside-out will help I think. my $rules = { 'not in shift' => { allows => [ 'Register for shift', ], }, 'in shift' => { allows => [ 'Confirm in shift', 'Remove from shift', ], }, # 'current' => { # nothing seems to depend on current # }, 'past' => { disallows => [ 'Remove from shift', 'Register for shift', ], }, }; sub get_menu_items { my ($rules,@conditions) = @_; my %results; for my $cond ( @conditions ) { next unless exists $rules->{$cond}; # irrelevant condition for $item ( @{$rules->{$cond}->{allows}} ) { $results{$item}++; } for $item ( @{$rules->{$cond}->{disallows}} ) { delete $results{$item}; } } return keys %results; } my @conditions = ( ['in shift', 'past' ], ['in shift', 'current' ], ['not in shift', 'past' ], ['not in shift', 'current' ], ); for (@conditions) { my @result = get_menu_items($rules,@$_); print "Conditions: " . join(',',@$_) . "\n" . "Menu items: " . join(',',@result) . "\n\n"; } [download] And the results: `Conditions: in shift,past Menu items: Confirm in shift Conditions: in shift,current Menu items: Remove from shift,Confirm in shift Conditions: not in shift,past Menu items: Conditions: not in shift,current Menu items: Register for shift` [download] This may just be a cheap application of others' suggestions to use boolean algebra and a state machine (or maybe not). I'm just a fan of code examples. I DO think this is a very natural way for people to express rules in external config files. --Solo -- You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.	[reply] [d/l] [select]
Re^2: Checking lots of conditions...ORed and ANDed by TVSET (Chaplain) on Jun 10, 2004 at 06:36 UTC
It's a neat piece of code. ;) I still prefer my though due to two reasons: It is more obvious which conditions need to be satisfied for the menu to get displayed. Each menu caption is written only once. It is easier to maintain interface consistancy. Thank you for the idea anyway. Leonid Mamtchenkov aka TVSET	[reply]
Re^2: Checking lots of conditions...ORed and ANDed by Solo (Deacon) on Jun 15, 2004 at 14:32 UTC
My above code has a nasty habit of allowing things it shouldn't depending on the order of the conditions. Assuming that 'disallow' rules trump 'allow' rules, here is a quick fix. `sub get_menu_items { my ($rules,@conditions) = @_; my %results; for my $cond ( @conditions ) { next unless exists $rules->{$cond}; for $item ( @{$rules->{$cond}->{allows}} ) { $results{$item}++; } } for my $cond ( @conditions ) { next unless exists $rules->{$cond}; for $item ( @{$rules->{$cond}->{disallows}} ) { delete $results{$item}; } } return keys %results; }` [download] --Solo -- You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.	[reply] [d/l]
Re: Checking lots of conditions...ORed and ANDed by andyf (Pilgrim) on Jun 10, 2004 at 08:56 UTC
If you follow Baruch and Netwalla towards a state machine with bool xformation matrix and your form code for the 'edge' functions, you might find these worth looking at to help build it. The best advantage to going down this road is _not_ to simplify your code. It is removing the state transitions from the code altogether, no hardwired logic code, just a conf file of transitions. Math::MatrixBool StateMachine::Gestinanna	[reply]


Do you know where your variables are?
	PerlMonks