Stream: questionnaire
Topic: Autocompletion with multiple display properties
Paul Lynch (May 18 2018 at 14:05):
The follow up to issue 15667 on GForge contains this line: “Need Grahame to confirm that ValueSet.expansion can include properties”. This discussion around other properties I think might deserve its own issue on GForge. In general, if you have an external web API providing searches on tables of data (e.g. a provider data table) a form designer may want specify 1) which table fields are displayed to the user in the form as they type into an autocompleting field; 2) which fields are searched in response to the user typing in the field; and 3) which fields just get returned for future use (maybe autopopulation of other fields) but not displayed.
Even if you have just a code and name, sometimes the form designer may want to display both but only search on the code (as I’ve seen). Or, you might have a field of synonyms you want searched but not displayed.
Lloyd McKenzie (May 18 2018 at 14:21):
That's the intention of the tracker. But to make it work, we need confirmation we can actually get the relevant properties back when we do a value set expansion.
Paul Lynch (May 18 2018 at 14:50):
The original request I wrote in 15667 was more about controls for 1) laying out questions horizontally in a table and 2) adding column headers for the extra properties of value sets once they were received. (The first two points in the issue have nothing to do with autocompleting fields, and are listed there with the one about column headers because we thought both could be handled via changes to itemControl.) I did not ask there about how to specify which properties were retrieved, searched, and displayed. These other issues are related to the one about column headers for lists with multiple properties, and I am okay discussing these points along with 15667 as long as they do not get lost. Should I add a follow up?
Lloyd McKenzie (May 18 2018 at 15:03):
sure
Grahame Grieve (May 20 2018 at 20:36):
The question is whether this is asking for purely visual content, or whether there needs to be semantics as well
Grahame Grieve (May 20 2018 at 20:37):
e.g. I want the the following columns displayed, vs here are the properties
Grahame Grieve (May 20 2018 at 20:37):
the former would be a lot less work for a client doing multi-column display, as in this case but is a lot less useful in the general case
Paul Lynch (May 21 2018 at 14:15):
Even purely visual content would be an improvement, but in the LHC-Forms case, when a list item is selected, the "value" of the field internally is an object with "code", "text", and "data" properties, the latter of which is an object with as many properties as were requested by the form, and which can be used to autopopulate related fields.
Last updated: Apr 12 2022 at 19:14 UTC
