On 7/12/16, 3:57 PM, "Greg Dove" <greg.d...@gmail.com> 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
