- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Fri, 26 May 2023 10:46:57 +0000
- To: XForms <public-xformsusers@w3.org>
This is a summary of what I understand the situation is with regards to embedded XForms, related to Actions 2330 and 2314. We have two XForms running simultaneously. One is embedded in the other, but I don't think this is of the essence. They communicate with each other via two mechanisms: * Shared data: (sub-)instances in each mirror each other. A change in one causes an equivalent change in the other. * Events. Both can send events to the other, and receive events from the other. The point of contact between the two XForms are the <control/> element in the parent, and the <interface/> element in the child. An XForm without an <interface/> may be embedded, but there can be no communication between the two. <interface/> signals the willingness of the child to communicate. Normally, in standalone XForms, events are sent to an element using <dispatch/>. Depending on its properties, an event may be captured on its way to, and/or bubble up from the element it is dispatched to. However, for communication between XForms, a mechanism is needed to say "this event should be dispatched in a different XForm". The event should not appear as an event in the sending XForm, and so cannot be listened for, nor does it capture or bubble in that XForm. On the other hand, events sent from the other XForm do capture and bubble in the receiving XForm, and can be listened for on the <control/> or <interface/> elements in the receiving XForm. There are three possible ways to achieve this: 1. Use <dispatch/> and change the behaviour of the receiving element in the dispatching XForm. 2. Use <dispatch/> and change its behaviour. 3. Use a different signalling method. Note this does not define how it should be implemented, just how it to specify that an event is to appear in the other XForm. EXAMPLES Assuming the existence of elements <control id="child" ref="..." resource="..."/> and <interface id="parent" ref="..."/> possible expressions are then: 1 <dispatch name="STOP" targetid="child"/> <dispatch name="READY" targetid="parent"/> In this version, it is specified that events dispatched to a <control/> or <interface/> do not capture or bubble, and you can never listen to events dispatched to those elements. 2 <dispatch name="STOP control="child"/> <dispatch name="READY" interface="parent"/> or <dispatch name="STOP receiver="child"/> <dispatch name="READY" receiver="parent"/> In this version, dispatch works differently, not dispatching the events in the normal way, but passing them on to the other XForm to dispatch. 3. <signal name="STOP" targetid="child"/> <signal name="READY" targetid="parent"/> In this version dispatch and events work as normal without change, and the events are just passed to the other XForm where they will be dispatched in the normal way. Steven
Received on Friday, 26 May 2023 10:47:07 UTC