AFAIK, properties cannot be overridden as getters and setters, so even simple properties can have issues. Yes. Rect Point and Matrix were all classes which caused problems.
Transform is actually quite a bit more complicated than just CSS. For HTML, yes, you probably need CSS3. But for SVG, it’s properties, and for canvas, I think it’s methods. Right now, we only have a transform bead for SVG which uses SVG property transforms because browser support for CSS transforms is very weak. What we ended up doing for transform was change the references from transform.matrix to transformMatrix. If our transformations were more complex, we might have needed a more complex Transform object, but we were only using 2D matrices. > Maybe the right answer is to take your sprite-wrapping and just make another > component set in parallel to the basic set. This makes sense to me. I’m fine with having another “optimized” component set if that proves to make a difference in performance, but I think most folks migrating code will want to use “wrapped” components to allow the easiest migration. Thanks, Harbs On Oct 19, 2016, at 8:07 PM, Alex Harui <aha...@adobe.com> wrote: > > > 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 >
