Brainstorming doc

As a form user:

• I want default values populated at form load time that I can edit and my edits will be retained (odk-instance-first-load, e.g. with the current date, last saved)
• I want default values populated at repeat instance creation time that I can edit and my edits will be retailed (odk-new-repeat, e.g. with a value from the form top-level or a previous repeat instance)
• I want default values based on entered form data that I can edit but that will change when a dependent value changes (xforms-value-changed, e.g. when I select an Entity)

ODK XForms spec: https://getodk.github.io/xforms-spec/#events
W3C XForms spec: https://www.w3.org/TR/xforms11/#action-setvalue

User-facing documentation:

• Dynamic defaults
• Trigger on value change

Note: a lot of forms have these, there are extensive scenario tests describing the intended behavior

Related

• Engine API: expand and improve select write semantics (also anticipating future types) #97
• Add support for jr:preload #122 -- could be implemented internally the same as setvalue triggered by odk-instance-first-load
• Add setgeopoint action #507

Background

All of XForms is defined in terms of events: https://www.w3.org/TR/xforms11/#rpm-events
The ODK subset only explicitly supports a few, most custom: https://getodk.github.io/xforms-spec/#events

Calculates are not guaranteed to run only when a dependent value updates

• There may be revalidation and recomputation at any time, e.g. at submission finalization
• The once() function (think of it as if-not-blank()) can kind of be used for dynamic defaults by wrapping default expressions in calculates on user-editable fields but the wrapped expression won't ever run again once there's a value (so not ideal, for example, when setting defaults based on an Entity selection that can be changed)
• Setvalue actions are useful for proper dynamic defaults

JavaRosa's actions implementation was ported from CommCare

• Map from event to actions triggered
• Every time an event happens, see if any actions are triggered, if so, do them
• Ideally they could be actually in the dependency graph

jr:preload – equivalent to setvalue on an odk-instance-first-load event

• Historical artifact from before events and actions
• Maybe the implementations could be shared, maybe it's not worth it