Conditions

PRO

Conditions allow you to choose with granularity when to execute actions or display informations. They can be use inside components or monitors but also in actions Conditions mainly work with variables. This can be input variables, retrieved when the user entered some data, or general variables that you defined yourself. A condition is a string which will evaluated at runtime by the application. This way, you can easily chain conditions, but still being able to understand it. Here are the exhaustive list of the available operators and operands.

Operators

Comparison operators

Logic operators

Operands

You can compare a variable and an operand with a comparison operator. There are four types of operands.

Examples

Given the following variables, here are some examples:

Variables:

Expressions

Conditionally insert or remove components or monitors

You can add a condition to any component. Octory will smoothly animate the insertion or removal of the component, depending on the result of the condition evaluation.

For example, if you define a ListInputComponent to ask the user their role in the company:


    <dict>
        <key>Type</key>
        <string>Input</string>
        <key>InputType</key>
        <string>List</string>
        <key>Variable</key>
        <string>UserRole</string>
        <key>Items</key>
        <array>
            <string>Consultant</string>
            <string>Manager</string>
            <string>Department Manager</string>
            <string>Director</string>
        </array>
    </dict>
    

You can then display a TextComponent only for the director role, like this:


    <dict>
        <key>Type</key>
        <string>Text</string>
        <key>Text</key>
        <string>I want a raise!</string>
        <key>Condition</key>
        <string>UserRole == "Director"</string>
    </dict>
    

Or you can display an input component only for the Consultant and Manager roles with the contains operator <: (the space between the two signs in the example is just here to avoid a wrong syntax colorization):


    <dict>
        <key>Type</key>
        <string>Input</string>
        <key>InputType</key>
        <string>Text</string>
        <key>Condition</key>
        <string>"Consultant, Manager" < : UserRole</string>
        <key>Label</key>
        <string>Who is your manager?</string>
        <key>Variable</key>
        <string>UserManager</string>
    </dict>
    

If you define a variable in GeneralVariables like NonDirectorRoles: "Consultant, Manager", you could simply write the last component this way:


    <dict>
        <key>Type</key>
        <string>Input</string>
        <key>InputType</key>
        <string>Text</string>
        <key>Condition</key>
        <string>NonDirectorRoles < : UserRole</string>
        <key>Label</key>
        <string>Who is your manager?</string>
        <key>Variable</key>
        <string>UserManager</string>
    </dict>
    

It is a good practice to store all your variables in the Variables array to avoid to repeat yourself, which is error prone. That said, you can even store conditions in the Conditions array to avoid to repeat this condition in several components:


    <array>
        <key>IsUserNotADirector</key>
        <string>NonDirectorRoles < : UserRole</string>
    </array>
    

Finally, your component would appear even clearer:


    <dict>
        <key>Type</key>
        <string>Input</string>
        <key>InputType</key>
        <string>Text</string>
        <key>Condition</key>
        <string>IsUserNotADirector</string>
        <key>Label</key>
        <string>Who is your manager?</string>
        <key>Variable</key>
        <string>UserManager</string>
    </dict>
    

About monitors

When adding a condition to monitors, you should keep in mind that the user can exit the application depending on the monitor installation states (unless you deactivated this behavior with the UserCanQuitIfInstallationIsIncomplete key in the navigation section). Thus, if all the monitors whose conditions are validated are installed, the user will be able to exit. That said, conditionally inserting monitors to be installed lets the user being able to exit by changing an input which validates some monitors but not the ones they are supposed to wait the installation for.

For example, let's said that you want to install Microsoft Office for your consultants. If the user is a director, you don't want to install it. If you ask to the user their role with an input component, the "Consultant" user might change the input to avoid the wait for the installation of Microsoft Office, and thus being able to exit. So, you should rather condition monitors insertion or removal depending on variables that will be set by you, with an API call for example.