XForms spec proposal: add event fired when new repeat instance is created

Agreed that firing an event for repeat instances that are already in the instance is not ideal. I do not think that this event we're describing should be fired based on creation of the primary instance and in fact I think that whatever event we define for now should be limited to repeats (at least for now).

That is what I'm leaning towards as well. So that would mean that in order to define defaults for all instances of a repeat including the one(s) defined in the form definition, a setvalue action would have to be triggered by both instance first load AND repeat instance creation, right?

In the mean time, I've made two interesting discoveries following @Xiphware's lead of looking through the documentation for Orbeon forms (probably the most complete W3C XForms engine implementation):

One thing I get out of that is that even Orbeon works some amount outside of the strict W3C XForms standard.

The Obeon spec says for xxf:default:

For dynamic values, for example coming from request parameters or session values, there is no declarative notation and you must use xforms-submit-done, xforms-model-construct-done, or xforms-submit-ready"

That could be taken to imply that xforms-model-construct-done is equivalent to our newly-introduced odk-instance-first-load as @Xiphware hypothesized here but I don't find it particularly conclusive.

To me, the fact that Orbeon has introduced a separate construct for dynamic defaults suggests that we're not crazy to introduce custom features for ODK XForms.

I don't think we've considered using an attribute. We could follow their lead and do that. odk-instance-first-load would still be supported but the preferred approach would be to use the new attribute.

Or we could have the setvalue used for defaults in repeats respond to both odk-new-repeat and odk-instance-first-load:

   <repeat nodeset="/data/friends">
      <setvalue event="odk-new-repeat odk-instance-first-load" ref="age" value="../../my_age + 2" />
      <input ref="/data/friends/age">
           <label>Update age</label>
      </input>
      ...
  </repeat>

This is also a good opportunity to make sure we're on the same page regarding evaluation context. In the example above with relative references, the evaluation context node for age would be a repeat instance e.g. /data/friends[3] and so would be resolved to e.g. /data/friends[3]/age. Then that would be used to contextualize the value so e.g. /data/friends[3]/age/../../my_age -> /data/my_age.

1 Like