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: <js:TextButton text="Push Me" click="handleEvent(event)" /> 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" <[email protected]> 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 <[email protected]> wrote: > >> >> >> On 8/17/16, 11:25 PM, "yishayw" <[email protected]> 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 >> >
