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

Development
,
10

Thanks as always for your thoughtful comments, @martijnr. :heart_eyes_cat:

Agreed!

I think this would be good to clarify in the ODK XForms spec. My understanding from the W3C spec is that it's the repeat form control in the body that defines the template. I believe that's equivalent to what you're saying.

My question isn't so much about templates, it's about repeat instances already in the body. Maybe easier to see if you think about the case where the form definition defines more than one repeat instance such as in example B in the default value spec. Probably the repeat creation event would get fired for all of those at the time of primary instance load? If so, that would mean that to define some existing repeat instances and also provide a template for new ones, the form would include a setvalue action with an expression that sets the value only if it's not blank.

Or maybe the event would never be fired for those? Then I think that to have dynamic defaults on all instances of the repeat including the one(s) defined in the instance you would need a setvalue action that responds both to form instance and repeat instance creation.

:sob:Ok, fine.

Upon more reflection, here's how I believe the W3C XForms xforms-insert event works with setvalue:

  • the event is dispatched to the instance (see this table)
  • any actions that want to listen for it are directly in the model (as siblings of instance, just like in my example above; that means they are triggered when the event bubbles up)
  • an action that responds to xforms-insert can't be nested in a form control because the event is not dispatched to control elements (or descendants)
  • the event provides an evaluation context for the setvalue action's ref (the newly created repeat instance)
  • if the ref is a relative expression that can be contextualized given the provided context, then the value expression is evaluated using the contextualized ref as the context node. If the ref can't be contextualized given the event context, nothing happens. This is one way for the action to only run when instances of a particular repeat are added.
  • if the ref has an absolute path, I believe the action will run any time any repeat instance is inserted.
  • the action can also set the observer attribute to only respond to inserts of instances of a particular repeat

I think it's the evaluation context piece that's tricky. Here's what W3C XForms says for the evaluation context used to evaluate the XPath expression in setvalue's value: "The evaluation context for this XPath expression is the result from the Single Node Binding". My understanding from the section on Single Node Binding is that this means the contextualized ref is used as the context for value.

And this about a change from XForms 1.0 to 1.1:

"the setvalue action has been improved due to the addition of the context() function. Now it is possible to express the value attribute in terms of the same context node used to evaluate the single node binding. This improves the ability to use setvalue inside of a repeat to set values of instance nodes that are outside of the repeat nodeset based on values that are within the repeat nodeset."

Here's how I understand your counter-proposal; please correct me if I got any of it wrong:

  • actions that are triggered by the odk-new-repeat event must be nested in a repeat form control
  • when a new instance of a repeat is added, the odk-new-repeat event is dispatched to the repeat, triggering actions that are directly nested in that repeat's form control (that is, if an action is defined in the form control for /data/repeat1/repeat2/, it will be triggered when an instance of repeat2 is created, but not when an instance of repeat1 is created)
  • values of any attributes defined on an action triggered by odk-new-repeat are evaluated using the contextualized ref node as context

The nesting makes it clear which new repeats should be responded to. It also provides a clear evaluation context node for the ref (the new instance of the repeat it is immediately nested in). If the evaluation context node for value is indeed the contextualized ref, then if ref is a node outside the repeat, value can't be a node in the repeat. I think that's a fine limitation.

I don't think that would make sense -- the nesting identifies the repeat whose odk-new-repeat event should be responded to, right? I don't see what additional information nesting it in a form control provides.

I'm tentatively onboard with your suggestion. Let's see whether I misunderstood anything or if the additional references I pointed to might provide more ideas.

1 Like