You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Josh Tynjala <jo...@bowlerhat.dev> on 2020/05/13 22:24:39 UTC
RoyaleUnit, EventDispatcher, and Node.js
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://bowlerhat.dev>
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> 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" <harbs.lists@gmail.com <ma...@gmail.com>> 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 <ah...@adobe.com.INVALID> 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" <jo...@bowlerhat.dev> 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 <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>> 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" <joshtynjala@bowlerhat.dev <ma...@bowlerhat.dev>> 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 <aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>>> 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" <carlosrovira@apache.org <ma...@apache.org>>
>>> 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 (<
>>>> joshtynjala@bowlerhat.dev <ma...@bowlerhat.dev>>)
>>>> 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>
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm ok with moving that to UIBase. Hope you got enough sleep __
-Alex
On 5/15/20, 9:00 AM, "Josh Tynjala" <jo...@bowlerhat.dev> 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 <jo...@bowlerhat.dev>
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 <ah...@adobe.com.invalid>
> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>> 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" <jo...@bowlerhat.dev>
>> 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
>> <ah...@adobe.com.invalid>
>> > 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" <jo...@bowlerhat.dev>
>> 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
>> <ah...@adobe.com.invalid>
>> >> 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" <ca...@apache.org>
>> >> 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 (<
>> >>> joshtynjala@bowlerhat.dev>)
>> >>> 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
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>>
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
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 <jo...@bowlerhat.dev>
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 <ah...@adobe.com.invalid>
> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>> 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" <jo...@bowlerhat.dev>
>> 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
>> <ah...@adobe.com.invalid>
>> > 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" <jo...@bowlerhat.dev>
>> 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
>> <ah...@adobe.com.invalid>
>> >> 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" <ca...@apache.org>
>> >> 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 (<
>> >>> joshtynjala@bowlerhat.dev>)
>> >>> 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
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>>
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
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 <ah...@adobe.com.invalid> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
> 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" <jo...@bowlerhat.dev>
> 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
> <ah...@adobe.com.invalid>
> > 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" <jo...@bowlerhat.dev>
> 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
> <ah...@adobe.com.invalid>
> >> 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" <ca...@apache.org>
> >> 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 (<
> >>> joshtynjala@bowlerhat.dev>)
> >>> 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
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
>
>
>
>
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <jo...@bowlerhat.dev> 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 <ah...@adobe.com.invalid>
> 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" <jo...@bowlerhat.dev> 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 <ah...@adobe.com.invalid>
>> 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" <ca...@apache.org>
>> 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 (<
>>> joshtynjala@bowlerhat.dev>)
>>> 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
>>>
>>>
>>>
>>
>>
>>
>
>
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> 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" <jo...@bowlerhat.dev> 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 <ah...@adobe.com.invalid>
> 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" <jo...@bowlerhat.dev> 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 <ah...@adobe.com.invalid>
>> 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" <ca...@apache.org>
>> 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 (<
>>> joshtynjala@bowlerhat.dev>)
>>> 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
>>>
>>>
>>>
>>
>>
>>
>
>
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <jo...@bowlerhat.dev> 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 <ah...@adobe.com.invalid>
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" <jo...@bowlerhat.dev> 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 <ah...@adobe.com.invalid>
> 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" <ca...@apache.org>
> 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 (<
> > joshtynjala@bowlerhat.dev>)
> > 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
> >
> >
> >
>
>
>
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
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://github.com/chjj/blessed
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Thu, May 14, 2020 at 12:58 PM Alex Harui <ah...@adobe.com.invalid>
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" <jo...@bowlerhat.dev> 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%7C906919aa5d894d911ad008d7f839bb8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250799170559368&sdata=Y773204cZgIq8bT%2FDOuNik0zFBfwcNIUtpOGkNtNzbU%3D&reserved=0
> >
>
>
> On Thu, May 14, 2020 at 11:19 AM Alex Harui <ah...@adobe.com.invalid>
> 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" <ca...@apache.org>
> 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 (<
> > joshtynjala@bowlerhat.dev>)
> > 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%7C906919aa5d894d911ad008d7f839bb8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250799170559368&sdata=Y773204cZgIq8bT%2FDOuNik0zFBfwcNIUtpOGkNtNzbU%3D&reserved=0
> > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C906919aa5d894d911ad008d7f839bb8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250799170559368&sdata=X7oCWJxjdlAHZDoOuORVKKpsPIeckntWY4p0y%2FotDtc%3D&reserved=0
> >
> >
> >
>
>
>
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <jo...@bowlerhat.dev> 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%7C906919aa5d894d911ad008d7f839bb8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250799170559368&sdata=Y773204cZgIq8bT%2FDOuNik0zFBfwcNIUtpOGkNtNzbU%3D&reserved=0>
On Thu, May 14, 2020 at 11:19 AM Alex Harui <ah...@adobe.com.invalid>
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" <ca...@apache.org> 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 (<
> joshtynjala@bowlerhat.dev>)
> 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%7C906919aa5d894d911ad008d7f839bb8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250799170559368&sdata=Y773204cZgIq8bT%2FDOuNik0zFBfwcNIUtpOGkNtNzbU%3D&reserved=0
> >
> >
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C906919aa5d894d911ad008d7f839bb8c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250799170559368&sdata=X7oCWJxjdlAHZDoOuORVKKpsPIeckntWY4p0y%2FotDtc%3D&reserved=0
>
>
>
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
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://bowlerhat.dev>
On Thu, May 14, 2020 at 11:19 AM Alex Harui <ah...@adobe.com.invalid>
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" <ca...@apache.org> 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 (<
> joshtynjala@bowlerhat.dev>)
> 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%7C9a34b8b369e346d319c608d7f82e97ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250751309179283&sdata=AOLMoT%2FnhQm%2B1IF8rVM0%2FrD6AvEWv4Bev7svEE9nkF4%3D&reserved=0
> >
> >
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9a34b8b369e346d319c608d7f82e97ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250751309179283&sdata=64OYco9N8cd%2F7u5BvWZt2RzlDiZVMvAa2F0c14%2FuBHY%3D&reserved=0
>
>
>
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ca...@apache.org> 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 (<jo...@bowlerhat.dev>)
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%7C9a34b8b369e346d319c608d7f82e97ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250751309179283&sdata=AOLMoT%2FnhQm%2B1IF8rVM0%2FrD6AvEWv4Bev7svEE9nkF4%3D&reserved=0>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C9a34b8b369e346d319c608d7f82e97ed%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637250751309179283&sdata=64OYco9N8cd%2F7u5BvWZt2RzlDiZVMvAa2F0c14%2FuBHY%3D&reserved=0
Re: RoyaleUnit, EventDispatcher, and Node.js
Posted by Carlos Rovira <ca...@apache.org>.
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 (<jo...@bowlerhat.dev>)
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://bowlerhat.dev>
>
--
Carlos Rovira
http://about.me/carlosrovira