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):
- They apparently define
setvalue
'sref
as being always relative to the root element of the form data. I'm honestly not sure that I believe this because I think it would mean it can't be used for repeats. Right? - They have defined a custom
default
bind attribute in their namespace to set dynamic defaults.
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
, orxforms-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
.