I’ll respond inline although it’ll likely start to get cumbersome. On Jul 12, 2016, at 5:33 PM, Alex Harui <aha...@adobe.com> wrote:
> > > 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. I think there should be separate packages for HTML, SVG and Canvas. I’m not sure what “HTML5” means and the package does not seem to have any functionality on its own. It seems to me that all 3 (or 4) packages should have the same base signature using interfaces defined in Core. So org.apache.flex.html.Label would implement ILabel and could be easily swapped out for a org.apache.flex.svg.Label or a org.apache.flex.cavas.Label. As far as HTML5 goes, I think it should be removed in favor of svg and cavas, or it can be HTML based, but have a heavier set of capabilities which might allow SVG skinning and the like. >> >> 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. You are correct that Flash has a Transform object which has properties for all the transformations which an object could have. The most commonly used is probably transform.matrix which is a Matrix of the 2D transformation. There’s also matrix3D, projections and color transformations none of which I’ve every personally used. I think these all has relative equivalents on the HTML side (at least with SVG and Canvas). > >> >> 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. A new tool sounds very nice. One thing’s for sure; FlexJS needs a lot in way of documentation… ;-) > 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 I haven’t quite wrapped my head around how the communication is currently working with Beads and Strands. That’s one of the things on my “to do” list.
