This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Rules Engine
Sam emails the group:
Rules
Date: July 6 To: Mike Foster, Al Sharpe, Teri Martin, Vijay Singh From: Sam Carlson Subject: Rules OK, so I know you all think this is unnecessary, but, well, you're wrong. In every project I have worked on, the client has invariably wanted something tweaked or changed the day we deliver. So, I want to build the flexibility to do intelligent processing without needing to recode right into this app. Here's what I mean: Right now all articles are displayed all the time, but what if users want some displayed based on the time of day? Or what if they want some articles excluded based on the geographical location of the user? Or what if . . . well, you get the idea. A rules engine is simply a way to let rules be applied at page-generation time. When the content management system generates content, it can check to see if any rules are associated with a category, and if so, execute the rule and include content- based on the value returned by the rule. We might not even use this thing now, but it won't be a lot of work to plug it in, and the first time the client asks for a "tweak" (BTW, I hate that word), we'll be able to provide it quickly and easily. The tricky part is the rules engine itself. There are a few ways to create one:The first option is the most usable, the second the most powerful, and the third somewhere in between (and my preference). Thoughts? Sam
- Have a defined set of rules. When content is created, there will be a form to fill in values for specific rules (for example, a user might pick "day of week" and enter 3 so the content shows up only on Tuesdays). The database stores these values, and when data is selected, the SQL statement used will filter out the rows that fail the rule. This type of interface is easy to create and use, but adding rules is a pain.
- The opposite extreme is to let users enter rules themselves; they write a little script that gets evaluated. For example, they'd enterDow(Now()) IS 3 for Tuesday, or something like that. The expression entered by the user is stored and evaluated when data is retrieved. This approach is really powerful—it allows for anything—but users have to knowscripting and function usage (and worse, we'd have to create a way to clean up their sloppy coding and mistakes).
- A middle ground is to have a quasi-finite set of rules; we have to write them ourselves and they are stored in a file (some sort of include file, maybe). What gets stored in the database is the name of the rule and the value to match against. So maybe the rule is named Day of Week, and the value associated with it is 3. We know somehow that Day of Week maps to a function we already wrote named dow(), and we evaluate that function and match it to the value. Users can't add their own rules easily (we have to do that for them), but it's easy to do, and we could keep adding rules without needing to make database changes. (Vijay will kill me if Idesign another app that requires him to write database migration scripts.)
Sam articulates the problem and solutions very well. Still, Mark is not convinced and responds to Sam's email:
Re: Rules
Date: July 6 To: Sam From: Mark Foster cc: Vijay, Teri, Al Subject: Re: Rules I like the idea. But I really don't think storing the names of external functions in a database is a good idea. What will you do if function names change or if code breaks? I'm not saying no, but I want to see how this will work. Mark
Sam takes Mark's email as a challenge, and experiments with ways to accomplish what he wants.