As I understand it, Royale's EventDispatcher uses an IChild interface that references an IParent interface. As long as those interfaces don't have any platform-specific properties or methods, EventDispatcher shouldn't need to know the "Node.js way" or the "DOMway" or the "SWF way" of doing things. Each platform would have one (or maybe more!) implementations of IChild/IParent, and EventDispatcher would only care about it this way:
if(event.bubbles && this instanceof IChild) I think that it basically works like this already, but IChild has other platform-specific APIs on it that EventDispatcher doesn't use. To answer your question directly, Node.js doesn't have a DOM or display list, so there isn't really a tree structure for bubbling. In theory, a Node.js library like this one could have custom IChild/IParent implementations that work with EventDispatcher: https://github.com/chjj/blessed -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Thu, May 14, 2020 at 12:58 PM Alex Harui <[email protected]> wrote: > I think the question for me is how EventDispatcher is defined in Node. > Does it support bubbling? Maybe it doesn't because there is no DOM? Is > there a "parent" API in Node? > > IMO, conditional compilation should be used as little as possible so we > only use it where APIs differ between platforms. Most Royale interfaces > should try to represent useful abstractions across platforms, a few > represent platform APIs. > > My 2 cents, > -Alex > > On 5/14/20, 12:05 PM, "Josh Tynjala" <[email protected]> wrote: > > Yeah, I don't mind if we find a way to have a single EventDispatcher > where > bubbling is supported, and it still works in Node.js. > > Currently, the IChild interface that is used to crawl up the list of > parents has a dependency on the HTMLElement type. The only part of > IChild > that matters to EventDispatcher should be the reference to its parent, > so > it's possible that this could be solved by moving some properties into > a > sub-interface of IChild. > > One thing that I thought might be interesting to consider is to > introduce > another compile-time constant, COMPILE::HTML. COMPILE:JS and > COMPILE::HTML > would both be true when compiling for the web. COMPILE::JS would be > true > and COMPILE::HTML would be false when compiling for Node.js. This would > allow us to keep the same IChild interface, but include the reference > to > "positioner" and other webby stuff only for the web. > > Either of those approaches would be acceptable to me. However, which is > better is probably better understood by those more familiar with the > framework side of Royale than I am. > > -- > Josh Tynjala > Bowler Hat LLC < > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev%2F&data=02%7C01%7Caharui%40adobe.com%7C906919aa5d894d911ad008d7f839bb8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250799170559368&sdata=Y773204cZgIq8bT%2FDOuNik0zFBfwcNIUtpOGkNtNzbU%3D&reserved=0 > > > > > On Thu, May 14, 2020 at 11:19 AM Alex Harui <[email protected]> > wrote: > > > I have not looked into this at all. FWIW, ED is spec'd to support > > bubbling and it should be possible for a RoyaleUnit test to rely on > > bubbling, so maybe the issue is that the support for bubbling has > > undesirable dependencies? > > > > On 5/14/20, 10:45 AM, "Carlos Rovira" <[email protected]> > wrote: > > > > Hi Josh, > > > > I was in the believe that the bubbling changes to ED was PAYG > and was > > done > > to be composed. I think that would be the best, if done in a way > where > > we > > can easily use with bubbling in the framework and without it in > > RoyaleUnit. > > If that's possible, I'd like that instead a ED duplicate class. > > > > Thanks > > > > El jue., 14 may. 2020 a las 0:24, Josh Tynjala (< > > [email protected]>) > > escribió: > > > > > FYI — It appears that Royale 0.9.7 breaks the ability for > > > org.apache.royale.events.EventDispatcher to be used in > Node.js. This > > means > > > that RoyaleUnit can no longer be used with Node.js, which was > one of > > my > > > original goals for RoyaleUnit. Unfortunately, while I tested > that > > one of my > > > Royale Node.js command line tools was working correctly with > the RC, > > I > > > guess that I forgot to run its RoyaleUnit tests too, so I > missed the > > > effects of this change until now. > > > > > > The change seems to be related to adding bubbling events to the > > > EventDispatcher class. EventDispatcher now depends on IChild, > which > > has > > > some properties of type WrappedHTMLElement. WrappedHTMLElement > > depends on > > > HTMLElement, which obviously isn't available in Node.js. > > > > > > Not sure about the best approach yet, but one possible > solution is to > > > create a new superclass of EventDispatcher. The superclass > would > > handle > > > events without bubbling. The subclass would add bubbling > support. As > > a > > > bonus, this would be more PAYG because it will allow projects > to > > exclude > > > the bubbling code if they don't need it. I don't know if I'll > get a > > chance > > > to implement this soon because I'm still knee-deep in compiler > > stuff, but > > > it's something that I'd eventually like to fix because my > Royale > > Node.js > > > projects will be stuck on 0.9.6 without it. > > > > > > -- > > > Josh Tynjala > > > Bowler Hat LLC < > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev%2F&data=02%7C01%7Caharui%40adobe.com%7C906919aa5d894d911ad008d7f839bb8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250799170559368&sdata=Y773204cZgIq8bT%2FDOuNik0zFBfwcNIUtpOGkNtNzbU%3D&reserved=0 > > > > > > > > > > > > -- > > Carlos Rovira > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C906919aa5d894d911ad008d7f839bb8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250799170559368&sdata=X7oCWJxjdlAHZDoOuORVKKpsPIeckntWY4p0y%2FotDtc%3D&reserved=0 > > > > > > > > >
