Re: Proposal for merging <signal/> into <dispatch/>

On Wed, 21 Nov 2018 07:58:43 +0100, Erik Bruchez <ebruchez@orbeon.com>  
wrote:

> I am not a huge fan of the `to` attribute, so I am looking for other  
> solutions :)
Could you elaborate on your objections?

> DOM events with the Shadow DOM have an attribute called `composed` [1].  
> When that attribute is set to `true` and the event bubbles, it does so  
> through the Shadow DOM root. We >could follow this and add a  
> `composed="true"` attribute on `dispatch` instead of `to="parent"`.
If there is one thing that has become clear to me from the design of  
XForms, it is that boolean attributes are always a bad idea, partly  
because of the confusion between "true" and "true()" that we are forced to  
use, but more because a boolean has only two values, and we inevitably end  
up dealing with more than two cases, @relevant on submission being the  
most recent example.

Secondly, it is really good if the choice of names for anything we invent  
are suggestive of their purpose; it helps you remember how to write what  
what you want to achieve, and it helps you read what someone else has  
written. I want to dispatch an event. What is its name? Where do you want  
to dispatch it to? That's why I chose 'to' for the attribute: it sort of  
makes it a sentence. composed="true" suggests nothing about the purpose to  
my mind.

> Now for the other way around, that is dispatching an event in the  
> embedding form to the embedded form, I don't find a corresponding  
> mechanism for the Shadow DOM, which is >crazy.

That is odd.

> We could consider attaching a listener with a special observer within  
> the embedded form, something like:
>
>    <action
>        event="my-custom-event-from-the-outside"
>        observer="#host"/>
How does this work? It seems to be the opposite of what we are trying to  
achieve. We want a version of <dispatch/> that dispatches into and out of  
embedded forms. The initial proposal was a different command with similar  
style to dispatch, and now we are trying to merge that with dispatch. It  
seems like the only thing we need to add is a way of indicating the  
difference with traditional dispatch, and that is whether we are  
dispatching into or out of an embedded form.

Steven


>
> Our implementation already makes use of values starting with `#`,  
> namely: [2]
>
>    event="#all"
>    observer="#document"
>    observer="#preceding-sibling"
>    target="#observer"
>
> -Erik
>
> [1] https://developer.mozilla.org/en-US/docs/Web/API/Event/composed
> [2] https://doc.orbeon.com/xforms/events/events-extensions-other
>
>
> On Tue, Nov 13, 2018 at 6:25 AM Steven Pemberton  
> <steven.pemberton@cwi.nl> wrote:
>> Add @to attribute to dispatch: (we can discuss the choice of name)
>>
>>   to = targetid | parent | control
>>   Value 'targetid' is default
>>
>> The attribute has the following effects:
>>   to="targetid", targetid="..." behaviour is as now.
>>   to="control", targetid="id of control element", event is dispatched  
>> to first model of embedded control
>>   to="parent", (targetid is ignored), event is dispatched to embedding  
>> control element
>>
>> Examples:
>>
>>   <dispatch name="tick" targetid="clock"/>
>>   <dispatch name="tick" to="targetid" targetid="clock"/> (has same  
>> effect as above)
>>   <dispatch name="reset" to="control" targetid="game"/>
>>   <dispatch name="finished" to="parent"/>
>>
>> You might prefer:
>>
>>   <dispatch name="reset" to="control" control="game"/>
>>
>> Steven