IChild also extends IRenderedObject which has element which is a WrappedHTMLElement
I’ve been thinking for a while that we should have COMPILE::NODE blocks as well as COMPILE::JS and COMPILE::SWF > On May 15, 2020, at 8:07 AM, Alex Harui <[email protected]> wrote: > > OK, I took a few minutes to look at the code. If you remove positioner from > IChild, what breaks? What code is counting on it? > > -Alex > > On 5/14/20, 1:27 PM, "Josh Tynjala" <[email protected]> wrote: > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchjj%2Fblessed&data=02%7C01%7Caharui%40adobe.com%7Cdc89f135ca864fc53bd608d7f8453ed2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250848602050555&sdata=WAuXeUVqEl0DmbGA%2Be8ePHZgCRpR82VSmHMeK1IBEt4%3D&reserved=0 > > -- > Josh Tynjala > Bowler Hat LLC > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev%2F&data=02%7C01%7Caharui%40adobe.com%7Cdc89f135ca864fc53bd608d7f8453ed2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250848602050555&sdata=OXXbDRlK2YWH%2BtP7VpnaMnNhVmyjjCC7CbNXB6FwIoQ%3D&reserved=0> > > > 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%7Cdc89f135ca864fc53bd608d7f8453ed2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250848602050555&sdata=OXXbDRlK2YWH%2BtP7VpnaMnNhVmyjjCC7CbNXB6FwIoQ%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%7Cdc89f135ca864fc53bd608d7f8453ed2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250848602050555&sdata=OXXbDRlK2YWH%2BtP7VpnaMnNhVmyjjCC7CbNXB6FwIoQ%3D&reserved=0 >>>> >>>> >>> >>> >>> -- >>> Carlos Rovira >>> >>> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cdc89f135ca864fc53bd608d7f8453ed2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250848602050555&sdata=zpjL1eDRKkkVJ8BC3MB8zpkCFCJ%2BpbUryj3reAYWJj8%3D&reserved=0 >>> >>> >>> >> >> >> > >
