One of the risks with Conditional Compilation is mixing. We can tell folks that you can't mix JS output with SWF output and that will sort of make sense. I'm not sure about saying you can't mix Node code with, say, Basic. It's all JS in the end and maybe you want to generate some JS to ship up to the client or are using an embedded JS runtime that has UI extensions.
I'm not saying there isn't some scenario where we'd conditionally compile Node code, but in this case, I'm leaning towards refactoring IChild. It'll be pretty disruptive: the parent/child pair was intended to be rather heavy and support what every display object in the DOM would have to have. I can't think of a non-disruptive change. Whatever code was relying on IParent having addElement will have to change. Maybe we create IUIParent to contain addElement and friends, and IUIChild to contain positioner. I'm stopping work for tonight so will see what others think tomorrow. -Alex On 5/15/20, 12:33 AM, "Harbs" <[email protected]> wrote: 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%7C285c03ed0fef4f98e66208d7f8a2345a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251247892933645&sdata=fS5bal9v2oCPgpbTNaBL2XH45m%2BLyV8mF6FnlRE45yY%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%7C285c03ed0fef4f98e66208d7f8a2345a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251247892933645&sdata=iQiqoGq8QNxTQ6pWS9THi5XVpzGt%2FrYYAulJXPV3PtE%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%7C285c03ed0fef4f98e66208d7f8a2345a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251247892933645&sdata=iQiqoGq8QNxTQ6pWS9THi5XVpzGt%2FrYYAulJXPV3PtE%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%7C285c03ed0fef4f98e66208d7f8a2345a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251247892933645&sdata=iQiqoGq8QNxTQ6pWS9THi5XVpzGt%2FrYYAulJXPV3PtE%3D&reserved=0 >>>> >>>> >>> >>> >>> -- >>> Carlos Rovira >>> >>> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C285c03ed0fef4f98e66208d7f8a2345a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251247892938636&sdata=Fr3cMeeqhOnrRr30U%2B%2FOxV%2FrzRVhyBiQfs30Hd3NBTc%3D&reserved=0 >>> >>> >>> >> >> >> > >
