Re: Soliciting Comments from SCXML Users

Can you link to a demo of the graphical viewer/debugger?

On Wed, Jan 9, 2013 at 6:24 AM, David Junger <tffy@free.fr> wrote:

> I am still working on JSSCxml, a Web browser implementation of SCXML.
> <self-advertising>
> JSSC is in active development, already quite capable (and largely
> conformant), and distributed under a MIT license.
> It includes and powers a graphical viewer/debugger for SCXML, which should
> also become a graphical editor in the future.
> https://github.com/Touffy/JSSCxml
> </self-advertising>
>
> With DOM events, it is very good at interacting with its parent Web page.
> It forces you to write robust event-based UI code while the complexity of
> managing a Web app is tamed by the state chart.
> What SCXML lacks in its ancestral area of dialog management compared with
> dedicated languages is grammars and parsing. Adding them is easy, but it'll
> always take a bit more code. However, SCXML makes up for it with its core
> expressivity (<history> and <parallel> in particular give you complex
> behavior in a way that's incredibly easy to design) and is orders of
> magnitude easier to debug than typical CCXML / VoiceXML implementations. If
> you've ever worked with those, you surely remember the pain. Cryptic debug
> logs are over, instead you can litterally look at your state chart as the
> application takes transitions through it. I think that point will be
> decisive in encouraging a <transition target="scxml"/> for the dialog
> management world.
>
>
> Now some specific remarks:
>
>
> C.2.6:
> The value at an undefined location is undefined, but it does not
> necessarily prevent the ECMAScript interpreter from assigning a new value
> to it (if the location points to a yet-undeclared property of an existing
> object). It may be desirable to let the ECMAScript datamodel behave like
> ECMAScript and allow such assignments to undeclared locations, raising an
> error when and only when the ECMAScript interpreter does. Certainly
> wouldn't hurt my implementation, I'd just have to remove some ugly code.
>
>
> I have noticed a few critical problems with the new definition of the DOM
> send type. Sorry ;)
>
> D.3.1 second paragraph:
> - the name of the CustomEvent's custom property is "detail" without an "s"
> - in the browser, it is impossible to set the value of many event
> properties (they are read-only to content JavaScript) so a browser
> implementation cannot be conformant with the current requirement that any
> event property named in namelist or <param> be set to the corresponding
> value (no error will be raised by the attempt, it will simply leave the
> value unchanged).
>
> D.3.2:
> - It is not practical to prevent Element instances (such as those
> representing SCXML states and other elements) in the browser from
> implementing the EventTarget interface, and neither is it practical
> (without native support) to have an inline <scxml> document in HTML (an
> <scxml> tag with a 'src' attribute is fine).
> - It is irrelevant at this point that the <scxml> element and its children
> implement it, since it cannot be used to listen to all DOM events anyway,
> because unlike with SCXML events, DOM events must have a registeredd
> listener in their name before anything will happen. Just cut that out of
> the recommendation.
> - Nothing about <content>? For CustomEvents, it shouldn't be a problem to
> be consistent and say that the <send> element may have one <content> child
> excluding any namelist and <param>s, and that the event's "detail" property
> must be set to the child's text contents (or possibly to that content
> interpreted as JSON).
>
>
>
> As I have pointed out before, the 'basichttp' I/O Processor is
> incompatible with a client-side implementation, but since that Processor is
> optional it's all right.
>
>
> I'd like to attract your attention to a couple of recent developments of
> HTML that deal with sending/receiving events and could inspire SCXML:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html
>
>
>                         David
>