This article is the second part of this feature guide on choice_filter expressions. To see the first part on getting started, click here.
Additional properties and considerations
Re-using choice lists
A general property of choice lists that goes beyond this guide is that the same choice lists can be used by many fields. So, to create a second choice list with the same choices is redundant. This is also true when it comes to choice lists that have filter values. Different fields that use the same choice list can either filter the assigned choice list (if they have a choice_filter expression) or not (if there is no choice_filter expression). Each field could also filter the same choice list differently, each with its own unique choice_filter expressions. This can help you re-use the same choice list rather than creating multiple near-identical choice lists for subtle variation (see example 8 in part 3 of this guide).
Missing filter values
You might think that choices only need a filter value if they are to be filtered. That is not the case. This is fine when negatively filtering, where the filter is NOT equal to something ("filter != x"), but with positive filtering ("filter = x"), each choice needs a filter value in order to appear. This is because, without a filter value, they’ll never meet the criteria in the choice_filter expression. You’ll see this if you ever forget to add filter values. However, if you are negatively filtering, this will not be important, but you can stay on the safe side by giving each choice a filter value.
Choice of values for filtering
While the example in part 1 of this guide uses strings (i.e. text) as filter values, it is also possible to use numeric values. Strings are used in this example for the purpose of an easily understood example, but you can also use integers or decimal values. Numeric values also offer a greater range of choice filtering options, including being able to use greater-than (>) and less-than (<), not only equal (=) and not equal (!= / not()). Read more about available operators here.
However, filter values must be static values - they cannot take expressions or dynamically reference values on the survey sheet of the form design (e.g. "${calculated_filter_1}" won’t work as a filter value). Seeing as filter values are always static (e.g. "1" or "a"), the dynamic aspects of choice filtering take place in the choice_filter expression only. The corollary of this is that filter values do nothing by themselves unless the choice list is being filtered using an expression placed in the choice_filter parameter for a field on the survey sheet.
It is also possible to use date values as filter values (e.g. "2002-12-31"). To treat a filter value as a date, you will have to enclose filter in the date() function in your choice filter expressions (e.g. date(filter)).
|
The only choice list parameters that can dynamically take values from the survey sheet are the label and image. Otherwise, choice lists as a whole can be dynamically pre-loaded from an external data source. |
Multiple filter columns
Choice lists can actually have multiple filter columns, offering greater flexibility and more options in terms of how to express your specifications in a choice_filter expression.
| This functionality is only available in the spreadsheet form design template, so if you are working in the online form designer, export your form design from the designer, or download it from the Design tab of the server console (Download > Form files). It is possible to upload the spreadsheet version of your form design back to the server on the design tab to update the same form on your server and then continue to edit it in the online designer, as before. |
On the choices sheet of the spreadsheet form design template, you’ll see the standard filter column on the right of the sheet. Add additional filters to the right with unique names (e.g. "filter_2" or "randomization", whichever names you like). Whatever new columns you add will be assumed to be filter columns. Then you’ll be able to use these additional filter columns in choice_filter expressions. For example:
filter = ${filter_criteria} and randomization >= 0.5
For a similar example, see example 10 in the sample form attached to part 3 of this guide.
Additionally, note the following:
- Adding additional filter columns is seldom necessary, even for complex choice filtering requirements but this functionality is there and can be used, even to just have more meaningfully named filter columns.
- If you’ve added more than three filter columns to be referenced in a single choice_filter expression, there probably is a more efficient way for you to achieve what you’re trying to do.
Static items in a filtered choice list
You might want some items in a choice list to be always present, in spite of other conditions in the choice_filter expression that will filter out other items. This is possible to achieve with the "or" operator. In general, the correct use of the "and" and "or" logical operators in expressions is critical to achieving the results you want. Adding static items that should always appear in a filtered choice list to the end of a choice_filter expression with "or", is an approach that can help keep your choice_filter expressions and filtered choice lists concise and flexible. You can achieve this by adding "or filter = [value of the static choice]" to the end of your choice_filter.
As an example, a choice_filter expression might filter down to the selections made in a select_multiple field named "choices". By itself, this part of a choice_filter expression is "selected(${choices}, filter)". If you wished to statically include "Don’t know" as an answer (with the choice list value 99), even though it wasn’t selected in the "choices" field, add "or filter = 99" to the end of the choice_filter expression for "selected(${choices}, filter) or filter = 99".
See example 8 in the sample form attached to part 3 of this guide for working syntax.
Using relevance instead of choice filtering
It is also possible to program forms without choice filtering while achieving similar results by using relevance. For example, instead of having a single select_one field with a list of districts that is filtered based on the selection of a province in a prior field, you could create many select_one fields, each with a different choice list of districts. However, it is much better when you rely on choice filtering where appropriate, as opposed to using relevance in this way; your form designs will be much more efficient (allowing them to work better on less powerfully specified Android devices) and will produce more concise, immediately usable raw data with fewer fields.
Incompatibility with pre-load choices
In SurveyCTO forms, it is possible to pre-load choices into your form designs. This functionality is however incompatible with choice filtering, which is limited to working with the hard-coded choices that appear in your design ("hard-coded" as in appearing directly in the design, not being pre-loaded from attached data). The labels for those hard-coded choices can still be dynamic, taking values from a field.
To see working example choice_filter expressions, click here to see the third part of this guide.
Do you have thoughts on this support article? We'd love to hear them! Feel free to fill out this feedback form.
0 Comments