Similar function to pulldata() but without csv

Support
,
1

What is the problem? Please be detailed.
I was trying to find a function similar to pulldata() that I'm using a lot but without having to use a csv.

  • My objective was to be able to extract the province, district, location and other information based on the selection of a team number - exactly like a pulldata() and a little bit like a reverse cascading question (as I don't want to filter the choice but get the unique choice based on an initial answer)
  • I wanted to avoid using a csv for various reasons : choices sheet seems quite more easier for the team here to play with than an external converted csv, my form is in quite different langues and wanted to extract the information based on their label rather than their name to be able to display the information extracted in the right language (and also avoiding issues with csv conversion for unusual languages...)
    I was wondering if there is any workaround to achieve such behaviour.

What you have you tried to fix the problem?
Try to find different idea bu none of them works, so for the moment I'm using an external csv and only display the needed information in english rather than the proper language.

2

Please see Is there any way to update the select option values of a form without replacing the whole form? - #7 by LN for a couple of example forms that do that.

As I said there, the XLSForm support is unfortunately not great but hopefully the examples help you get the idea.

3

Many thanks helène for those examples! And sorry to not have found by myself those resources in the forum which is a great ressource.
Didn't know the instance / root / items feature. Will definitely test it (provided examples are more than enough) !
You were mentionning in one of the link that "search() and pulldata() let you pull values from arbitrary CSVs but I don't personally use those because they're not part of the official specification" : is there any risks that those functions will be remove in a near future if not part of the official specifications ?

1 Like
4

That's how the underlying XML refers to parts of the form! It turns out that XML references we use there just get passed through so we can do pretty sophisticated things. In XLSForm we would probably eventually want to introduce a ${}-like of syntax to hide some of those details.

They're in wide enough usage that even if/when there is better support for more spec-aligned approaches, they are unlikely to be removed in the near future or perhaps ever.