Re: Dispatch with delay="0"

"If a run-time element is destroyed, then any delayed events targeted at  
that element are removed from the delayed event queue. A run-time element  
may be destroyed for a number of reasons, such as removal of controls  
associated by a repeat with an instance data node that is destroyed."

Presumably also applies to disabled elements.

Steven

On Wed, 24 May 2017 00:21:54 +0200, Erik Bruchez <erik@bruchez.org> wrote:

> All,
>
>> The spec says:
>
>> "If the delay is zero, or does not conform to xs:nonNegativeInteger,  
>> then the event is dispatched immediately"
>
>> I assume that it means dispatched synchronously. This means that there  
>> is a difference of synchronicity between:
>
>>    <xf:dispatch name="foo" targetid="my-model" delay="0"/>
>
>> and:
>
>>    <xf:dispatch name="foo" targetid="my-model" delay="1"/>
>
>> It would be nice to be able to add an event to the event queue  
>> immediately. Using `delay="1"` is close but not ideal.
>
>> The obvious way of doing that would be to change the spec and say that  
>> if `delay` is present and contains a number, the event is always added  
>> to the queue. So you always >get asynchronous dispatch with a numeric  
>> `delay`.
>
>> Now, this causes a problem if you want to have a single action which,  
>> via an AVT, allows for both asynchronous dispatch and asynchronous  
>> dispatch. A special value, such as >`delay="none"` could possibly be  
>> used.
>
>>    <xf:dispatch name="foo" targetid="my-model" delay="none"/>
>
>> Or an empty value:
>
>>    <xf:dispatch name="foo" targetid="my-model" delay=""/>
>
>> Also, a case could be made that if `delay` evaluates to something which  
>> is not a number and not a value indicating synchronous dispatch, then  
>> the event dispatch shouldn't >take place (or an error could be raised):
>
>>    <xf:dispatch name="foo" targetid="my-model" delay="bar"/>
>
>> Thoughts?
>
>> -Erik