On 10/19/16, 2:16 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>I don’t remember all the conflicts we had. Warnings would have helped >somewhat but not totally. Here’s one example (of many): > >We were using a Sprite Image component, and we needed to migrate to a >FlexJS BinaryImage component. Some of the properties we were using were: >scaleMode, smooth, cacheAsBitmap, blendMode, filters, mask, rotation, >scaleX, scaleY > >The neatest way to migrate our code was to create a subclass of >BinaryImage which implements all (or rather most of) these properties and >use transformation, clipping, etc. beads to implement the functionality. >This allows all the code in our app which uses the original Spark >components to remain the same. Inheriting from DisplayObject (and >children) would make using the same properties impossible because these >properties are already used in Flash. For properties that are scalars (Number, String), it is easy to override. But AIUI, where the type is an object like DisplayObjectContainer, Transform, Rect, etc, that's where it gets hard, right? You want to create an org.apache.flex.geom.Transform class and make that the type of the "transform" property but the compiler currently won't let you do that. FWIW, the design goal for the basic set of components was to tune it towards the HTML/JS platform. It was not a priority to maintain and emulate Flash API surfaces. I did choose to do so for x,y,width,height,visible, but didn't really want to propagate properties for every other Sprite API. Taking a quick look this morning, I see that for HTML/JS, transform is a CSS property. Thus, I would not have chosen to treat transform as a property in a FlexJS image component. It would remain a style and specified in MXML like we specify other styles, and a bead would pick up the style and "do the right thing" on the SWF side. Then you probably wouldn't have hit an API conflict. And then, the JS would run as optimally as it could because the developer could specify the transform in CSS and no code at runtime on the JS side would have to apply it. The browser would just see the DOM and the CSS and "do it". That said, when someone got around to emulating the Spark components they would have eventually hit this same problem, but for emulating Spark, the infrastructure is so fat anyway, wrapping could be an plausible option. But IIRC, there still is a pain point for something as simple as the parent property. And I think there were some issues with Rectangles in APIs as well, but I'm not sure. Basically, my experience from Flex is that, as you add code to make a perfect world, you end up tempting others to undercut you with lighter weight frameworks and fracture the community. I want FlexJS to own the lowest-level so everybody builds on top of it. Tools should be able to give you the developer productivity without having to pay for it at runtime. I spent a great deal of time profiling for folks who were just about to go production and realized that their app had grown too fat and slow. Choosing to emulate Flash APIs creates more conflicts and is less optimal for the JS side, but does mean there is more migration work to do. Maybe the right answer is to take your sprite-wrapping and just make another component set in parallel to the basic set. There is certainly an option for someone to make a "not-quite-full-emulation" or "less-migration" set of components for FlexJS that is someplace between the basic set and the full Spark/MX port. It would be interesting to see how many beads like the disabled bead could be used for both component sets. -Alex
