Understand: Customization Rules

SD Elements provides an extensible yet easy-to-use rules interface for defining when specific problems, tasks and how-tos appear in a project. Despite its simple appearance, the rules engine is sophisticated. This article describes how the rules engine works in detail.

Project Settings

Every time you open a rule editor, you will see the entire set of project settings laid out in a single, vertical list. The order of these settings mirrors their order when you click on the Project Settings button inside a project. The left side of the editor shows all of the sections and the right side shows the individual questions and answers. Subsections are not present in this view. You can select a specific answer to be part of the rule by clicking on it. By default, when you select more than one answer in a rule they are separated by AND clauses. You can also toggle Adding rule for when it is not selected, in which case every answer you select will be separated by AND NOT.


Figure 1: Project settings mapped to rules editor.


Boolean Operators

Rules are composed of project settings and Boolean operators. For example, a rule Application type - Web application AND Programming language - Java will evaluate to true in a given project if that project's settings include Application type - Web application and Programming language - Java. If either one of these settings are not present in the project, then the rule will evaluate to false. This means that the corresponding problem, task or how-to will not appear.

  • A OR B Means either A or B must be in the project for the rule to be true.
  • A AND B Means both A and B must be in the project for the rule to be true.
  • NOT A Means that A must not be in the project for the rule to be true.

You can define multiple rules for a single piece of content. Each individual rule is composed of ANDs and NOTs, and the rules together are separated by ORs. For example, suppose you want to create a rule to the effect of "Web applications with internal users or any application with external users", you would create two rules: One rule would be Application type - Web application AND Kinds of users - Internal users only. You would then click Save Rule and then Add Another Rule. The next rule would be Kinds of users Internal and external users. The resultant aggregate rule would be: (Application type - Web application AND Kinds of users - Internal users only) OR (Kinds of users - Internal users and external users)

Note that the OR clause is automatically selected whenever you click Add Another Rule.


Figure 2: Rules editor showing use of Boolean operators.


Internal Properties

In some cases, you will notice that the existing rules have certain settings called Internal Properties. These are properties that are used behind the scenes by SD Elements. For example, when you select Application type - Mobile client in a project, it automatically selects Internal Properties - The application is a generic client application behind the scenes.

Internal properties help create reusable rules in related contexts without overloading the end user. For example, there may be certain tasks that are true for any client application in a client server model, including desktop and mobile applications. Rather than asking the user to specify "Is this application a kind of client?", SD Elements automatically derives that information from the kind of application type the user selected.

You can use internal properties by selecting them from the 'Hidden' section in the rules editor.

Figure 3: Internal Properties function found in the rules editor.


Changes Since Last Release

Many of the rules for the original content include project settings from the Changes Since Last Release section. These rules help decrease the burden of completing tasks for new project releases. For example, task T7: Salt and hash stored password includes Changes since last release - Changes to authentication in its rule. This means that if authentication has not changed, then this task will not appear in a project. Using these settings in your rules helps keep subsequent releases more manageable.

NOTE: The Changes Since Last Release section only appears for new releases of existing projects. New projects that are not releases of existing projects hide the Changes Since Last Release section and automatically include all of the answers inside of that section. For example, Changes since last release - Changes to authentication is always included in the first project of an application. Keep this in mind if you include answers from this section in your rules.

Figure 4: Changes Since Last Release screen shot.
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request