On 7/12/16, 1:29 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>I did not think about Application. That does put a spanner in the works, >but composition might make sense anyway and proxy everything. It’ll >probably be a lot of work, and there’s probably other things to worry >about first. > >HTML needs to be broken down into 3 categories: Normal DOM elements, SVG, >and Canvas. I'm not quite sure what we'll end up doing for SVG, but for Canvas, I was sort of expecting the HTML5 component set to leverage Canvas. Maybe you want to fill out the HTML5 component set. I think SVG will be handled in skinnable views for the HTML component set. > >Transformations on DOM elements need to be done using CSS, and that >should probably be delegated to a IValuesImpl. It’s supported in IE10 and >later and in IE9 with a prefix.[1] >I think SVG can use CSS as well, but for transforms, they can be >specified directly. >Canvas has a transform method which takes a matrix as well. EaselJS has a >Matrix2D object to simplify matrix transforms. A base class in the HTML5 component set can be heavier and expose other properties. Since Flash has a transform property and Canvas has a transform method, we might want to pick a different name, or flatten the API. Maybe a "transformMatrix" property. IIRC, the Flash transform contains more than one matrix. > >Personally, I don’t think I want to use a Spark port for my app because >it’s so heavy. I’m currently doing inventory on exactly which features of >Spark and MX we’re currently using. It will probably make more sense to >add support (as Beads) to regular FlexJS rather than pull in the entire >Spark dependency tree. We’ve been going back and forth between SVG and >Canvas, and I think we’re going to go with a canvas implementation for >object manipulation. I’m probably going to use regular FlexJS components >for UI elements. > >That said, it might be interesting to see what happens when I try the >Spark port. Yeah, well it will be a while before you can try it. It needs more volunteers. I'd much prefer to see more features added in a pay-as-you-go manner to the Basic set. I'm hoping that the APIs in UIBase are the "fundamental" APIs and all other display capabilities can be added as plug-ins/beads. I haven't figured out if there is a way to hide all of the inherited flash.*.* APIs from code intelligence in the IDEs but we should look into doing that. Longer term, I dream of a new ASDoc tool written in FlexJS that can categorize/filter APIs. The beads have to expose public APIs to communicate with the strand and other beads that the Application Developer doesn't need to consider. So then, if you do start adding things like rotation as a plug-in, you are effectively using composition, whether or not the "fundamental" APIs are using subclassing or not, and you should run into fewer issues conflicting with the built-in flash APIs. I think you can then do things like have flexjs Rectangle not subclass Flash rectangle and proxy/marshal back and forth in the plug-in. Thoughts? -Alex
