I'm ok with moving that to UIBase. Hope you got enough sleep __ -Alex
On 5/15/20, 9:00 AM, "Josh Tynjala" <[email protected]> wrote: I hadn't looked closely at the code in EventDispatcher before I sent the last message, but I just discovered that EventDispatcher already has my proposed architecture. Here's the code we have today: override public function getParentEventTarget():goog.events.EventTarget { return (this as IChild).parent as EventDispatcher; } With this implementation we've made IChild a hard dependency of EventDispatcher, but I think that we could instead move that one method into UIBase (or somewhere else more appropriate, if UIBase isn't exactly right). -- Josh Tynjala Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev%2F&data=02%7C01%7Caharui%40adobe.com%7C0881a16c4b3c40ba2bee08d7f8e92106%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251552485713246&sdata=u3dA9t1cUbAFhEsK6oyqIjSy%2FpuBiqx1VCmBu2jhIBw%3D&reserved=0> On Fri, May 15, 2020 at 8:54 AM Josh Tynjala <[email protected]> wrote: > I woke up in the middle of the night with an idea that I think would be > much less disruptive than changing the available fields on IChild. > > Bubbling happens in subclasses of EventDispatcher. In SWF, bubbling > happens on DisplayObjects. In Royale, as I understand it, it's currently > available to subclasses of EventDispatcher that implement IChild. > > EventDispatcher doesn't necessarily need to know about IChild interface > specifically, though. In fact, it would be desirable if it didn't need to > know about IChild because (hypothetical) new component sets could extend > EventDispatcher without being forced into a specific interface's naming > convention. Instead, EventDispatcher would still provide the core bubbling > architecture, but it would delegate the accessing of the target's parent to > a method that could be overridden by the subclass. > > EventDispatcher would provide the basic case, which would work for objects > that don't have a parent to bubble to (like Timer or RoyaleUnitCore, for > instance) : > > protected function nextBubbleTarget(target:Object):EventDispatcher { > return null; } > > UIBase could provide this custom implementation of the method: > > override protected function > nextBubbleTarget(target:Object):EventDispatcher { > return target is IChild ? IChild(target).parent : null; > } > > A hypothetical new component set could do something like this (with its > hypothetical INode interface): > > override protected function > nextBubbleTarget(target:Object):EventDispatcher { > return target is INode ? INode(target).parentNode : null; > } > > -- > Josh Tynjala > Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev%2F&data=02%7C01%7Caharui%40adobe.com%7C0881a16c4b3c40ba2bee08d7f8e92106%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251552485713246&sdata=u3dA9t1cUbAFhEsK6oyqIjSy%2FpuBiqx1VCmBu2jhIBw%3D&reserved=0> > > > On Fri, May 15, 2020 at 1: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]> 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%7C0881a16c4b3c40ba2bee08d7f8e92106%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251552485713246&sdata=5hNt%2FvZfat9QZWx0uNDYdJeBu9xfVVVwDHLBp%2FbayjY%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%7C0881a16c4b3c40ba2bee08d7f8e92106%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251552485713246&sdata=u3dA9t1cUbAFhEsK6oyqIjSy%2FpuBiqx1VCmBu2jhIBw%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%7C0881a16c4b3c40ba2bee08d7f8e92106%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251552485713246&sdata=u3dA9t1cUbAFhEsK6oyqIjSy%2FpuBiqx1VCmBu2jhIBw%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%7C0881a16c4b3c40ba2bee08d7f8e92106%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251552485713246&sdata=u3dA9t1cUbAFhEsK6oyqIjSy%2FpuBiqx1VCmBu2jhIBw%3D&reserved=0 >> >>>> >> >>>> >> >>> >> >>> >> >>> -- >> >>> Carlos Rovira >> >>> >> >>> >> >> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0881a16c4b3c40ba2bee08d7f8e92106%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637251552485723243&sdata=u1PK8y5u0h8hkEbkdVxF2B8vDyVnLbM%2BuVybDHARSzc%3D&reserved=0 >> >>> >> >>> >> >>> >> >> >> >> >> >> >> > >> > >> >> >> >>
