Closed mtyszler closed 3 years ago
Thanks for the report and the follow-up.
The underlying data types indeed are different from the widget types, so from a pure data analysis perspective it makes sense to get "string" for a choice field. The information not provided by form_schema
, such as widget type or skip logic, is part of the form definition, which is available as form_xml
.
What could be a good use case for a user to get widget type programmatically via ruODK beyond existing functionality:
form_xml
> XForm
Problem
When using
form_schema()
the return types are incorrect. In particular,select_one
, for example, is returned asstring
.I believe this is a problem of the API, as reported in https://forum.getodk.org/t/incorrect-type-returned-by-api-form-schema-fields/31044, but I thought it would be good to flag here.
Reproducible example
Session Info
```{r} # utils::sessionInfo() R version 3.6.3 (2020-02-29) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 17763) Matrix products: default locale: [1] LC_COLLATE=Dutch_Netherlands.1252 LC_CTYPE=Dutch_Netherlands.1252 LC_MONETARY=Dutch_Netherlands.1252 [4] LC_NUMERIC=C LC_TIME=Dutch_Netherlands.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] ruODK_0.9.2.9001 loaded via a namespace (and not attached): [1] Rcpp_1.0.5 rstudioapi_0.11 xml2_1.3.2 janitor_2.0.1 magrittr_1.5 tidyselect_1.1.0 R6_2.5.0 [8] rlang_0.4.8 fansi_0.4.1 stringr_1.4.0 httr_1.4.2 dplyr_1.0.2 tools_3.6.3 utf8_1.1.4 [15] cli_2.1.0 ellipsis_0.3.1 assertthat_0.2.1 tibble_3.0.4 lifecycle_0.2.0 crayon_1.3.4 purrr_0.3.4 [22] tidyr_1.1.2 vctrs_0.3.4 curl_4.3 glue_1.4.2 snakecase_0.11.0 stringi_1.5.3 compiler_3.6.3 [29] pillar_1.4.6 generics_0.1.0 jsonlite_1.7.1 lubridate_1.7.9 pkgconfig_2.0.3 ```