Re: SCXML: DOM Events I/O

I just want to say, I've read the previous two emails, and I'm comfortable
with Jim's proposals and David's revisions to them. At the moment, I have
nothing to add.

Jake

On Sat, Oct 6, 2012 at 3:52 AM, David Junger <tffy@free.fr> wrote:

> Just realized I'd sent the reply only to Jim… stupid Reply-to headers…
>
> 2.****
> a.       Should all events sent from the state machine have type
> CustomEvent, with any data converted to a  string and stored in the
> ‘detail’ property?  If we say this we must say that the value of the
> ‘event’ attribute on <send> will be ignored.  Alternatively, we can say
> that  CustomEvent is the default if ‘event’ is not supplied, while if
> ‘event’ is provided, it defines the type of the event.  (But it that case
> where does the data go?)
>
>
> DOM Events all have a "type" property which is equivalent to the "name"
> property of SCXML events. But the baseline Event interface cannot carry any
> data. Thus, there are Event subclasses, one (CustomEvent) defined in the
> DOM spec itself, and others (MouseEvent, NetworkEvent, etc) defined for
> HTML ; these subclasses have extra properties, such as "detail" for
> CustomEvent,  "button", "clientx", "clienty", etc for MouseEvents, and so
> on. Those properties are set when the event is initialized.
> see http://www.w3.org/TR/dom/#interface-event
>
> So, we still use the "event" attribute for the DOM Event's type.
> The CustomEvent.detail property can be any JS value, no need to convert to
> a String (but we might want to stringify some stuff to follow the
> encapsulation principle, despite it being a lost cause in the browser).
>
> There remain the issue of "cancellable" and "bubbles".
> "cancellable" doesn't make sense since <send> is fire-and-forget.
> "bubbles" can be useful in a complex HTML interface with multiple
> listeners for the same event, so I'd activate it just in case. It can
> always be ignored by the listeners. Ideally, there would be a
> (DOM-specific) "bubbles" attribute on the <send> SCXML element.
>
> ****
> b.      For the value of ‘target’, we could say “Processors _*must*_
> support CSS syntax and _*may*_ support XPath syntax”.  Or we could make
> both ‘must’s, but  then we have to make sure that there never could be any
> confusion between the two.
>
>
> It's not possible to guarantee there *will never* be an intersection
> between the two languages, of course. I think most authors will be happier
> with guaranteed CSS support. You could state that a "target" value *_must_
> * be interpreted as a CSS selector first, but that if it doesn't work
> out, the implementation *_may_* try XPath, and queue an error only if
> that doesn't work either (By the way, what sort of error would that be?
> Personally, I like "error.DOM").
> Both syntaxes are built-in so suporting them on modern browsers is a piece
> of cake.
>
> ****
> c.       For events the state machine receives, it makes sense to say
> that the name is the event type and that the actual event goes in
> _event.data.
>
>
> Indeed. Or rather a shallow copy of it, since its properties may change
> later. Also, DOM Events in the browser have a srcElement property which
> might be converted to a valid target and used as the event's origin in
> SCXML.
>
> ****
> d.      I understand the arguments that we shouldn’t require that the
> SCXML root be a node in the DOM.  Maybe we can say:  if the root is a node
> in the DOM, then any events targeted at it are converted into SCXML
> events.  Furthermore, implementations may support other ways of injecting
> events into the state machine.
>
>
> No, we can't. The only way to handle an event in the DOM is to set an
> eventListener for its type (or use the old DOM0 methods). Unlike in SCXML,
> there is no way to set a "wildcard" eventListener. That (and other reasons
> I've mentionned in earlier messages) is why we must have other ways of
> queueing external events. These other ways are
> - a registration method similar to *EventTarget*.addEventListener, but
> with no callback
> - a direct method similar to *EventTarget*.dispatchEvent, but without a
> return value and more flexible
> - attributes on HTML elements, as Jacob suggested, that fall outside the
> scope of the recommendation
>
> see http://www.w3.org/TR/dom/#interface-eventtarget
>
> As a practical matter, we’re  trying  to finish up the spec quickly and I
> don’t think that there is any way of  guaranteeing real interoperability
> without producing the second spec that I mentioned above.  Within our
> current scope, though, I’d like to clean up the DOM Event I/O definition so
> that it doesn’t force anybody to do things the wrong way.  Do you think
> that it is sufficient to address points a-d above?   You and Jacob have the
> two currently active JS implementations that I’m aware of, so I think that
> whatever the two of you agree to is a good basis for the spec.
> ****
> ****
>
>
> I think the API is also necessary. It's not all specific to a browser
> implementation either.
> At the very least we need a method for adding an event to the external
> queue.
>
> I'm OK with leaving the DOM anchor out of it and keeping it for an HTML
> extension. There are a lot of issues that a native browser implementation
> would resolve, too.
>
> David
>