On 7/11/16, 12:23 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>It could be that instead of subclassing Flash objects, we should be using >composition instead… Maybe. I started out subclassing because it would be lower overhead, and so the main class could be the initial class in the SWF. I think the initial entry point has to subclass Sprite/MovieClip. I know that properties like "transform" are exposed by some underlying flash class right now, but IMO, FlexJS hasn't "exposed" an API unless there is an org.apache.flex.* for it that cross-compiles to JS. Remember that in FlexJS, there is no one way to do something. We are designing the Basic set to thinly wrap what the Browser provides, but with a bit of the Flex "flavor". I wish I'd had more time to spend on the MX/Spark port because it would probably have exposed a lot of these issues as well, but that component set is designed to be much more like regular Flex. IMO, we don't want to blindly implement Flash implementations in the Basic set. We want to understand how the browser implements various features and Flex-ify them by giving the AS and MXML APIs. So, before "transform" becomes the API for rotating things in the Basic set, we want to understand how it is implemented in the browser. Since I think you are working with an existing code base from one of your apps, you might want to stop and consider whether you want to invest in making the MX/Spark port work better. In those component sets we will have a "transform" property. We want FlexJS to be pay-as-you-go, so whatever we do to support rotation must be opt-in and not baked into the base APIs for the Basic set like IUIBase. It should be possible to build a UI that doesn't need rotation and not link in the rotation classes. For the MX/Spark, we are trying to implement as many existing Flex APIs as possible, so the support for rotation could be baked in. In the MX/Spark port, I am planning to pull off one compile trick where imports of flash.*.* automatically get re-interpreted as flex.*.*. You can look at the code in the branch to see that there is a flex.display.DisplayObject that doesn't yet support every flash.display.DisplayObject API. That's how I think we will incrementally implement this port. In a quick look, it looks like in the browser there is a CSS Transform property. And there is 2D and 3D support. So, IMO, in the Basic set, the transforms would be specified in CSS and not as properties so the base classes don't have to carry around the potential for rotation. It could also be a bead of properties that gets plugged in, or even alternate views like TextInputViewWithRotation. At least, that's the way I think about it. We want folks who are coding from scratch to have the smallest fastest product. Incremental baking in of functionality "just-in-case" is why UIComponent is 13,000 lines long and attempts to optimized failed because no one sub-feature was big enough to move the needle, but the sum was just too large and unwieldy. Pay-as-you-go, opt-in, just-in-time are the mantras I would like to see applied to most FlexJS work. In the MX/Spark port, the opposite is true: that component set's job is to minimize migration effort at the cost of size and performance since the Flex app was already bigger and slower than you probably wanted. Thoughts? -Alex > >On Jul 11, 2016, at 10:21 AM, Harbs <harbs.li...@gmail.com> wrote: > >> Sure they are. >> >> Try this: >> var myRect:org.apache.flex.core.graphics.Rect = new >>org.apache.flex.core.graphics.Rect(); >> var transform:Matrix = myRect.transform; >> >> On Jul 11, 2016, at 10:16 AM, Alex Harui <aha...@adobe.com> wrote: >> >>> >>> >>> On 7/11/16, 12:06 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>> >>>> I believe Bitmaps use Rectangles. >>> >>> OK but flash.display.Bitmap should not be exposed to the SWC's API >>> surface. Bitmap should be wrapped and rectangles in its API should be >>> wrapped as well. >>> >>>> >>>> FlexJS subclasses DisplayObject which returns a Flash Matrix for the >>>> transform. IF you try to use transformPoint() on that, it’ll return >>>>(and >>>> expects) a Flash Point. >>> >>> Again, the transform and flash.geom.Matrix should not be exposed to the >>> SWC's API surface. >>> >>> -Alex >>> >> >
