Rails on Rules: Example

June 25, 2007

I was just speaking with my friend Sami Samhuri about use cases for the rule engine. I imagined this scenario:

You've got a page that lists objects that are authored by many people. You have [a set of] reusable components/helpers/partials for displaying the objects in the list.

You want edit/delete links to appear for objects that were authored by the current user. You could imagine something like this in the template that uses the reusable component or in the reusable component itself:

if object.owner == session.current_user { display_edit_and_delete_links }

That's easy to code and maintain, and it can be refactored into a controller without much hassle.

But you might have dozens of pages that list completely unrelated types of objects. And then you get a requirement to add support for editorial workflow. Now you need to allow other people to edit/delete the object, not just the owner. The business rules (you see how this makes sense?) is not longer as simple as "if object.owner == session.current_user", but they do apply application-wide.

Change the "if" check to:

if context.shouldDisplayEditAndDeleteLinks { display_edit_and_delete_links }

Now the business logic is decoupled from the display logic, and the decision making can make augmented without changing application code. Just provide rules:

Note, the scenario below is simple, clearly a more robust "role" design would be desirable - but part of the point is "role" is an application concept, not a rule engine concept. Also note the (numbers) next to the rules: these are the priority of the rule, which make it easy to say one rule is more important than another.

Base rules that specify the role in the current context:

*true* => role = 'public' (10)

(session.current_user.is_editor = true) => role = 'editor' (50)

(session.current_user.is_manager = true) => role = 'manager' (60)

Base/original rules for displaying edit and delete links:

*true* => shouldDisplayEditAndDisplayLinks = false (10)

(object.owner = session.current_user) => shouldDisplayEditAndDisplayLinks = true (50)

New rules to support editors editing objects:

(role = 'editor') => shouldDisplayEditAndDisplayLinks = true (100)

New rules for important exceptions to the above:

(entity.name = 'SecurityNotice') => shouldDisplayEditAndDisplayLinks = false (1000)

((entity.name = 'SecurityNotice') and (role = 'manager')) => shouldDisplayEditAndDisplayLinks = true (1010)

If we weren't using rules, we would have had to write some pretty complicated code to cover all of these (and future) cases, and duplicate that code in many places or augment the application design (in many places) to inherit/mixin the code, or augment the application design (in many places) to have an entry point that could call a centralized routine that implemented all that logic.

When you think of all the places in your application you have complicated business rules that require application logic to implement, and how much the support of these business rules governs your application design to make it easy to implement/maintain, it becomes easy to see how this approach simplifies application design and improves productivity.

June 6, 2007

FYI, rules look something like this:

*true* => itemHelperName = "DefaultItemHelper"

(task = 'inspect') => itemHelperName = "InspectItemHelper"

(task = 'list') => itemHelperName = "ListItemHelper"

((task = 'list') and (entity.name = 'Post')) => itemHelperName = "MyCustomListPostHelper"

Note that this example is VERY contrived for the purposes of a really simple example. Presumably the first three rules would be supplied by a system that included generic scaffolding templates, and the last rule would be supplied by the application developer to provide more specific blog listing rendering functionality.

Also note that I'm reusing some of Direct To Web's terminology above, specifically "task" and "entity".