Re: Discussion points for <control/>

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>
>
> ==
>
>