W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2012

Re: SCXML: DOM Events I/O

From: David Junger <tffy@free.fr>
Date: Tue, 2 Oct 2012 21:50:26 +0200
Message-Id: <7BE1A57A-EB6B-4751-8326-7D200844C9C8@free.fr>
To: www-voice@w3.org
> However, I've had several opportunities to present SCION to front-end developers recently, and they seem to be universally concerned with the fact that SCXML uses an XML syntax. XML is still painful to deal with for js devs for reasons that are by now well-documented, and I think this is the primary issue blocking adoption of SCXML in front-end development. For this reason, I'm considering rolling a JSON format for SCXML. SCION already uses a JSON-serializable intermediate representation internally, and so I'm thinking about simply fixing this up and exposing it as an alternative document format that SCION can accept as input. From a practical perspective, this work may be more important than refining the spec.

I agree that a JSON representation can be handy (and I encourage you to document your JSON format beacuse I can easily think of cases where that would be useful). It is not really relevant here though.

As for inline <scxml> tags, I like to use them with a src attribute, though the restrictions that you pointed out mean that I'll probably scrap full inline support altogether.

> I also feel that relative xpath paths from <send type="DOM">  in a document that is not anchored in the DOM should simply throw an error. This could be determined through static analysis when the model is parsed.

No, and no. It would be counter-intuitive and unhelpful to throw an error when there is an obvious default reference (the document root). targetexpr cannot, in general, be determined at parse time, nor can static target XPaths or selectors be resolved with certainty at parse time because the HTML (or SVG, etc) document itself may change between that time and the moment the event is sent.

> What would be practical, and I think useful in some cases, is binding an instance of a particular SCXML document with a particular node in the DOM, such that the SCXML instance can automatically consume the DOM events sent to the bound DOM node,

Do you mean events sent specifically to it (where target==currentTarget in the node)? that would only happen with a dispatchEvent call, and it's simply not possible anyway to add an event listener for all possible event types. Besides, most native HTML elements have a very limited event I/O unlike JSSC which manipulates all sorts of events, and wants data with them. If you think of manually creating and dispatching Events, as I said before, it's easier to reduce that to one method call on the interpreter (we could even call it dispatchEvent, but that would be incompatible with the DOM definition).

> and events which the SCXML document sends to other DOM nodes via <send type="DOM"> would seem to originate from the DOM node to which the SCXML instance is bound. This could even be expressed declaratively using a custom data attribute on the bound element, e.g. <div data-scxml-href="document.scxml"/>, which would indicate that the that the document at that href should be fetched, instantiated, and event listeners created which would pass events received by that element to the bound state machine instance.
> Currently, SCION maps DOM events to SCXML events in the following simple way:
> * The SCXML event name is derived from the DOM event name.
> * The SCXML event data is the DOM event itself

That's what I do as well with the name, and I copy (shallowly) the Event's properties into _event.data, replacing DOM Elements with an XPath string.
Again, binding all incoming event types is not possible. So we must either not listen to DOM events, or use a registering method for each type we want, similar to addEventListener in the EventTarget DOM interface (http://www.w3.org/TR/dom/#eventtarget) but without a callback.

Oh, another thing, while we're talking about <send>: a web browser implementation cannot receive HTTP events, though it is very easy to implement sending them. That means, according to the current draft, that a browser implementation either doesn't implement HTTP at all, or is non-conformant.

Received on Tuesday, 2 October 2012 19:50:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:03:59 UTC