I’m encountering a persistent error when trying to deploy an XLSForm that uses site-based filtering for subsequent select_one questions (chiefdom/village, etc.). I keep getting:
Error: ‘dict’ object has no attribute ‘nodeType’
What I’m Trying to Do
Filter chiefdom/village options based on the selected site.
The filtering logic is implemented in the choice_filter column, referencing the value selected in a previous select_one question for site.
What I’ve Tried
Initially, the site choice list used numeric codes (1, 2, 3, 4) as the name values. Calculations referenced these codes, but this triggered a type mismatch (sometimes Kobo treats these as floats or strings).
I updated the site list so that both name and label match the full site name (e.g., “South Luangwa”, “Lower Zambezi”).
I removed all intermediate calculations and tried both calculate and hidden field types for the mapping logic.
No circular references or duplicate field names are present.
The select_one for site is not in a repeat or group, and all referenced fields are defined before use.
Despite all these changes, Kobo still throws the ‘dict’ object has no attribute ‘nodeType’ error when previewing or deploying the form. Screenshots of the form structure and the error message are attached for reference.
Names shall never contain blanks, please. General rule.
And I am not sure if hidden could work here. But calculate does.
Choice names are always stored/treated as strings, e.g. “1”.
Did you check your form with the Online validator, please? (Always recommended during form development anx before deployment, please.)
Why do you use hint instead of multiple language labels?
Would you mind to share a related extract or minimal example of your form, please?
None of the names are blank — and yes, I did use the validator. That’s actually where the last screenshot showing the nodeType error was thrown.
Thanks for catching the label/hint mix-up; I’ve updated the question label from hint.
Since I understand the values are stored as strings, I did try casting them as numbers. I also stripped the form down to only the choice filter questions, and in that version, the logic works — so it seems the issue was somewhere else in the full form.
Still not entirely sure where the problem was, but rebuilding the form from scratch resolved it.
Sorry, as far as your screenshot shows, there are blanks/spaces in your choice names, e.g. “South Luangwa”. These are not allowed as choice names. Please, replace them, e.g. with underline (or just use numbers): “South_Luangwa” (or 1).
As choice names are stored as strings, your expression should be … loc = ‘1’.
(or … loc = “1”).
Please, provide a testable xlsform extract.
(Or … loc = “1”).
Hi @wroos, thanks for your correction. I had mentioned that I had orginally stored them as numerators and that still didn’t work. The text name options were an attempt to use strings directly for reference in the calculate field.
Initially, the site choice list used numeric codes (1, 2, 3, 4) as the name values. Calculations referenced these codes, but this triggered a type mismatch (sometimes Kobo treats these as floats or strings).
I updated the site list so that both name and label match the full site name (e.g., “South Luangwa”, “Lower Zambezi”).
KObo_Test.xlsx (544.5 KB)
I have tried to do some minor adjustment., it was on how you structured the filters. Am not sure if this is what you want. Please check the form using online validator and revert.
