Hi Gavin, I found a few sources that claimed that ActionScript is an ECMAScript dialect: http://en.wikipedia.org/wiki/ActionScript http://stackoverflow.com/questions/1424087/actionscript-is-like-javascript/1424111#1424111
JavaScript is also an ECMAScript dialect. My understanding is that most versions of JavaScript which you find implemented in browsers today are based on the ECMAScript 3 standard, whereas ActionScript includes language features taken from the now-defunct ECMAScript 4 standard. scxml-js generates code based on ECMAScript 3. In any case, I decided to try an experiment to see if the ECMAScript code generated by scxml-js was directly compilable to Flash bytecode using the Flex 4 SDK. I took the generated ECMAScript code from one of my demos, and put it into an mxml document, then attempted to compile it with mxmlc. Demo page: http://commons.apache.org/sandbox/gsoc/2010/scxml-js/demo/drag-and-drop/drag-and-drop3.html Generated JavaScript from this demo: http://commons.apache.org/sandbox/gsoc/2010/scxml-js/demo/drag-and-drop/drag-and-drop3.js Generated code embedded into mxml document: https://gist.github.com/eb7445592f2a00cc7c4f The good news is that, I only had to make one very small alteration to the generated code in order to get it to compile with the Flex 4 mxml compiler. It would be exceedingly simple to update scxml-js to accommodate this change. The above experiment is a good indication that scxml-js could be used directly in your work. However, there are still some large unanswered questions. First, it's not clear whether the semantics of the generated ECMAScript code will be the same when interpreted as ActionScript; there are no guarantees that the generated code will execute properly. Second, the only examples of standalone .as files I have seen are wrapped in a "package{}" declaration, and each of the objects declared inside of the package have public/private visibility modifiers. This may mean that, to move the generated ECMAScript code out into its own .as file, as opposed to embedding it directly into the mxml document, would require extra code to be generated for the package and visibility declarations. Third, performance of the generated code may be sub-par, as it is not using ActionScript's optional type declarations. With that said, I think it wouldn't be too difficult to make the above modifications to scxml-js so that it generates ActionScript-friendly code. I may be able to spend some cycles on this, if you would be interested in using it in your research. Let me know what you think. Cheers, Jake On 11-01-30 01:43 AM, Gavin Lei wrote: > Hi Jake, > > Thank you for your help and you have done a good job. I am not very familiar > with ECMAScript, it seems that ECMAScript is some kind of JavaScript. > I do not think ActionScript is a superset of ECMAScript. ActionScript is a > kind a Flex/Flash script languare, we usually use it to develop some kind of > Flash application, a ball or a small guy move in the screen something. And > it is a Object-Oriented language, just like JAVA and we can use it to parse > XML document very convenient. > > In Flash/Flex application, we usually write much state or transition > relative code to control an object in the canvas, if we hava an ActionScript > SCXML engine, i think it will improve our Flash/Flex develop progress. And i > search this topic in Google and find some relative requests from developers, > so i have this idea and post it here to expect more advises :-) > > 在 2011年1月30日 下午12:28，Jacob Beard <jbea...@cs.mcgill.ca>写道： > >> Hi Gavin, >> >> I've developed scxml-js, a SCXML-to-ECMAScript compiler as a part of >> last year's Google Summer of Code. In addition to continuing to develop >> this compiler, I'm currently using it in my research on developing user >> interface with Statecharts. I've never worked with ActionScript before, >> but my understanding is that it is a superset of ECMAScript. Therefore, >> the ECMAScript code generated by scxml-js might also be compilable with >> an ActionScript compiler. Even if the generated code is not directly >> compilable, it might be easier to create an ActionScript backend for >> scxml-js based on the existing ECMAScript backend, rather than writing >> your own interpreter from scratch. You can find more information on >> scxml-js here: http://commons.apache.org/sandbox/gsoc/2010/scxml-js/ >> >> If you have any questions, please don't hesitate to ask. Thanks, >> >> Jake >> >> >> On 11-01-29 10:51 PM, Gavin Lei wrote: >>> Hi guys, >>> >>> I am a doctor student from China. My name is Gavin Lei. I have much >>> Flex/Flash development experience, and you know that we usually use Flash >>> actionscript to develop some cartoon application, such as some thing move >> in >>> the screen. Recently, i noticed that SCXML may be a good solution for >> this >>> kind of application, it can control state and transation very well. >>> >>> But sadly i can not get any good ActionScript based SCXML engine, and we >>> know we have a Java based SCXML engine under Apache Commons, so i want to >>> develop a similar actionscript based SCXML engine. I will finish this job >>> step by step: >>> >>> step 1: >>> Finish basic element parse job for SCXML document, these elements >> includes: >>> SCXML,state,transition,parallel,initial,final,onentry,onexit and some >> other >>> relative basic element. I will implenent them in actionscript, parse them >>> into ActionScript object. >>> >>> step 2: >>> Finish execute content elements parse job for SCXML document, parse >> Raise, >>> If, ElseIf, Else and Log into Actionscript object, and we should involve >>> Data Model elements parse job too, for example, we usually use datamodel >>> element as If elements' parameter >>> >>> step 3: >>> Just like Commons SCXML engine, we should build TriggerEvent, Step, >> Status >>> and SCInstance and basic SCXMLExecutor here, package a basic SCXML >> executor >>> engine here. >>> >>> After these jobs, i will put myself upon thinking about the most useful >>> CustomAction implemention in this ActionScript SCXML engine. >>> >>> Any good advises? please let me know, thank you. >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
