Monkey patching does not work very well. Here’s my setup (on Mac — Windows is similar):
1) Follow the instructions here to get your basic environment setup: https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Developer+Setup 2) If you want to use Flash Builder, read the section on Flash Builder on the above page and this as well: https://cwiki.apache.org/confluence/display/FLEX/Using+FlexJS+with+Adobe+Flash+Builder 3) I have a shell script to set all my environment variables in each shell like this: #!/bin/sh export FALCON_HOME=/Users/harbs/Documents/ApacheFlex/flex-falcon/compiler export FLEXUNIT_HOME=/Users/harbs/Documents/ApacheFlex/flex-flexunit export FLEX_HOME=/Users/harbs/Documents/ApacheFlex/flex-sdk export AIR_HOME=/Users/harbs/Documents/ApacheFlex/frameworks/AIRSDK_Compiler export PLAYERGLOBAL_HOME=/Users/harbs/Documents/ApacheFlex/frameworks/libs/player export FLASHPLAYER_DEBUGGER=/Users/harbs/Documents/ApacheFlex/frameworks/Flash\ Player\ Debugger.app/Contents/MacOS/Flash\ Player\ Debugger export FLEXJS_HOME=/Users/harbs/Documents/ApacheFlex/flex-asjs 4) You can then run ant on either flex-asjs or any one of the individual Projects such as Core. For doing incremental builds of the projects, that is highly recommended. 5) To use the changes with a nightly build, I run the following script which copies the changed files: rsync -r -u --include="*.swc" /Users/harbs/Documents/ApacheFlex/flex-asjs/frameworks/libs /Users/harbs/Documents/Apache\ Flex\ Dist/FlexJSNightly/frameworks rsync -r -u --include="*.js" /Users/harbs/Documents/ApacheFlex/flex-asjs/frameworks/js/FlexJS/generated-sources /Users/harbs/Documents/Apache\ Flex\ Dist/FlexJSNightly/frameworks/js/FlexJS HTH, Harbs On Jul 14, 2016, at 9:33 AM, Greg Dove <[email protected]> wrote: > Harbs and Alex, thanks for your explanations. > > I guess 'drop-in' replacement is quite unrealistic. But I think if could be > closer to the IDataInput/IDataOutput, and given that ByteArray is a common > utility class in many libraries, particularly for low-level parsing of > various formats, the closer the better imo. > > In my experience most ByteArray use seems to be mostly sequential reading > or writing which uses the flash class' read/write methods instead of array > access. So in terms of migration effort, swapping array access out wherever > it is used to the method-based getByteAt, setByteAt is not so bad. > > Harbs, I picked up the recent updates from nightly and there is more there > than what I had for sure, but more to do I think - perhaps I can help - I > will try to work on this over the next day or so and share where I get to. > After using Flex for 8 years I am kinda struggling with my setup for > FlexJS, and I'm not sure if I can use monkey-patching for checking the > additions I have in mind.... which I could do in the past with the regular > flex sdk. > > > cheers > Greg > > > On Wed, Jul 13, 2016 at 6:46 PM, Alex Harui <[email protected]> wrote: > >> >> >> On 7/12/16, 3:57 PM, "Greg Dove" <[email protected]> wrote: >> >>> I have dipped my toes into FlexJS for the first time. I am evaluating >>> FlexJS for a migration away from Flex4/flash and figured I would try to >>> cross compile an isolated a3 library that is a core dependency for my >>> client's project. >>> >>> It seems there is no direct substitute for flash.utils.ByteArray on the js >>> side, The nearest I could find was org.apache.flex.utils.BinaryData which >>> seems to be a partial proxy implementation for ByteArray. >>> >>> BinaryData does not implement IDataInput and IDataOutput and therefore >>> cannot simply be used in place of the original ByteArray in arbitrary >>> code. >>> >>> Is this intentional? Or is this WIP, with a plan to get to the original >>> interfaces? Or am I looking in the wrong place for what I am trying to do >>> (entirely possible!). >> >> IMO, FlexJS is a WIP, but there is no "plan" per-se. >> >> Unlike Flex, FlexJS is intended to support multiple component sets. The >> Basic set we have released so far is meant to thinly wrap Browser/HTML/JS >> APIs so that when you compose an application, the result has as little >> overhead as possible when compared to writing an HTML/JS app directly in >> JS. It isn't a goal for these components to emulate Flash. Instead, the >> SWF versions of those components are trying to emulate the browser. >> >> There is an experiment under way to try to see how hard it would be to >> make a component set that supports most (but not all) Flex APIs. We >> received several opinions that the Basic set is too big of a migration >> step for existing Flex code bases. Flex is already heavy so making a >> heavy component set that lowers migration pain by spending code on >> emulating more of Flex in the browser might be viable. This component set >> is a ton of work and isn't a top priority on my list right now and could >> use more volunteers to help. >> >> ByteArray isn't even a Flex API. But it is often used so I suppose a >> component set that emulates Flex will likely have to support most of >> ByteArray. The Basic set is supposed to be pay-as-you-go and use plugins >> for additional functionality, so IDataInput/IDataOutput might be replaced >> by plug-ins that support similar APIs. >> >> But really, what actually happens is often up to the person that codes it. >> We don't have resources to mark every API as needing implementation, and >> since we want to make many implementations as plugins, the API may not be >> the same anyway, so we just need folks to jump in and deal with holes in >> the documentation and code and help make things better for the next person >> who jumps in. >> >> HTH, >> -Alex >> >>
