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
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
>
>
>
>
