Re: Discussion points for <control/>

Updated following the discussion from last week.

REQUIREMENTS FOR <control/>
 Embeds an XForm in another XForm
 The embedded XForms behaves like an inbuilt command
 The embedding uses recognizable interfaces (eg @ref @resource etc)

      <control resource="mycontrol.xhtml" ref="instance('data')" 
label="..."/>

INDEPENDENCE
 A form should be able to be used both embedded and free-standing.

DYNAMIC LOADING
 There should be a way for embedded forms to be loaded dynamically.
 QUESTION: Does this get specified, or is it part of their behaviour?.

PRIVACY
 An XForm that can be embedded contains an element in the model (currently 
called <interface/>) that:
 1) identifies which (sub-)instance receives the data,
 2) receives events arriving from outside,
 3) is the target for events to be sent to the outside.

        <interface ref="instance('values')"/>

 Each form (embedder/embeddee) only has access to data granted by the 
other.

DATA
 Data can be passed in; data can be passed out.

 The interface uses bi-directional mirroring between a (sub)-instance in 
the embedding form, 
 and a (sub-)instance in the embedded form.
 To the embedded form it looks like it is referencing one of its own 
instances.
 Each form sees the changes made by the other form (more or less) 
simultaneously as they are made.
 There are clearly requirements to the two instances matching in shape in 
some way.

 Either side can bind to an attribute 
(https://www.w3.org/2022/11/11-forms-minutes#t01),
 but in that case both have to bind to a text node,
 and the embedded form's referenced item must not have children.
 QUESTION: And vice versa?

 If there is a mismatch, an xforms-bind-error is dispatched.
 QUESTION: On the embedder side?

INITIALISATION
 QUESTION: How do we determine if the embedded form gets initialised from 
the referenced data
 or from its own data? Use heuristics, or should the <interface/> element 
specify that?

EVENTS
 Events can be passed in (by targeting the <control/> elements)
 Events can be passed out (by targeting the <interface/> elements)
 Both forms are insulated from events from the other except 
 for events specifically targeted at communication between the two.

 Events should perform the same as normal.

 QUESTION: Which is better?
 1. Events targeted to <control/> and <interface/> perform the same,
    and so bubble up from the <control/> or <interface/> in the dispatching 
form,
    therefore appearing in both forms.
 2. The <interface/> and <control/> elements have magic so that if they are 
targeted, 
    the events neither bubble nor capture on the dispatching side.
 3. We introduce a new action, say <signal/> with comparable attributes to 
<dispatch/>
    which causes a <dispatch/> to happen on the other side of the 
interface,
    so that the event only appears in the form being signalled to.
 4. Something else?

 QUESTION: What are the ramifications for xforms-ready if any?
 Should it only be fired when all embedded forms are also ready?

EXAMPLE

 <control id="process" resource="process.xhtml" ref="data" label="Before">
     <action ev:event="FINISHED">
         <setvalue ref="done">1</setvalue>
     </action>
 </control>
 ...
 <dispatch name="STOP" targetid="process"/>

 ------------ process.xhtml
 <model>
    <interface ref="instance('values')" id="external">
        <action ev:event="STOP">
            ...whatever...
     <dispatch name="FINISHED" targetid="external"/>
        </action>
    </interface>
    ...
 </model>
#

Received on Thursday, 1 December 2022 20:52:28 UTC