Re: IR and XPath DM implementation

If we want to keep the DOM Event I/O processor in SCXML 1.0, we will 
have to restrict ourselves to the assertions that are already in the 
spec.  Adding the assertions that David suggests would require 
publishing another last call working draft and that would slow us down.  
We can always work on extending the DOM Event I/O Processor after 1.0 
goes out.

  - Jim
On 10/26/2014 2:48 PM, David Junger wrote:
> Le 26 okt 2014 à 18:15, Zjnue Brzavi <zjnue.brzavi@googlemail.com> a écrit :
>> Glad to hear there is someone else willing to make the final push for DOM events.
>> I don't have much time for this either, so hoping we can stick to supporting assertions 1-9 as mentioned by Jim.
>> In case it helps, here are the applicable routines in my implementation [1][2][3][4].
> Sure. JSSC already covers most of that, though the details differ slightly. Should be really simple to fix.
>
> One thing that's not in the spec is the name and arguments of the method exposed to external code to queue (DOM) events into the interpreter. It would be nice if we agreed on some of our API. In JSSC that method is called fireEvent and you can pass it a DOM event (among other things).
> http://www.jsscxml.org/api.html#methods
>
> Maybe you want to look at my heuristics to determine whether to parse target as CSS or XPath, see if we're interoperable in case you want to suport both (I see you're passing the target to JQuery, do you know how it interprets it?):
> https://github.com/Touffy/JSSCxml/blob/master/SCxmlProcessors.js#L44-L75
> JSSC instances are always attached to an Element in the parent HTML document so that elements serves as the default target and the starting point for relative XPaths.
>
> 			David

Received on Sunday, 26 October 2014 19:15:42 UTC