On 7/12/16, 7:55 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>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. I thought HTML5 had some new HTMLElements and the components in there would wrap them. But sure, multiple sets are fine. I'm not sure we have to have an ILabel unless you want to swap at runtime. A lot of swapping can be done simply by changing the MXML manifest and your import statements. > >>> >>> 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). Yes, and I think their JS APIs are not combined into a single data structure so a good opportunity to create a different API that is lighter-weight, and pay-as-you-go for the JS side and thus less likely to conflict with existing Flash APIs. > >> >>> >>> 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. >
