Getting data in a linked_table entry for parent form

Support
1

Hi,

I have an ODK2.0 form which contains a linked_table to a form (let’s call it the “child” form). In the child form, the user will enter a single integer called “numberOfCans” and then finalize that child form instance. How can I return this integer value back to the parent form for use for validation in the parent form? Would it be something like data(‘<some_unique_form_id>.numberOfCans’)?

Specifically, I plan on restricting the number of child form entries by the total sum of these integers across all of the entered child forms.

Thanks,
A newbie ODK2.0 user

2

The mechanism to do this has not been generalized and folded into the core software.

The ‘agriculture’ form demonstrates one possible implementation of the mechanism. In this form, there are custom prompt types for asynchronous assignment of values. Defining a custom prompt type requires a ‘prompt_types’ sheet with the prompt type name and the datatype that the prompt type manipulates (number in this example). And a customPromptTypes.js file that defines the implementation of that prompt type.

This demonstration form defines the following prompt types:
async_assign_max
async_assign_min
async_assign_avg
async_assign_sum
async_assign_total
async_assign_count

All of these ‘prompts’ share a common rendering template (templates/async_assign.handlebars) which, in this case, displays nothing unless the row in the survey sheet has a column labeled ‘display.debug’ that contains the value 'TRUE

i.e., these prompts are included in a form only for their side-effects – for their assignment of a value into a field. In this manner, they are similar to the synchronous ‘assign’ action. But, there are several differences. First, because these are prompts, they are always treated as if they occur within a begin screen … end screen block. So if you use them directly without wrapping them in a screen, the device will display a blank (white) screen with no prompts (unless you have display.debug TRUE). Second, because these are prompts, and because of the way they are implemented, the assignment occurs after the synchronous ‘assign’ and after the if-then-else determination of what prompts should be rendered. The order in which the assignment occurs and is available to other prompts is based upon the order in which the prompts are rendered within a screen. I.e., these prompts should be declared at the top of the begin screen … end screen block in order for the assigned values to be available for prompts appearing later within the screen.

The actual implementation of the prompt uses the linked_table prompt type as its base. That prompt type uses queries defined on the queries sheet to select values from whatever table you specify. In an ordinary linked_table prompt, the value retrieved from the query is governed by the instance_name setting in the form being referenced. In these async… prompts, the field to retrieve is specified by the ‘fieldName’ column on the queries sheet.

Since the selection filter on the query might return more than one row, the various async… prompt types return the max, min, avg, sum (alias: total), or count of the number of matching rows.

If this were folded into the core software, these actions would be processed outside of a screen block and would be processed before the synchronous assign operations and if-then-else logic within a screen. They would also not be customizable like they are now (e.g., you can edit the customPromptTypes.js file and make whatever changes you need).