Re: [FlexJS] ElementWrapper.forwarder() Changes Target
On 8/17/16, 11:25 PM, "yishayw" wrote: >If I listen on a click event on the application I expect to get all click >events bubbled up from contained elements. That works, however the target >is >the application rather than the element that was clicked on. This is due >to >ElementWrapper.forwarder() re-dispatching the event, where the >ElementWrapper is the application. Is this by design? Well yes, for events dispatched from the wrapped element, but you are correct that it won't work for bubbled events. There is no way to set the target of an event in Flash. We might have to build our own queue of listeners and call them directly, but even then, the target will be a wrapped element and not its wrapper. This might be an issue that kills the plan of wrapping Flash DisplayObjects. We'll see if someone comes up with a "easy" way of getting it to work. I'll ponder it while I'm sleeping. -Alex
Will we have a new release out the door till 8th of September?
Hi, as I mentioned a few days ago, I will be having a talk on FlexJS in Hamburg on 08.09.2016 (http://programmplaner.solutions.hamburg/#/). I hope we will be able to ship a new version with the Maven support till then? Do you think that's possible? What are we missing? I would suggest that I stage a Maven release and you do an Ant release based on the Maven Release Tag. Maven does two commits during a release: 1. change the version number to the release version, 2. Change the version to the next development version. It tags the commit number 1 automatically. So if you would do an Ant release from that state, the version number should be consistent. The only thing we would need to do is merge both ends back together, but that shouldn't be an issue as the files touched during an Ant release should be different than those of a Maven release. The only thing I would need to do before that, would be to prepare 1.0.0 releases of the build-helper-maven plugin and the little jburg-types jar. I could initiate this any time. Chris
Re: [FlexJS] ElementWrapper.forwarder() Changes Target
IMO, the “right” way to fix this is by dispatching events from the flexjs_wrapper and implement event bubbling up the FlexJS element chain. Yishay did not mention them, but we were having a whole slew of problems related to events: 1. Event targets being lost (which he mentioned here) 2. Fixing that seems to mess up bubbling. (again) 3. clone() and cloneEvent() is a bit weird. You cannot dispatch cloneEvent() directly without casting it first (because it’s the Flash EventDispatcher which does the dispatching) and you cannot override clone() using a Flex event because it’s an incompatible override. 4. BrowserEvents vs. MouseEvent We were actually kind of confused by MouseEvent, because in the Browser, only BrowserEvents seem to be used. What’s the point of MouseEvents? 5. EventDispatcher took a Flash event even though we really need a Flex event. See # 3. 6. EventDispatcher cannot take an IFlexEvent. This kind of defeats the point of have an IFlexEvent in the first place. 7. BrowserEvent was missing localX and localY (maybe fixed) 8. I really think that MouseEvent should probably subclass event, but it can’t because it subclasses Flash MouseEvent. It it wrapped the events, this problem would be solved. To me, all this points to the fact that we should have a Flex event bus which would be completely cross-platform and wrap browser and Flash events. On Aug 18, 2016, at 10:05 AM, Alex Harui wrote: > > > On 8/17/16, 11:25 PM, "yishayw" wrote: > >> If I listen on a click event on the application I expect to get all click >> events bubbled up from contained elements. That works, however the target >> is >> the application rather than the element that was clicked on. This is due >> to >> ElementWrapper.forwarder() re-dispatching the event, where the >> ElementWrapper is the application. Is this by design? > > Well yes, for events dispatched from the wrapped element, but you are > correct that it won't work for bubbled events. There is no way to set the > target of an event in Flash. We might have to build our own queue of > listeners and call them directly, but even then, the target will be a > wrapped element and not its wrapper. > > This might be an issue that kills the plan of wrapping Flash > DisplayObjects. We'll see if someone comes up with a "easy" way of > getting it to work. I'll ponder it while I'm sleeping. > > -Alex >
Re: [FlexJS] numElements and contentView
Hi Alex,
Can you please tell me how to unsubscribe?
Thanks,
Jack
On 8/8/16 12:55 AM, Alex Harui wrote:
On 8/7/16, 2:06 AM, "yishayw" wrote:
We have code that removes all elements in a container. It does something
like
while (container.numElements) {container.removeElementAt(0)}
The problem was that ContainerBase.removeElementAt(0) actually did
ContainerBase.contentView.removeElementAt(0) while container.numElements
was
returning ContainerBase.numElements, not
ContainerBase.contentView.numElements.
I fixed that, but I was wondering if ContainerBase.$numElements should be
fixed as well. I'm not sure exactly what the $ methods do in
ContainerBase.
Are they meant to insure the contentview is not used as a delegate?
$numElements looks ok to me. The $ functions are used by ContainerViews
to add elements to the "chrome" of the container itself, since addElement
otherwise adds it to the contentView. Scrollbars, TitleBars and stuff
like that get added by the ContainerViews outside of the contentView.
Thanks for fixing the bug.
-Alex
Re: Will we have a new release out the door till 8th of September?
On 8/18/16, 4:40 AM, "Christofer Dutz" wrote: >Hi, > > >as I mentioned a few days ago, I will be having a talk on FlexJS in >Hamburg on 08.09.2016 (http://programmplaner.solutions.hamburg/#/). > > >I hope we will be able to ship a new version with the Maven support till >then? Do you think that's possible? What are we missing? > > >I would suggest that I stage a Maven release and you do an Ant release >based on the Maven Release Tag. Maven does two commits during a release: >1. change the version number to the release version, 2. Change the >version to the next development version. It tags the commit number 1 >automatically. So if you would do an Ant release from that state, the >version number should be consistent. The only thing we would need to do >is merge both ends back together, but that shouldn't be an issue as the >files touched during an Ant release should be different than those of a >Maven release. > > >The only thing I would need to do before that, would be to prepare 1.0.0 >releases of the build-helper-maven plugin and the little jburg-types jar. >I could initiate this any time. I asked this in a different thread, but where is the source package for the official vote? From the Ant or Maven builds? I have not checked the Maven builds. If the plan is to use the Ant builds for the source package, then your plan sounds fine to me. AFAIK, I am just waiting on one more check-in from Peter on the examples. It would be great to get Justin's thumbs up before starting the vote, or we can just gamble that we've addressed all of his earlier issues. Thoughts? -Alex
AW: Will we have a new release out the door till 8th of September?
Hi Alex, the source package we should vote on will be the Ant one. That's the reason for me preparing a Maven release before the Ant. This way you can checkout the Released version (with release versions in the poms). Perhaps it would be a good idea to start with release branches this time. Chris Von: Alex Harui Gesendet: Donnerstag, 18. August 2016 16:56:46 An: dev@flex.apache.org Betreff: Re: Will we have a new release out the door till 8th of September? On 8/18/16, 4:40 AM, "Christofer Dutz" wrote: >Hi, > > >as I mentioned a few days ago, I will be having a talk on FlexJS in >Hamburg on 08.09.2016 (http://programmplaner.solutions.hamburg/#/). > > >I hope we will be able to ship a new version with the Maven support till >then? Do you think that's possible? What are we missing? > > >I would suggest that I stage a Maven release and you do an Ant release >based on the Maven Release Tag. Maven does two commits during a release: >1. change the version number to the release version, 2. Change the >version to the next development version. It tags the commit number 1 >automatically. So if you would do an Ant release from that state, the >version number should be consistent. The only thing we would need to do >is merge both ends back together, but that shouldn't be an issue as the >files touched during an Ant release should be different than those of a >Maven release. > > >The only thing I would need to do before that, would be to prepare 1.0.0 >releases of the build-helper-maven plugin and the little jburg-types jar. >I could initiate this any time. I asked this in a different thread, but where is the source package for the official vote? From the Ant or Maven builds? I have not checked the Maven builds. If the plan is to use the Ant builds for the source package, then your plan sounds fine to me. AFAIK, I am just waiting on one more check-in from Peter on the examples. It would be great to get Justin's thumbs up before starting the vote, or we can just gamble that we've addressed all of his earlier issues. Thoughts? -Alex
Re: Will we have a new release out the door till 8th of September?
+1. I think now would be a good time to cut a release branch. On Aug 18, 2016, at 6:40 PM, Christofer Dutz wrote: > Perhaps it would be a good idea to start with release branches this time.
Re: [FlexJS] ElementWrapper.forwarder() Changes Target
I think I'm leaning more toward agreeing with you, Harbs, about a Flex event bus. I remember changing MouseEvent because of some issue (have to look at the logs) with it being a subclass of Event. If we make it a rule that every FlexJS component only work with org.apache.flex.events.Event (or a subclass), and have a set of interactive event (mouse, touch, keyboard) classes (which derive from our own Event class), something deep down should be able to translate platform events to our events and put them onto our bus. It is a shame not to take advantage of the platform's own dispatching system, but when trying to put things together from different systems, sometimes you need to go outside the box. For example: where the event will be org.apache.flex.events.InteractiveEvent. I picked this so that on a mobile device, you might get a TouchEvent and a desktop would deliver a MouseEvent. If the handleEvent code needed to know Touch vs Mouse, it could just query the event's data type. Underneath, Button might be assigned TextButtonMouseController and, in its Flash platform-specific code, would listen for flash.events.MouseEvent. Upon receiving it, use MouseUtils to convert the event into our MouseEvent and then dispatch it onto our bus. Each interactive type of control component would have a set of device-type controllers (TextButtonMouseController, TextButtonTouchController, etc) and their job is to interface between the platform and FlexJS events. App developers would be told to write their code to accept InteractiveEvents in their button handlers which would contain basic information (localX, localY, etc) that were common to all of the touch & mouse events. More details might be in the subclass (eg, which mouse button was used found when casting the event to a MouseEvent). Might be a lot of work, I don't know. This might also be fraught will all kinds of side-effects which are not occurring to me right now. ‹peter On 8/18/16, 7:45 AM, "Harbs" wrote: >IMO, the ³right² way to fix this is by dispatching events from the >flexjs_wrapper and implement event bubbling up the FlexJS element chain. > >Yishay did not mention them, but we were having a whole slew of problems >related to events: > > >1. Event targets being lost (which he mentioned here) >2. Fixing that seems to mess up bubbling. (again) >3. clone() and cloneEvent() is a bit weird. You cannot dispatch >cloneEvent() directly without casting it first (because it¹s the Flash >EventDispatcher which does the dispatching) and you cannot override >clone() using a Flex event because it¹s an incompatible override. >4. BrowserEvents vs. MouseEvent We were actually kind of confused by >MouseEvent, because in the Browser, only BrowserEvents seem to be used. >What¹s the point of MouseEvents? >5. EventDispatcher took a Flash event even though we really need a Flex >event. See # 3. >6. EventDispatcher cannot take an IFlexEvent. This kind of defeats the >point of have an IFlexEvent in the first place. >7. BrowserEvent was missing localX and localY (maybe fixed) >8. I really think that MouseEvent should probably subclass event, but it >can¹t because it subclasses Flash MouseEvent. It it wrapped the events, >this problem would be solved. > >To me, all this points to the fact that we should have a Flex event bus >which would be completely cross-platform and wrap browser and Flash >events. > > > >On Aug 18, 2016, at 10:05 AM, Alex Harui wrote: > >> >> >> On 8/17/16, 11:25 PM, "yishayw" wrote: >> >>> If I listen on a click event on the application I expect to get all >>>click >>> events bubbled up from contained elements. That works, however the >>>target >>> is >>> the application rather than the element that was clicked on. This is >>>due >>> to >>> ElementWrapper.forwarder() re-dispatching the event, where the >>> ElementWrapper is the application. Is this by design? >> >> Well yes, for events dispatched from the wrapped element, but you are >> correct that it won't work for bubbled events. There is no way to set >>the >> target of an event in Flash. We might have to build our own queue of >> listeners and call them directly, but even then, the target will be a >> wrapped element and not its wrapper. >> >> This might be an issue that kills the plan of wrapping Flash >> DisplayObjects. We'll see if someone comes up with a "easy" way of >> getting it to work. I'll ponder it while I'm sleeping. >> >> -Alex >> >
Re: [FlexJS] ElementWrapper.forwarder() Changes Target
On 8/18/16, 10:42 AM, "Peter Ent" wrote: >I think I'm leaning more toward agreeing with you, Harbs, about a Flex >event bus. I remember changing MouseEvent because of some issue (have to >look at the logs) with it being a subclass of Event. If we make it a rule >that every FlexJS component only work with org.apache.flex.events.Event >(or a subclass), and have a set of interactive event (mouse, touch, >keyboard) classes (which derive from our own Event class), something deep >down should be able to translate platform events to our events and put >them onto our bus. It is a shame not to take advantage of the platform's >own dispatching system, but when trying to put things together from >different systems, sometimes you need to go outside the box. Duplicating the event system is definitely a possibility, but I would like to explore other solutions first. Stepping back, IIRC, the reason we tried wrapping Sprite was to deal with code-hinting in the IDEs and issues with property and method names with low-level Flash APIs. It occurred to me that the wrapping solution might be attacking this problem incorrectly: it is adding runtime overhead for an author-time problem. That isn't PAYG. Further adding a duplicate event system will only add more runtime overhead. The Google event system we use on the JS side added 6K to every download. Not sure how big a Flash version will be, but it will double the number of event listener arrays and worse, the duplicates will be in ActionScript instead of C code. And when you add overhead, you invite others to undercut you with lower-overhead alternatives and fracture the community. In addition, IMO, it was a goal to try to abstract away the internal implementations of the components. I'm concerned that we will get used to wrapping everything. The CreateJS code and another Canvas framework that doesn't have to wrap HTMLElements shouldn't have to wrap elements. Same will be true for any Flash 3D/Starling/Feathers sort of thing for the SWF. So maybe the answer is to upgrade the tools to solve the original set of problems. Then the runtime is as efficient as it can be for each platform. The separate problem of event classes and their inheritance is, IMO a separate problem and the solution is dependent on whether we keep wrapping DisplayObjects in the SWF implementation. I will say, though, that it is important to remember that we want the lowest overhead on the JS side, so having some additional overhead on the SWF side is ok, but double the number of objects may be too much. Further, 100% compatibility with Flex is not a requirement. So, some old Flex coding patterns and expectation may have to change, including whether you have to get the type of your events correct because MouseEvent doesn't subclass Event. That might still be better fixed with better tooling and debugging. I can imagine some hybrid apps where the app uses more than one library which are dispatching different kinds of events. I am going to go dig up the original thread and respond there with a discussion on alternative solutions. My 2 cents, -Alex
Re: [FlexJS] HTMLElementWrapper extending Sprite
On 7/27/16, 1:14 AM, "Harbs" wrote: >I’m running into lots of issues with the fact that HTMLElementWrapper >extends Sprite. The underlying problem is because all the native Flash >properties and methods are being exposed to the compiler for all >sub-classed objects. > >For my port this is causing two issues: > >1. It’s hard to find all the dependancies on Flash. Ideally, I’d like to >base my components off FlexJS ones instead of Spark and native Flash ones >and have the compiler find the pieces I’m missing. This is not working >because a lot of pieces appear to the compiler as fine because Sprite is >the base class. > >2. I’m getting lots of conflicts with property and method names. This is >mostly happening with components which were based off of Spark, but I’m >getting lots of compiler errors where pieces are not marked as overrides. >They should not have to be marked as overrides because FlexJS does not >implement them, but Flash does. > >The third issue is related to code completion help. The user should not >get hints for Flash properties and methods because they will not work in >HTML. So we've tried wrapping Sprite instead of extending it and ran into other issues in that implementation. As I mentioned in another thread, wrapping Sprite doubles the number of objects and therefore adds runtime overhead to solve what are essentially author-time problems. So in this fork of this thread, I want to explore alternative solutions. 1. For this problem, I think you could compile your app against the "JS" SWCs. As a reminder, each SWC in FlexJS is actually two SWCs: one containing SWF code, and one containing JS-only APIs to be consumed by downstream SWCs. I think the "JS" SWCs do not have any Flash dependencies. The "JS" SWCs do have some non-SWF public APIs used for communicating internally, but it is probably important for you to know that before the cross-compile anyway. If you can get a clean compile (it won't run as a SWF for sure), then I think you can then switch back to the regular SWCs and get a runnable SWF. 2. I think the parser builds the AST without caring about overrides and override detection is done as the AST is being read. It might be possible for Falcon to auto generate the override if the base definition is a Flash definition. 3. Similar to 1, maybe the SDK should be set up with the JS SWCs by default and the SWF compiler could auto-swap in the SWCs for Flash when actually linking in code into the SWF. Also, we could just use [Exclude] metadata to hide the Flash APIs although apparently, not every IDE supports [Exclude] metadata. Thoughts? -Alex
Re: [FlexJS] ElementWrapper.forwarder() Changes Target
Just to play devil's advocate for moment, ReactJS duplicates the DOM for its own purposes and seems to do quite well. I know it has code in it to do optimization for what to redraw, making it more complex than just a duplicate tree structure. That said, reducing our overhead is a worthy goal and if it can be done without duplication that would be great. I guess a duplicate event system that really brings nothing else to the table would not be worth it if there were alternatives. ‹peter On 8/18/16, 2:38 PM, "Alex Harui" wrote: > > >On 8/18/16, 10:42 AM, "Peter Ent" wrote: > >>I think I'm leaning more toward agreeing with you, Harbs, about a Flex >>event bus. I remember changing MouseEvent because of some issue (have to >>look at the logs) with it being a subclass of Event. If we make it a rule >>that every FlexJS component only work with org.apache.flex.events.Event >>(or a subclass), and have a set of interactive event (mouse, touch, >>keyboard) classes (which derive from our own Event class), something deep >>down should be able to translate platform events to our events and put >>them onto our bus. It is a shame not to take advantage of the platform's >>own dispatching system, but when trying to put things together from >>different systems, sometimes you need to go outside the box. > >Duplicating the event system is definitely a possibility, but I would like >to explore other solutions first. > >Stepping back, IIRC, the reason we tried wrapping Sprite was to deal with >code-hinting in the IDEs and issues with property and method names with >low-level Flash APIs. It occurred to me that the wrapping solution might >be attacking this problem incorrectly: it is adding runtime overhead for >an author-time problem. That isn't PAYG. Further adding a duplicate >event system will only add more runtime overhead. The Google event system >we use on the JS side added 6K to every download. Not sure how big a >Flash version will be, but it will double the number of event listener >arrays and worse, the duplicates will be in ActionScript instead of C >code. And when you add overhead, you invite others to undercut you with >lower-overhead alternatives and fracture the community. > >In addition, IMO, it was a goal to try to abstract away the internal >implementations of the components. I'm concerned that we will get used to >wrapping everything. The CreateJS code and another Canvas framework that >doesn't have to wrap HTMLElements shouldn't have to wrap elements. Same >will be true for any Flash 3D/Starling/Feathers sort of thing for the SWF. > >So maybe the answer is to upgrade the tools to solve the original set of >problems. Then the runtime is as efficient as it can be for each >platform. > >The separate problem of event classes and their inheritance is, IMO a >separate problem and the solution is dependent on whether we keep wrapping >DisplayObjects in the SWF implementation. I will say, though, that it is >important to remember that we want the lowest overhead on the JS side, so >having some additional overhead on the SWF side is ok, but double the >number of objects may be too much. Further, 100% compatibility with Flex >is not a requirement. So, some old Flex coding patterns and expectation >may have to change, including whether you have to get the type of your >events correct because MouseEvent doesn't subclass Event. That might still >be better fixed with better tooling and debugging. I can imagine some >hybrid apps where the app uses more than one library which are dispatching >different kinds of events. > >I am going to go dig up the original thread and respond there with a >discussion on alternative solutions. > >My 2 cents, >-Alex >
Re: [FlexJS] ElementWrapper.forwarder() Changes Target
> Stepping back, IIRC, the reason we tried wrapping Sprite was to deal with > code-hinting in the IDEs and issues with property and method names with > low-level Flash APIs. A bigger issue was related to defining properties and methods which collided with Flash ones. That’s not just a tooling issue. It’s not possible to define the properties and methods without overrides, and overrides generally do not work because they are incompatible. I don’t think wrapping things on the Flash side adds an unacceptible amount of overhead. It’s not worse that classic Flex components (probably a lot better) in that regard. On Aug 18, 2016, at 9:38 PM, Alex Harui wrote: > > > On 8/18/16, 10:42 AM, "Peter Ent" wrote: > >> I think I'm leaning more toward agreeing with you, Harbs, about a Flex >> event bus. I remember changing MouseEvent because of some issue (have to >> look at the logs) with it being a subclass of Event. If we make it a rule >> that every FlexJS component only work with org.apache.flex.events.Event >> (or a subclass), and have a set of interactive event (mouse, touch, >> keyboard) classes (which derive from our own Event class), something deep >> down should be able to translate platform events to our events and put >> them onto our bus. It is a shame not to take advantage of the platform's >> own dispatching system, but when trying to put things together from >> different systems, sometimes you need to go outside the box. > > Duplicating the event system is definitely a possibility, but I would like > to explore other solutions first. > > Stepping back, IIRC, the reason we tried wrapping Sprite was to deal with > code-hinting in the IDEs and issues with property and method names with > low-level Flash APIs. It occurred to me that the wrapping solution might > be attacking this problem incorrectly: it is adding runtime overhead for > an author-time problem. That isn't PAYG. Further adding a duplicate > event system will only add more runtime overhead. The Google event system > we use on the JS side added 6K to every download. Not sure how big a > Flash version will be, but it will double the number of event listener > arrays and worse, the duplicates will be in ActionScript instead of C > code. And when you add overhead, you invite others to undercut you with > lower-overhead alternatives and fracture the community. > > In addition, IMO, it was a goal to try to abstract away the internal > implementations of the components. I'm concerned that we will get used to > wrapping everything. The CreateJS code and another Canvas framework that > doesn't have to wrap HTMLElements shouldn't have to wrap elements. Same > will be true for any Flash 3D/Starling/Feathers sort of thing for the SWF. > > So maybe the answer is to upgrade the tools to solve the original set of > problems. Then the runtime is as efficient as it can be for each platform. > > The separate problem of event classes and their inheritance is, IMO a > separate problem and the solution is dependent on whether we keep wrapping > DisplayObjects in the SWF implementation. I will say, though, that it is > important to remember that we want the lowest overhead on the JS side, so > having some additional overhead on the SWF side is ok, but double the > number of objects may be too much. Further, 100% compatibility with Flex > is not a requirement. So, some old Flex coding patterns and expectation > may have to change, including whether you have to get the type of your > events correct because MouseEvent doesn't subclass Event. That might still > be better fixed with better tooling and debugging. I can imagine some > hybrid apps where the app uses more than one library which are dispatching > different kinds of events. > > I am going to go dig up the original thread and respond there with a > discussion on alternative solutions. > > My 2 cents, > -Alex >
Re: [FlexJS] HTMLElementWrapper extending Sprite
Like I mentioned in the other thread, it’s NOT just an author-time problem. Conflicts in variables and methods will cause Flash runtime errors and override can often not be done properly. The only runtime workaround I can see for that would be to automatically rename the methods and properties, but that seem like a poor solution to me. On Aug 18, 2016, at 9:53 PM, Alex Harui wrote: > > > On 7/27/16, 1:14 AM, "Harbs" wrote: > >> I’m running into lots of issues with the fact that HTMLElementWrapper >> extends Sprite. The underlying problem is because all the native Flash >> properties and methods are being exposed to the compiler for all >> sub-classed objects. >> >> For my port this is causing two issues: >> >> 1. It’s hard to find all the dependancies on Flash. Ideally, I’d like to >> base my components off FlexJS ones instead of Spark and native Flash ones >> and have the compiler find the pieces I’m missing. This is not working >> because a lot of pieces appear to the compiler as fine because Sprite is >> the base class. >> >> 2. I’m getting lots of conflicts with property and method names. This is >> mostly happening with components which were based off of Spark, but I’m >> getting lots of compiler errors where pieces are not marked as overrides. >> They should not have to be marked as overrides because FlexJS does not >> implement them, but Flash does. >> >> The third issue is related to code completion help. The user should not >> get hints for Flash properties and methods because they will not work in >> HTML. > > So we've tried wrapping Sprite instead of extending it and ran into other > issues in that implementation. As I mentioned in another thread, wrapping > Sprite doubles the number of objects and therefore adds runtime overhead > to solve what are essentially author-time problems. So in this fork of > this thread, I want to explore alternative solutions. > > 1. For this problem, I think you could compile your app against the "JS" > SWCs. As a reminder, each SWC in FlexJS is actually two SWCs: one > containing SWF code, and one containing JS-only APIs to be consumed by > downstream SWCs. I think the "JS" SWCs do not have any Flash > dependencies. The "JS" SWCs do have some non-SWF public APIs used for > communicating internally, but it is probably important for you to know > that before the cross-compile anyway. If you can get a clean compile (it > won't run as a SWF for sure), then I think you can then switch back to the > regular SWCs and get a runnable SWF. > > 2. I think the parser builds the AST without caring about overrides and > override detection is done as the AST is being read. It might be possible > for Falcon to auto generate the override if the base definition is a Flash > definition. > > 3. Similar to 1, maybe the SDK should be set up with the JS SWCs by > default and the SWF compiler could auto-swap in the SWCs for Flash when > actually linking in code into the SWF. Also, we could just use [Exclude] > metadata to hide the Flash APIs although apparently, not every IDE > supports [Exclude] metadata. > > Thoughts? > -Alex
Re: [FlexJS] ElementWrapper.forwarder() Changes Target
On 8/18/16, 1:34 PM, "Peter Ent" wrote: >Just to play devil's advocate for moment, ReactJS duplicates the DOM for >its own purposes and seems to do quite well. I know it has code in it to >do optimization for what to redraw, making it more complex than just a >duplicate tree structure. What do they get out of duplicating the DOM? > >That said, reducing our overhead is a worthy goal and if it can be done >without duplication that would be great. I guess a duplicate event system >that really brings nothing else to the table would not be worth it if >there were alternatives. Regarding events, at some point more research needs to be done. Maybe for our purposes we can override event.target. But I still think this answer requires us to first settle on whether we are wrapping DisplayObjects or not. Duplicating Events in FlexJS would bring the API closer to what it was in Flex, but there might be other ways, like a different property name for target and generating different code to access it. We should also revisit and properly document the reason why MouseEvent is not inheriting from Event. Maybe there is another solution there as well, which would totally change the set of possible solutions. -Alex
Re: [FlexJS] ElementWrapper.forwarder() Changes Target
React works by using a Shadow DOM and diffing the DOM to figure out if things need to change. Angular works by running constant checks on the DOM and updating stuff as needed. I think simply wrapping DOM elements by JS ones has WAY less overhead than both of these approaches. Re. Events: I think MouseEvent does not inherit from Event because it inherits from Flash MouseEvent (being events are being subclassed rather than wrapped). The fact that MouseEvent on the JS side seems to be BrowserEvent instead, is just weird. We spent a very long time today on the fact that Mouse coordinates on transformed SVG elements were not working correctly. We have a partial solution to that, but fixing it “correctly” is a whole other topic. On Aug 19, 2016, at 12:30 AM, Alex Harui wrote: > > > On 8/18/16, 1:34 PM, "Peter Ent" wrote: > >> Just to play devil's advocate for moment, ReactJS duplicates the DOM for >> its own purposes and seems to do quite well. I know it has code in it to >> do optimization for what to redraw, making it more complex than just a >> duplicate tree structure. > > What do they get out of duplicating the DOM? > >> >> That said, reducing our overhead is a worthy goal and if it can be done >> without duplication that would be great. I guess a duplicate event system >> that really brings nothing else to the table would not be worth it if >> there were alternatives. > > Regarding events, at some point more research needs to be done. Maybe for > our purposes we can override event.target. But I still think this answer > requires us to first settle on whether we are wrapping DisplayObjects or > not. Duplicating Events in FlexJS would bring the API closer to what it > was in Flex, but there might be other ways, like a different property name > for target and generating different code to access it. > > We should also revisit and properly document the reason why MouseEvent is > not inheriting from Event. Maybe there is another solution there as well, > which would totally change the set of possible solutions. > > -Alex >
Re: [FlexJS] HTMLElementWrapper extending Sprite
On 8/18/16, 2:15 PM, "Harbs" wrote: >Like I mentioned in the other thread, it’s NOT just an author-time >problem. > >Conflicts in variables and methods will cause Flash runtime errors and >override can often not be done properly. Are you saying the override would have an incompatible signature with the Flash API? What are some examples that you ran into? Especially ones where if the compiler warned you and recommended that you pick a new name that it would seriously harm usability. > >The only runtime workaround I can see for that would be to automatically >rename the methods and properties, but that seem like a poor solution to >me. What are your reasons that be a poor solution? Other than obj["propertyName"] being hard to detect and re-write. Thanks, -Alex
Re: [FlexJS] ElementWrapper.forwarder() Changes Target
On 8/18/16, 2:37 PM, "Harbs" wrote: >React works by using a Shadow DOM and diffing the DOM to figure out if >things need to change. > >Angular works by running constant checks on the DOM and updating stuff as >needed. > >I think simply wrapping DOM elements by JS ones has WAY less overhead >than both of these approaches. > Agreed. But that is not, IMO, a clear reason to wrap the Sprite DisplayObjects. > >Re. Events: > >I think MouseEvent does not inherit from Event because it inherits from >Flash MouseEvent (being events are being subclassed rather than wrapped). IIRC, there is more to it than that, otherwise the FlexJS MouseEvent would still inherit from flash.event.Event. >The fact that MouseEvent on the JS side seems to be BrowserEvent instead, >is just weird. We spent a very long time today on the fact that Mouse >coordinates on transformed SVG elements were not working correctly. We >have a partial solution to that, but fixing it “correctly” is a whole >other topic. When we get to discussing events, one proposal is to not use Google Closure's events. -Alex
Re: [FlexJS] HTMLElementWrapper extending Sprite
On Aug 19, 2016, at 12:49 AM, Alex Harui wrote: > > > On 8/18/16, 2:15 PM, "Harbs" wrote: > >> Like I mentioned in the other thread, it’s NOT just an author-time >> problem. >> >> Conflicts in variables and methods will cause Flash runtime errors and >> override can often not be done properly. > > Are you saying the override would have an incompatible signature with the > Flash API? What are some examples that you ran into? Especially ones > where if the compiler warned you and recommended that you pick a new name > that it would seriously harm usability. I don’t remember off-hand which ones I ran into, but it definitely was an issue. I can try to go through the code commits and see if I can find examples. We can’t hide the Flash APIs and then require the client specifies compatible overrides. That defeats the whole point of hiding the APIs. >> >> The only runtime workaround I can see for that would be to automatically >> rename the methods and properties, but that seem like a poor solution to >> me. > > What are your reasons that be a poor solution? Other than > obj["propertyName"] being hard to detect and re-write. Confusion while debugging comes to mind. > Thanks, > -Alex >
Re: [FlexJS] HTMLElementWrapper extending Sprite
On 8/18/16, 3:40 PM, "Harbs" wrote: > >On Aug 19, 2016, at 12:49 AM, Alex Harui wrote: > >> >> >> On 8/18/16, 2:15 PM, "Harbs" wrote: >> >>> Like I mentioned in the other thread, it’s NOT just an author-time >>> problem. >>> >>> Conflicts in variables and methods will cause Flash runtime errors and >>> override can often not be done properly. >> >> Are you saying the override would have an incompatible signature with >>the >> Flash API? What are some examples that you ran into? Especially ones >> where if the compiler warned you and recommended that you pick a new >>name >> that it would seriously harm usability. > >I don’t remember off-hand which ones I ran into, but it definitely was an >issue. I can try to go through the code commits and see if I can find >examples. We can’t hide the Flash APIs and then require the client >specifies compatible overrides. That defeats the whole point of hiding >the APIs. It occurs to me that even on the JS side there is a risk that a property or method name you choose will already be taken by some internal aspect of the platform-specific implementation that we probably would filter from the "public" API. I think it would be too constraining declare a set of APIs by which all platform implementations must conform. Because there are more small separate pieces in the FlexJS implementation, there must be public APIs used to communicate between those pieces that most application developers will not need to know about. The best FlexJS IDEs will allow you to filter those out. And then you might still run into a conflict because the actual platform implementation chose a particular public name for something. I'm interested to see how often that is going to happen. In the longer term, I still hope to support simple forms of overloading by decorating names like C++ did on Windows, so renaming methods doesn't seem that terrible to me. My 2 cents, -Alex
