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://bowlerhat.dev>
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://bowlerhat.dev>
>
>
> 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%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
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>>
