Meeting minutes
ACTION-2325: Steven and Erik, check the new submit-ready text
https://
Erik: Still to do
ACTION-2314: Compose text that matches the <control/> discussion for
mirroring (Steven)
https://
Steven: What happens if the shape of the data on either side is different?
Erik: What do you mean by "bind to a text node"?
Erik: I'm not sure we agreed to do that, just raised the issue
… about what to do when the two sides bind to something slightly different/.
… for instance if the embedded side is bound to an element content and the embedder is bound to an attribute, then they are mirrored
Alain: We could specify how to say in the embedded form that the text is to be in the content of an attribute, or anywhere...
… using a <bind/> element
Steven: Standard controls only have two cases: no children, or children
Erik: In practice you bind to an attribute or an element.
Erik: <repeat> is different
… binding to a series of things
… or binding to an atomic value
… a sequence of items
… We support binding to elements, not to other cases, but I agree it would be good to bind to attributes
… also to 'repeated' things
… for instance a tabbed based interface, with repeating over multiple tabs
Steven: Is the conclusion that it would be nice to bind attributes, but we don't know how to do it?
Alain: there might be exceptions if the embedded form has an instance not as a root element.
… or is it ignoring?
Erik: Two main use cases: an input field, that really deals with string values.
… 2) subforms that need complex content under the binding, and that couldn't be bound to an attribute. It wouldn;t make sense.
Erik: It might be nice to have a mechanism that allowed a subform to do both, not sure if it is needed though
Steven: So what should the reaction be if the two sides don't match?
Erik: Binding error event?
Steven: That's a good answer as far as I'm concerned.
Steven: OK, moving to events.
Erik: I want to avoid duplication of events.
Steven: What about my suggestion of <signal/>
Erik: there's a problem with that.
[Long discussion about how it works with web components]
Steven: Initialisation. You Erik use a heuristic about which side has data at the start
Erik: Yes
… complex content is easy
… one side is empty, the other not
… for simple content, it is harder
Steven: Maybe an attribute on the interface element saying what should be done?
Erik: Maybe other possibilities. Always initialises from the outside, but if the embedded form wants it differently, it then initialises
Steven: this also has ramifications about how xforms-ready works on both sides.
Alain: We have subforms for performance reasons. We load a subform after xforms ready
… so it has a different dynamic with xforms-ready
… we have that requirement
Steven: So we need to think about that too.
AOB
[None]
[ADJOURN]
Recreating the missing discussion above
Erik: web components puts a listener on (effectively) the <control/> element, so the action in the embedded form responds to that but the event bubbles in the embedding form.
Steven: Doesn't that mess with the context?
Erik: No the context remains the same.
Steven: So the <interface/> element has a sort of magic
… it looks like the event was targetted to it, but it wasn't.
… and doesn't bubble up in the embedded form.
Steven: My <signal/> proposal was intended to let the event turn up at the <interface/> element in a normal, non-magic way.