[ODK Community] Cascading Selects in ODK Collect 1.2 - An Example

Great stuff!!

··· On Mon, Jul 23, 2012 at 9:17 PM, Mitch S wrote:

Since there is a lot of confusion about what KoBo Collect's javarosa
supports, I I'll work to get this up on While I work to get this up on the
opendatakit.org website, I thought I would show everyone the
cascading-select feature available in ODK Collect 1.2.

Attached are 3 versions of a simple form.

The form has a cascading select for counties and the cities within those
counties.

The definition of the set of counties and set of cities is in a separate
named instance ('choices') and is NOT PART OF the main instance
submitted to ODK Aggregate ( the 'CascadingSelect' instance ) -- the form
submitted to ODK Aggregate consists of only the block, with the
and data item -- NOTHING ELSE. In your forms, you can
define as many blocks as you desire. The 1st block in the form
definition is the block that will be sent to ODK Aggregate. The others are
just static data used for filling in the form.

The prompts in the use constructions to refer
to the values in the 'choices' instance. You can add or remove values from
that second instance, and ODK Aggregate will not care (assuming you're
using the version attribute appropriately), because the main (1st) instance
is not changing.

Thus, with this example, you can upload the form 'cascadingForm.xml' to
ODK Aggregate, download it, and see 2 city choices for each county, then,
WITHOUT DELETING YOUR FORM on ODK Aggregate, you can then upload the
second form, 'cascadingFormv2.xml', which is the same form id, but with a
different version attribute, and see 3 city choices for King county. i.e.,
you can modify the choices offered to the user for this question as you
revise your form, and not lose any of your earlier data in ODK Aggregate.
Furthermore, if you display the metadata for your submissions in ODK
Aggregate, you will see that ODK Aggregate knows what version of your form
was used!

The 3rd file ('cascadingFormv3.xml'), shows how you can support language
translations by using the value field to index into the itext translation
tables.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Steven Nsubuga
Mobile: +256772712983
snsubuga@grameenfoundation.org
Skype ID: stebugz
Software Developer
AppLab Uganda
To enable the poor, especially the poorest, to create a world without
poverty

It looks like it is up on ODK website.
http://opendatakit.org/help/form-design/cascading-selects/

Cheers,
Ed

··· On 08/01/2012 02:56 AM, Olivier Kalmus wrote: > Hey, > > I would be very interested in having a look at these example forms, > but I can't seem to find the original post. Could you please point me > in the right direction? > > Thanks > > Olivier > > On Tuesday, July 31, 2012 2:29:00 PM UTC+2, Steven Nsubuga wrote: > > Great stuff!! > > On Mon, Jul 23, 2012 at 9:17 PM, Mitch S <mitchellsundt@gmail.com > wrote: > > Since there is a lot of confusion about what KoBo Collect's > javarosa supports, I I'll work to get this up on While I work > to get this up on the opendatakit.org > website, I thought I would show everyone the cascading-select > feature available in ODK Collect 1.2. > > Attached are 3 versions of a simple form. > > The form has a cascading select for counties and the cities > within those counties. > > The definition of the set of counties and set of cities is in > a separate named instance ('choices') and is *NOT PART OF* the > main instance submitted to ODK Aggregate ( the > 'CascadingSelect' instance ) -- the form submitted to ODK > Aggregate consists of only the block, with the > and data item -- *NOTHING ELSE*. In your forms, you > can define as many blocks as you desire. The 1st > block in the form definition is the block that will be sent to > ODK Aggregate. The others are just static data used for > filling in the form. > > The prompts in the use > constructions to refer to the values in the 'choices' > instance. You can add or remove values from that second > instance, and ODK Aggregate will not care (assuming you're > using the version attribute appropriately), because the main > (1st) instance is not changing. > > Thus, with this example, you can upload the form > 'cascadingForm.xml' to ODK Aggregate, download it, and see 2 > city choices for each county, then, *WITHOUT DELETING YOUR > FORM* on ODK Aggregate, you can then upload the second form, > 'cascadingFormv2.xml', which is the same form id, but with a > different version attribute, and see 3 city choices for King > county. i.e., you can modify the choices offered to the user > for this question as you revise your form, and not lose any of > your earlier data in ODK Aggregate. Furthermore, if you > display the metadata for your submissions in ODK Aggregate, > you will see that ODK Aggregate knows what version of your > form was used! > > The 3rd file ('cascadingFormv3.xml'), shows how you can > support language translations by using the value field to > index into the itext translation tables. > > -- > Mitch Sundt > Software Engineer > University of Washington > mitchellsundt@gmail.com > -- > Post: opendatakit@googlegroups.com > > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > > Options: http://groups.google.com/group/opendatakit?hl=en > > > > > > -- > Steven Nsubuga > Mobile: +256772712983 > snsubuga@grameenfoundation.org > Skype ID: stebugz > Software Developer > AppLab Uganda > To enable the poor, especially the poorest, to create a world > without poverty > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en