Good point about mixing. Adobe CEP actually supports a node context within the HTML one and I have Node code mixed into my HTML extensions.
> On May 15, 2020, at 11:00 AM, Alex Harui <[email protected]> wrote: > > 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] > <mailto:[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 >> >> <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 >> >> <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] >> <mailto:[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] >>> <mailto:[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 >>> >>> <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] >>> <mailto:[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] >>>> <mailto:[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] <mailto:[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 >>> >>> <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 >>> >>> <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>
