Re: Discussion points for <control/>

OK, how about this.


Any XForm that can be embedded signifies this with an element in the model 
that 1) identifies which instance receives the data, 2) receives events 
arriving from outside, 3) is the target for events to be sent to the 
outside.


For now lets call it <interface/>; we can discuss naming later.


So essentially the <control/> element in the embedder links to the 
<interface/> element in the embeddee.


Events targeted to <control/> emerge at the <interface/>; events targeted 
at <interface/> emerge at the linked <control/>


For example:


Embedder:


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

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

On Thursday 03 November 2022 23:11:07 (+01:00), Erik Bruchez wrote:


All,


Here are my comments on Steven's questions:


 > Should the data be shared with the default instance of the embedded form
or does it have to explicitly mark the instance to be used?



With our implementation, it is explicit. We have an attribute called 
`mirror="true"` on the instance element, which designates it for mirroring.


 > Does the embedding form copy data in, and mirror, or pass a reference?
Does it matter? Is this just an implementation issue?


It matters because if it's not a copy, the embedded form can access the 
embedding form's data, for example using the ancestor axis, down to the 
root of the embedding form XML data.


 > Where does the event appear in the embedded form? The default model?


I don't think it should be the default model, as that is not positioned at 
the root of the DOM (or any DOM).


Instead, I'd suggest we need a way to attach a listener to the element 
causing the embedding (the `<control>` element in the embedding form), in 
the same way that in HTML you attach the listener to the custom element. 
This is not an element in the current DOM so we need a special mechanism. 
I'd suggest a declarative notation, for example:


     <xf:action observer="#bound-element">


 > Is any other mechanism needed other than to say that events bubble out 
of
the embedded form into the embedded form?


Here we would need to be able to dispatch an event to that same element. We 
could have again a declarative notation:


     <xf:dispatch targetid="#bound-element">


I think that it is good if this is compatible in spirit with Web Components 
as much as possible.

-Erik





On Fri, Oct 14, 2022 at 5:45 AM Steven Pemberton <steven.pemberton@cwi.nl> 
wrote:

Requirements for <control/>

Behaves like an inbuilt command
      Uses recognizable interfaces (eg @ref @resource etc)
A form should be able to be used embedded and free-standing.

DATA
Can pass data in; Can get data out
         Agreed interface is mirroring between a (sub)-instance in the 
embedding
form, and an instance in the embedded form.
         To the embedded form it looks like it is referencing one of its 
own
instances.
         The embedding form sees the changes (more or less) simultaneously 
as they
are made.
         There are clearly requirements to the two instances matching in 
shape in
some way:
               the embedding form has to supply a reference to a
(sub-)instance that matches the instance in the embedded form.
         Should the data be shared with the default instance of the 
embedded form
or does it have to explicitly mark the instance to be used?
         Does the embedding form copy data in, and mirror, or pass a 
reference?
Does it matter? Is this just an implementation issue?

EVENTS
Can get events passed in
         Is there any other mechanism needed other than dispatching an 
event to the
<control/>?
         Where does the event appear in the embedded form? The default 
model?

Can get events to bubble out
         Is any other mechanism needed other than to say that events bubble 
out of
the embedded form into the embedded form?

EXAMPLE
<control resource="mycontrol.xhtml" ref="instance('data')">
         <action ev:event="finished">
             <setvalue ref="done">1</setvalue>
         </action>
</control>

==