You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2016/07/10 20:32:18 UTC
[FlexJS] subclassed Flash classes and casting
I just added some casting to Point, Rectangle and Matrix. The reason for this is that Flex objects are expecting org.apache.flex.geom instead of flash.geom classes. Any objects originating from Flash causes compiler errors on the Flex side.
I’m sure there are other classes which have this issue (MouseEvent and its Point objects come to mind. If folks could keep this in mind when working on these kinds of classes, that would be great.
I ran into one issue related to this that I did not find a solution for:
Rectangle has a few getters and setters which take and return Point objects (i.e. size, topLeft and bottomRight). Changing the getters to return org.apache.flex.geom.Point works, but I get a mismatch warning because the setters are type flash.geom.Point. The setter probably SHOULD be flash.geom.Point, but even trying to change them to org.apache.flex.geom.Point did not work because the compiler complains of an incompatible override.
Is there any way around this problem?
Harbs
AW: [FlexJS] subclassed Flash classes and casting
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi,
I still think using common interfaces as contract for writing code would simplify things. We could have "FlexEvent" for example and base the API on this, just as an example: There could be a "FlashFlexEvent" which extends FlexEvent with things specific to Flash and a JSFlexEvent that has things specific to JavaScript. I still don't see how this would be a performance thing to code against FlexEvent in general and cast in case some platform specialities are needed. Isn't JavaScript typeless? I think on the JS side there shouldn't be any casts needed to access the JS specific parts.
Does anyone claiming that this could be a performance problem have any proof for this performance degradation? If yes, I would be happy to review that (never stop learning).
Chris
________________________________
Von: Harbs <ha...@gmail.com>
Gesendet: Montag, 11. Juli 2016 08:59:16
An: dev@flex.apache.org
Betreff: Re: [FlexJS] subclassed Flash classes and casting
One simple example is clone() on on both Point and Rectangle. Flash returns a flash Rectangle, but Flex is expecting a flex Rectangle. Another one that I ran into in my own code is union() in Rectangle.
The casting that I did, did not even work. The compiler does not complain if you change the return type to a subclass, but it looks like I’m getting runtime errors.
On Jul 11, 2016, at 8:50 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/10/16, 10:37 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> I believe the reason it’s subclassing flash.geom.Rectangle is because
>> some Flash classes return Rectangles and those cases need to be handled.
>>
>> I’m not sure how the static methods would work and resolving to flash
>> packages should only happen on the SWF side.
>
> I think if no Flash APIs are directly exposed to the SWC's APIs and vice
> versa, then the code in the SWC would convert/proxy/marshall between the
> two Rectangles.
>
> Do you know where some problem places are in the code? It might help to
> examine concrete examples.
>
> -Alex
>
Re: [FlexJS] subclassed Flash classes and casting
Posted by Alex Harui <ah...@adobe.com>.
On 7/12/16, 7:55 AM, "Harbs" <ha...@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 <ah...@adobe.com> wrote:
>
>>
>>
>> On 7/12/16, 1:29 AM, "Harbs" <ha...@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.
>
Re: [FlexJS] subclassed Flash classes and casting
Posted by Harbs <ha...@gmail.com>.
I’ll respond inline although it’ll likely start to get cumbersome.
On Jul 12, 2016, at 5:33 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/12/16, 1:29 AM, "Harbs" <ha...@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.
Re: [FlexJS] subclassed Flash classes and casting
Posted by Alex Harui <ah...@adobe.com>.
On 7/12/16, 1:29 AM, "Harbs" <ha...@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
Re: [FlexJS] subclassed Flash classes and casting
Posted by Harbs <ha...@gmail.com>.
Here’s a good article on transforms (and differences with different methods)
https://css-tricks.com/transforms-on-svg-elements/
On Jul 12, 2016, at 11:29 AM, Harbs <ha...@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.
>
> 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.
>
> 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.
>
> For Canvas, I’m probably going to expand the CreateJS package to have more complete coverage and the ability to use EaselJS Stage objects inside a normal application. I’m also thinking about adding SWF support to the package. The other way to go about it would be to create a new canvas API set instead of using EaselJS. That would be a lot more work in the short term. I don’t know if there would be long-term gains going that route. One thing I noticed when using EaselJS Matrix2Ds is that the behavior did not seem identical to the Flash behavior. I don’t know why that was and how easy it will be to work around the issue.
>
> As far as architecture goes, I think it would be great if different implementations could be swapped out with as little pain as possible. If each rendering path uses the same interfaces, that would be a good thing.
>
> [1]http://caniuse.com/#feat=transforms2d
> On Jul 11, 2016, at 11:16 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 7/11/16, 12:23 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> It could be that instead of subclassing Flash objects, we should be using
>>> composition instead…
>>
>> Maybe. I started out subclassing because it would be lower overhead, and
>> so the main class could be the initial class in the SWF. I think the
>> initial entry point has to subclass Sprite/MovieClip.
>>
>> I know that properties like "transform" are exposed by some underlying
>> flash class right now, but IMO, FlexJS hasn't "exposed" an API unless
>> there is an org.apache.flex.* for it that cross-compiles to JS.
>>
>> Remember that in FlexJS, there is no one way to do something. We are
>> designing the Basic set to thinly wrap what the Browser provides, but with
>> a bit of the Flex "flavor". I wish I'd had more time to spend on the
>> MX/Spark port because it would probably have exposed a lot of these issues
>> as well, but that component set is designed to be much more like regular
>> Flex. IMO, we don't want to blindly implement Flash implementations in
>> the Basic set. We want to understand how the browser implements various
>> features and Flex-ify them by giving the AS and MXML APIs.
>>
>> So, before "transform" becomes the API for rotating things in the Basic
>> set, we want to understand how it is implemented in the browser. Since I
>> think you are working with an existing code base from one of your apps,
>> you might want to stop and consider whether you want to invest in making
>> the MX/Spark port work better. In those component sets we will have a
>> "transform" property.
>>
>> We want FlexJS to be pay-as-you-go, so whatever we do to support rotation
>> must be opt-in and not baked into the base APIs for the Basic set like
>> IUIBase. It should be possible to build a UI that doesn't need rotation
>> and not link in the rotation classes. For the MX/Spark, we are trying to
>> implement as many existing Flex APIs as possible, so the support for
>> rotation could be baked in.
>>
>> In the MX/Spark port, I am planning to pull off one compile trick where
>> imports of flash.*.* automatically get re-interpreted as flex.*.*. You
>> can look at the code in the branch to see that there is a
>> flex.display.DisplayObject that doesn't yet support every
>> flash.display.DisplayObject API. That's how I think we will incrementally
>> implement this port.
>>
>> In a quick look, it looks like in the browser there is a CSS Transform
>> property. And there is 2D and 3D support. So, IMO, in the Basic set, the
>> transforms would be specified in CSS and not as properties so the base
>> classes don't have to carry around the potential for rotation. It could
>> also be a bead of properties that gets plugged in, or even alternate views
>> like TextInputViewWithRotation.
>>
>> At least, that's the way I think about it. We want folks who are coding
>> from scratch to have the smallest fastest product. Incremental baking in
>> of functionality "just-in-case" is why UIComponent is 13,000 lines long
>> and attempts to optimized failed because no one sub-feature was big enough
>> to move the needle, but the sum was just too large and unwieldy.
>> Pay-as-you-go, opt-in, just-in-time are the mantras I would like to see
>> applied to most FlexJS work. In the MX/Spark port, the opposite is true:
>> that component set's job is to minimize migration effort at the cost of
>> size and performance since the Flex app was already bigger and slower than
>> you probably wanted.
>>
>> Thoughts?
>> -Alex
>>
>>>
>>> On Jul 11, 2016, at 10:21 AM, Harbs <ha...@gmail.com> wrote:
>>>
>>>> Sure they are.
>>>>
>>>> Try this:
>>>> var myRect:org.apache.flex.core.graphics.Rect = new
>>>> org.apache.flex.core.graphics.Rect();
>>>> var transform:Matrix = myRect.transform;
>>>>
>>>> On Jul 11, 2016, at 10:16 AM, Alex Harui <ah...@adobe.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 7/11/16, 12:06 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> I believe Bitmaps use Rectangles.
>>>>>
>>>>> OK but flash.display.Bitmap should not be exposed to the SWC's API
>>>>> surface. Bitmap should be wrapped and rectangles in its API should be
>>>>> wrapped as well.
>>>>>
>>>>>>
>>>>>> FlexJS subclasses DisplayObject which returns a Flash Matrix for the
>>>>>> transform. IF you try to use transformPoint() on that, it’ll return
>>>>>> (and
>>>>>> expects) a Flash Point.
>>>>>
>>>>> Again, the transform and flash.geom.Matrix should not be exposed to the
>>>>> SWC's API surface.
>>>>>
>>>>> -Alex
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS] subclassed Flash classes and casting
Posted by Harbs <ha...@gmail.com>.
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.
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.
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.
For Canvas, I’m probably going to expand the CreateJS package to have more complete coverage and the ability to use EaselJS Stage objects inside a normal application. I’m also thinking about adding SWF support to the package. The other way to go about it would be to create a new canvas API set instead of using EaselJS. That would be a lot more work in the short term. I don’t know if there would be long-term gains going that route. One thing I noticed when using EaselJS Matrix2Ds is that the behavior did not seem identical to the Flash behavior. I don’t know why that was and how easy it will be to work around the issue.
As far as architecture goes, I think it would be great if different implementations could be swapped out with as little pain as possible. If each rendering path uses the same interfaces, that would be a good thing.
[1]http://caniuse.com/#feat=transforms2d
On Jul 11, 2016, at 11:16 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/11/16, 12:23 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> It could be that instead of subclassing Flash objects, we should be using
>> composition instead…
>
> Maybe. I started out subclassing because it would be lower overhead, and
> so the main class could be the initial class in the SWF. I think the
> initial entry point has to subclass Sprite/MovieClip.
>
> I know that properties like "transform" are exposed by some underlying
> flash class right now, but IMO, FlexJS hasn't "exposed" an API unless
> there is an org.apache.flex.* for it that cross-compiles to JS.
>
> Remember that in FlexJS, there is no one way to do something. We are
> designing the Basic set to thinly wrap what the Browser provides, but with
> a bit of the Flex "flavor". I wish I'd had more time to spend on the
> MX/Spark port because it would probably have exposed a lot of these issues
> as well, but that component set is designed to be much more like regular
> Flex. IMO, we don't want to blindly implement Flash implementations in
> the Basic set. We want to understand how the browser implements various
> features and Flex-ify them by giving the AS and MXML APIs.
>
> So, before "transform" becomes the API for rotating things in the Basic
> set, we want to understand how it is implemented in the browser. Since I
> think you are working with an existing code base from one of your apps,
> you might want to stop and consider whether you want to invest in making
> the MX/Spark port work better. In those component sets we will have a
> "transform" property.
>
> We want FlexJS to be pay-as-you-go, so whatever we do to support rotation
> must be opt-in and not baked into the base APIs for the Basic set like
> IUIBase. It should be possible to build a UI that doesn't need rotation
> and not link in the rotation classes. For the MX/Spark, we are trying to
> implement as many existing Flex APIs as possible, so the support for
> rotation could be baked in.
>
> In the MX/Spark port, I am planning to pull off one compile trick where
> imports of flash.*.* automatically get re-interpreted as flex.*.*. You
> can look at the code in the branch to see that there is a
> flex.display.DisplayObject that doesn't yet support every
> flash.display.DisplayObject API. That's how I think we will incrementally
> implement this port.
>
> In a quick look, it looks like in the browser there is a CSS Transform
> property. And there is 2D and 3D support. So, IMO, in the Basic set, the
> transforms would be specified in CSS and not as properties so the base
> classes don't have to carry around the potential for rotation. It could
> also be a bead of properties that gets plugged in, or even alternate views
> like TextInputViewWithRotation.
>
> At least, that's the way I think about it. We want folks who are coding
> from scratch to have the smallest fastest product. Incremental baking in
> of functionality "just-in-case" is why UIComponent is 13,000 lines long
> and attempts to optimized failed because no one sub-feature was big enough
> to move the needle, but the sum was just too large and unwieldy.
> Pay-as-you-go, opt-in, just-in-time are the mantras I would like to see
> applied to most FlexJS work. In the MX/Spark port, the opposite is true:
> that component set's job is to minimize migration effort at the cost of
> size and performance since the Flex app was already bigger and slower than
> you probably wanted.
>
> Thoughts?
> -Alex
>
>>
>> On Jul 11, 2016, at 10:21 AM, Harbs <ha...@gmail.com> wrote:
>>
>>> Sure they are.
>>>
>>> Try this:
>>> var myRect:org.apache.flex.core.graphics.Rect = new
>>> org.apache.flex.core.graphics.Rect();
>>> var transform:Matrix = myRect.transform;
>>>
>>> On Jul 11, 2016, at 10:16 AM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>>
>>>>
>>>> On 7/11/16, 12:06 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> I believe Bitmaps use Rectangles.
>>>>
>>>> OK but flash.display.Bitmap should not be exposed to the SWC's API
>>>> surface. Bitmap should be wrapped and rectangles in its API should be
>>>> wrapped as well.
>>>>
>>>>>
>>>>> FlexJS subclasses DisplayObject which returns a Flash Matrix for the
>>>>> transform. IF you try to use transformPoint() on that, it’ll return
>>>>> (and
>>>>> expects) a Flash Point.
>>>>
>>>> Again, the transform and flash.geom.Matrix should not be exposed to the
>>>> SWC's API surface.
>>>>
>>>> -Alex
>>>>
>>>
>>
>
Re: [FlexJS] subclassed Flash classes and casting
Posted by Alex Harui <ah...@adobe.com>.
On 7/11/16, 12:23 AM, "Harbs" <ha...@gmail.com> wrote:
>It could be that instead of subclassing Flash objects, we should be using
>composition instead…
Maybe. I started out subclassing because it would be lower overhead, and
so the main class could be the initial class in the SWF. I think the
initial entry point has to subclass Sprite/MovieClip.
I know that properties like "transform" are exposed by some underlying
flash class right now, but IMO, FlexJS hasn't "exposed" an API unless
there is an org.apache.flex.* for it that cross-compiles to JS.
Remember that in FlexJS, there is no one way to do something. We are
designing the Basic set to thinly wrap what the Browser provides, but with
a bit of the Flex "flavor". I wish I'd had more time to spend on the
MX/Spark port because it would probably have exposed a lot of these issues
as well, but that component set is designed to be much more like regular
Flex. IMO, we don't want to blindly implement Flash implementations in
the Basic set. We want to understand how the browser implements various
features and Flex-ify them by giving the AS and MXML APIs.
So, before "transform" becomes the API for rotating things in the Basic
set, we want to understand how it is implemented in the browser. Since I
think you are working with an existing code base from one of your apps,
you might want to stop and consider whether you want to invest in making
the MX/Spark port work better. In those component sets we will have a
"transform" property.
We want FlexJS to be pay-as-you-go, so whatever we do to support rotation
must be opt-in and not baked into the base APIs for the Basic set like
IUIBase. It should be possible to build a UI that doesn't need rotation
and not link in the rotation classes. For the MX/Spark, we are trying to
implement as many existing Flex APIs as possible, so the support for
rotation could be baked in.
In the MX/Spark port, I am planning to pull off one compile trick where
imports of flash.*.* automatically get re-interpreted as flex.*.*. You
can look at the code in the branch to see that there is a
flex.display.DisplayObject that doesn't yet support every
flash.display.DisplayObject API. That's how I think we will incrementally
implement this port.
In a quick look, it looks like in the browser there is a CSS Transform
property. And there is 2D and 3D support. So, IMO, in the Basic set, the
transforms would be specified in CSS and not as properties so the base
classes don't have to carry around the potential for rotation. It could
also be a bead of properties that gets plugged in, or even alternate views
like TextInputViewWithRotation.
At least, that's the way I think about it. We want folks who are coding
from scratch to have the smallest fastest product. Incremental baking in
of functionality "just-in-case" is why UIComponent is 13,000 lines long
and attempts to optimized failed because no one sub-feature was big enough
to move the needle, but the sum was just too large and unwieldy.
Pay-as-you-go, opt-in, just-in-time are the mantras I would like to see
applied to most FlexJS work. In the MX/Spark port, the opposite is true:
that component set's job is to minimize migration effort at the cost of
size and performance since the Flex app was already bigger and slower than
you probably wanted.
Thoughts?
-Alex
>
>On Jul 11, 2016, at 10:21 AM, Harbs <ha...@gmail.com> wrote:
>
>> Sure they are.
>>
>> Try this:
>> var myRect:org.apache.flex.core.graphics.Rect = new
>>org.apache.flex.core.graphics.Rect();
>> var transform:Matrix = myRect.transform;
>>
>> On Jul 11, 2016, at 10:16 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>>
>>>
>>> On 7/11/16, 12:06 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> I believe Bitmaps use Rectangles.
>>>
>>> OK but flash.display.Bitmap should not be exposed to the SWC's API
>>> surface. Bitmap should be wrapped and rectangles in its API should be
>>> wrapped as well.
>>>
>>>>
>>>> FlexJS subclasses DisplayObject which returns a Flash Matrix for the
>>>> transform. IF you try to use transformPoint() on that, it’ll return
>>>>(and
>>>> expects) a Flash Point.
>>>
>>> Again, the transform and flash.geom.Matrix should not be exposed to the
>>> SWC's API surface.
>>>
>>> -Alex
>>>
>>
>
Re: [FlexJS] subclassed Flash classes and casting
Posted by Harbs <ha...@gmail.com>.
It could be that instead of subclassing Flash objects, we should be using composition instead…
On Jul 11, 2016, at 10:21 AM, Harbs <ha...@gmail.com> wrote:
> Sure they are.
>
> Try this:
> var myRect:org.apache.flex.core.graphics.Rect = new org.apache.flex.core.graphics.Rect();
> var transform:Matrix = myRect.transform;
>
> On Jul 11, 2016, at 10:16 AM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 7/11/16, 12:06 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> I believe Bitmaps use Rectangles.
>>
>> OK but flash.display.Bitmap should not be exposed to the SWC's API
>> surface. Bitmap should be wrapped and rectangles in its API should be
>> wrapped as well.
>>
>>>
>>> FlexJS subclasses DisplayObject which returns a Flash Matrix for the
>>> transform. IF you try to use transformPoint() on that, it’ll return (and
>>> expects) a Flash Point.
>>
>> Again, the transform and flash.geom.Matrix should not be exposed to the
>> SWC's API surface.
>>
>> -Alex
>>
>
Re: [FlexJS] subclassed Flash classes and casting
Posted by Harbs <ha...@gmail.com>.
Sure they are.
Try this:
var myRect:org.apache.flex.core.graphics.Rect = new org.apache.flex.core.graphics.Rect();
var transform:Matrix = myRect.transform;
On Jul 11, 2016, at 10:16 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/11/16, 12:06 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> I believe Bitmaps use Rectangles.
>
> OK but flash.display.Bitmap should not be exposed to the SWC's API
> surface. Bitmap should be wrapped and rectangles in its API should be
> wrapped as well.
>
>>
>> FlexJS subclasses DisplayObject which returns a Flash Matrix for the
>> transform. IF you try to use transformPoint() on that, it’ll return (and
>> expects) a Flash Point.
>
> Again, the transform and flash.geom.Matrix should not be exposed to the
> SWC's API surface.
>
> -Alex
>
Re: [FlexJS] subclassed Flash classes and casting
Posted by Alex Harui <ah...@adobe.com>.
On 7/11/16, 12:06 AM, "Harbs" <ha...@gmail.com> wrote:
>I believe Bitmaps use Rectangles.
OK but flash.display.Bitmap should not be exposed to the SWC's API
surface. Bitmap should be wrapped and rectangles in its API should be
wrapped as well.
>
>FlexJS subclasses DisplayObject which returns a Flash Matrix for the
>transform. IF you try to use transformPoint() on that, it’ll return (and
>expects) a Flash Point.
Again, the transform and flash.geom.Matrix should not be exposed to the
SWC's API surface.
-Alex
Re: [FlexJS] subclassed Flash classes and casting
Posted by Harbs <ha...@gmail.com>.
I believe Bitmaps use Rectangles.
FlexJS subclasses DisplayObject which returns a Flash Matrix for the transform. IF you try to use transformPoint() on that, it’ll return (and expects) a Flash Point.
I’m sure there’s more examples.
On Jul 11, 2016, at 10:03 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/10/16, 11:59 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> One simple example is clone() on on both Point and Rectangle. Flash
>> returns a flash Rectangle, but Flex is expecting a flex Rectangle.
>> Another one that I ran into in my own code is union() in Rectangle.
>>
>> The casting that I did, did not even work. The compiler does not complain
>> if you change the return type to a subclass, but it looks like I’m
>> getting runtime errors.
>
> Well sure, that's going to be a problem if flexjs rectangle subclasses
> flash.geom.Rectangle, but what I'm interested in is actual usage of
> Rectangle in our code base. IOW, where in our code do we pass a Rectangle
> to Flash or get one back from Flash (other than in
> org.apache.flex.geom.Rectangle)?
>
> -Alex
>
Re: [FlexJS] subclassed Flash classes and casting
Posted by Alex Harui <ah...@adobe.com>.
On 7/10/16, 11:59 PM, "Harbs" <ha...@gmail.com> wrote:
>One simple example is clone() on on both Point and Rectangle. Flash
>returns a flash Rectangle, but Flex is expecting a flex Rectangle.
>Another one that I ran into in my own code is union() in Rectangle.
>
>The casting that I did, did not even work. The compiler does not complain
>if you change the return type to a subclass, but it looks like I’m
>getting runtime errors.
Well sure, that's going to be a problem if flexjs rectangle subclasses
flash.geom.Rectangle, but what I'm interested in is actual usage of
Rectangle in our code base. IOW, where in our code do we pass a Rectangle
to Flash or get one back from Flash (other than in
org.apache.flex.geom.Rectangle)?
-Alex
Re: [FlexJS] subclassed Flash classes and casting
Posted by Harbs <ha...@gmail.com>.
One simple example is clone() on on both Point and Rectangle. Flash returns a flash Rectangle, but Flex is expecting a flex Rectangle. Another one that I ran into in my own code is union() in Rectangle.
The casting that I did, did not even work. The compiler does not complain if you change the return type to a subclass, but it looks like I’m getting runtime errors.
On Jul 11, 2016, at 8:50 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/10/16, 10:37 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> I believe the reason it’s subclassing flash.geom.Rectangle is because
>> some Flash classes return Rectangles and those cases need to be handled.
>>
>> I’m not sure how the static methods would work and resolving to flash
>> packages should only happen on the SWF side.
>
> I think if no Flash APIs are directly exposed to the SWC's APIs and vice
> versa, then the code in the SWC would convert/proxy/marshall between the
> two Rectangles.
>
> Do you know where some problem places are in the code? It might help to
> examine concrete examples.
>
> -Alex
>
Re: [FlexJS] subclassed Flash classes and casting
Posted by Alex Harui <ah...@adobe.com>.
On 7/10/16, 10:37 PM, "Harbs" <ha...@gmail.com> wrote:
>I believe the reason it’s subclassing flash.geom.Rectangle is because
>some Flash classes return Rectangles and those cases need to be handled.
>
>I’m not sure how the static methods would work and resolving to flash
>packages should only happen on the SWF side.
I think if no Flash APIs are directly exposed to the SWC's APIs and vice
versa, then the code in the SWC would convert/proxy/marshall between the
two Rectangles.
Do you know where some problem places are in the code? It might help to
examine concrete examples.
-Alex
Re: [FlexJS] subclassed Flash classes and casting
Posted by Harbs <ha...@gmail.com>.
I believe the reason it’s subclassing flash.geom.Rectangle is because some Flash classes return Rectangles and those cases need to be handled.
I’m not sure how the static methods would work and resolving to flash packages should only happen on the SWF side.
On Jul 11, 2016, at 8:18 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/10/16, 1:32 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> I just added some casting to Point, Rectangle and Matrix. The reason for
>> this is that Flex objects are expecting org.apache.flex.geom instead of
>> flash.geom classes. Any objects originating from Flash causes compiler
>> errors on the Flex side.
>>
>> I’m sure there are other classes which have this issue (MouseEvent and
>> its Point objects come to mind. If folks could keep this in mind when
>> working on these kinds of classes, that would be great.
>>
>> I ran into one issue related to this that I did not find a solution for:
>>
>> Rectangle has a few getters and setters which take and return Point
>> objects (i.e. size, topLeft and bottomRight). Changing the getters to
>> return org.apache.flex.geom.Point works, but I get a mismatch warning
>> because the setters are type flash.geom.Point. The setter probably SHOULD
>> be flash.geom.Point, but even trying to change them to
>> org.apache.flex.geom.Point did not work because the compiler complains of
>> an incompatible override.
>>
>> Is there any way around this problem?
>
> Maybe. I think we could try not having org.apache.flex.geom.Rectangle
> extend flash.geom.Rectangle. Some utility/static method would convert
> to/from flash.geom.Rectangle as needed. I think it would make for an
> extra step when using Flash APIs, but maybe that is less painful than what
> we have now.
>
> It might be possible to do some compiler tricks. I haven't thought it all
> through, but what if the compiler always resolved
> org.apache.flex.geom.Rectangle as flash.geom.Rectangle?
>
> -Alex
Re: [FlexJS] subclassed Flash classes and casting
Posted by Alex Harui <ah...@adobe.com>.
On 7/10/16, 1:32 PM, "Harbs" <ha...@gmail.com> wrote:
>I just added some casting to Point, Rectangle and Matrix. The reason for
>this is that Flex objects are expecting org.apache.flex.geom instead of
>flash.geom classes. Any objects originating from Flash causes compiler
>errors on the Flex side.
>
>I’m sure there are other classes which have this issue (MouseEvent and
>its Point objects come to mind. If folks could keep this in mind when
>working on these kinds of classes, that would be great.
>
>I ran into one issue related to this that I did not find a solution for:
>
>Rectangle has a few getters and setters which take and return Point
>objects (i.e. size, topLeft and bottomRight). Changing the getters to
>return org.apache.flex.geom.Point works, but I get a mismatch warning
>because the setters are type flash.geom.Point. The setter probably SHOULD
>be flash.geom.Point, but even trying to change them to
>org.apache.flex.geom.Point did not work because the compiler complains of
>an incompatible override.
>
>Is there any way around this problem?
Maybe. I think we could try not having org.apache.flex.geom.Rectangle
extend flash.geom.Rectangle. Some utility/static method would convert
to/from flash.geom.Rectangle as needed. I think it would make for an
extra step when using Flash APIs, but maybe that is less painful than what
we have now.
It might be possible to do some compiler tricks. I haven't thought it all
through, but what if the compiler always resolved
org.apache.flex.geom.Rectangle as flash.geom.Rectangle?
-Alex