You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by yishayw <yi...@hotmail.com> on 2016/09/04 08:59:30 UTC
[FlexJS] Bubbling Problem
https://paste.apache.org/ORA4
In this simple example bubbling isn't working. Am I doing anything wrong? I
tried this on both sprite-refactor and development branches.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Bubbling-Problem-tp54796.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Bubbling Problem
Posted by Alex Harui <ah...@adobe.com>.
It doesn't work on either SWF or JS? I've not done much testing on
either, but I'd be surprised if it failed in the develop branch on SWF.
-Alex
On 9/4/16, 1:59 AM, "yishayw" <yi...@hotmail.com> wrote:
>https://paste.apache.org/ORA4
>
>In this simple example bubbling isn't working. Am I doing anything wrong?
>I
>tried this on both sprite-refactor and development branches.
>
>
>
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Bubbling-Probl
>em-tp54796.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Bubbling Problem
Posted by yishayw <yi...@hotmail.com>.
I've pushed a workaround that adds a new prop to MouseEvent:
targetBeforeBubbling. It's not pretty but it helps get the correct screenX
and clientX values, which is important in our app. Feel free to come up with
a better solution...
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Bubbling-Problem-tp54796p56747.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Bubbling Problem
Posted by yishayw <yi...@hotmail.com>.
MouseEvents don't bubble well wither on the SWF side. The target is mistaken
for the forwarder.
I filed a bug here [1]
This is a problem for us in our app.
[1]https://issues.apache.org/jira/browse/FLEX-35185
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Bubbling-Problem-tp54796p56693.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Bubbling Problem
Posted by Josh Tynjala <jo...@gmail.com>.
This bubbling issue where something deep in this display list unexpectedly
called a listener at a much higher level that wasn't expecting a different
event type or target annoyed me surprisingly frequently back in the day.
Touch/mouse events are perfect candidates for bubbling because you are
actually interacting with every object up the chain. For most events
dispatched by UI components, the event often doesn't make sense beyond its
target, and maybe 1 or 2 levels up the chain. Re-dispatching, as Alex
suggests, is the right way to go in those situations.
- Josh
On Sep 6, 2016 8:32 AM, "Alex Harui" <ah...@adobe.com> wrote:
> On 9/6/16, 1:38 AM, "Harbs" <ha...@gmail.com> wrote:
>
> >I don’t understand what you mean.
> >
> >It seems to me that bubbling is functionality that users would expect and
> >implementing bubbling should have very little overhead.
>
> Yes, people misused (IMO) bubbling quite frequently in existing Flex code.
> It is very tempting to use it to skip levels in the DOM so some outer
> thing can catch an event from an inner thing like an ItemRenderer.
>
> More than once, a customer wrote in with with one of those hard-to-find
> "can't coerce FooEvent to BarEvent" errors. After much investigation it
> would turn out to be a problem caused by bubbling. IIRC, in one case
> there was a DataGrid in a Panel. But a custom DataGrid ItemRenderer also
> contained a Panel or Callout or something like that. Sure enough, when
> you closed the Panel/Callout, the close event unintentionally bubbled up
> to logic in the ItemRenderer and on up to the outer Panel that contained
> the DataGrid. Once you bubble, you are shouting to the entire parent
> chain unless you further take steps to stop propagation or start checking
> targets. It is better, IMO, to have private conversations between the two
> pieces that care.
>
> I think there was another case where a custom skin picked up an event
> bubbled from a renderer. It worked in one theme, but not another.
>
> And there was another case where someone created a shell app for a
> "mashup" that would host other Flex apps loaded via SWFLoader. Those
> child Flex apps bubbled events that screwed up the shell app because it
> happened to be listening for custom events that had a different semantic
> meaning than the meaning in the child Flex apps.
>
> Bubbling, IMO, was intended for Mouse and Keyboard events (and I think
> Scroll), where there is little doubt that the event will have the same
> meaning globally, and you really do need to figure out who dispatched the
> event since the DOM can be arbitrarily complex. For everything else, I
> believe the best practice is event propagation with increased semantic
> meaning.
>
> Thus, an item renderer containing a "delete" button would listen for
> "click" on the button and dispatch a "rendererDeleted" event off of the
> renderer. If the delete button was buried inside the renderer by several
> containers, there is no wasted effort of the event bubbling up through all
> of those containers. In FlexJS, a custom item renderer factory allows you
> to add "rendererDeleted" listeners to each renderer as it is created. If
> the list was, for example, a list of users, your code containing the List
> and the custom factory might further propagate a "usersListItemDeleted"
> event off of the containing MXML document. Some other controller logic
> could then handle that, and would not be confused from some other list
> deleting things.
>
> So, IMO, the Panel's TitleBar's Close Button should not just bubble a
> Close event. The TitleBar should know to propagate a "close" event and
> the PanelView should know it has a TitleBar and dispatch the event off the
> Panel/strand.
>
> Sure, we should fix bubbling in FlexJS (once we decide on what event model
> we are going with), but in my reading of the Google implementation, the
> parent chain will be walked for every event dispatched. So, I think there
> are plenty of reasons to discourage bubbling and recommend some other
> practice.
>
> My 2 cents,
> -Alex
>
>
>
Re: [FlexJS] Bubbling Problem
Posted by Alex Harui <ah...@adobe.com>.
On 9/6/16, 1:38 AM, "Harbs" <ha...@gmail.com> wrote:
>I don’t understand what you mean.
>
>It seems to me that bubbling is functionality that users would expect and
>implementing bubbling should have very little overhead.
Yes, people misused (IMO) bubbling quite frequently in existing Flex code.
It is very tempting to use it to skip levels in the DOM so some outer
thing can catch an event from an inner thing like an ItemRenderer.
More than once, a customer wrote in with with one of those hard-to-find
"can't coerce FooEvent to BarEvent" errors. After much investigation it
would turn out to be a problem caused by bubbling. IIRC, in one case
there was a DataGrid in a Panel. But a custom DataGrid ItemRenderer also
contained a Panel or Callout or something like that. Sure enough, when
you closed the Panel/Callout, the close event unintentionally bubbled up
to logic in the ItemRenderer and on up to the outer Panel that contained
the DataGrid. Once you bubble, you are shouting to the entire parent
chain unless you further take steps to stop propagation or start checking
targets. It is better, IMO, to have private conversations between the two
pieces that care.
I think there was another case where a custom skin picked up an event
bubbled from a renderer. It worked in one theme, but not another.
And there was another case where someone created a shell app for a
"mashup" that would host other Flex apps loaded via SWFLoader. Those
child Flex apps bubbled events that screwed up the shell app because it
happened to be listening for custom events that had a different semantic
meaning than the meaning in the child Flex apps.
Bubbling, IMO, was intended for Mouse and Keyboard events (and I think
Scroll), where there is little doubt that the event will have the same
meaning globally, and you really do need to figure out who dispatched the
event since the DOM can be arbitrarily complex. For everything else, I
believe the best practice is event propagation with increased semantic
meaning.
Thus, an item renderer containing a "delete" button would listen for
"click" on the button and dispatch a "rendererDeleted" event off of the
renderer. If the delete button was buried inside the renderer by several
containers, there is no wasted effort of the event bubbling up through all
of those containers. In FlexJS, a custom item renderer factory allows you
to add "rendererDeleted" listeners to each renderer as it is created. If
the list was, for example, a list of users, your code containing the List
and the custom factory might further propagate a "usersListItemDeleted"
event off of the containing MXML document. Some other controller logic
could then handle that, and would not be confused from some other list
deleting things.
So, IMO, the Panel's TitleBar's Close Button should not just bubble a
Close event. The TitleBar should know to propagate a "close" event and
the PanelView should know it has a TitleBar and dispatch the event off the
Panel/strand.
Sure, we should fix bubbling in FlexJS (once we decide on what event model
we are going with), but in my reading of the Google implementation, the
parent chain will be walked for every event dispatched. So, I think there
are plenty of reasons to discourage bubbling and recommend some other
practice.
My 2 cents,
-Alex
Re: [FlexJS] Bubbling Problem
Posted by Harbs <ha...@gmail.com>.
I don’t understand what you mean.
It seems to me that bubbling is functionality that users would expect and implementing bubbling should have very little overhead.
On Sep 6, 2016, at 12:12 AM, Alex Harui <ah...@adobe.com> wrote:
> IMO, bubbling is only for interactive events. When you
> bubble an event, the event type/name becomes global. That can pose a big
> problem for mashups and other aggregations.
Re: [FlexJS] Bubbling Problem
Posted by Alex Harui <ah...@adobe.com>.
On 9/5/16, 8:35 AM, "yishayw" <yi...@hotmail.com> wrote:
>I tried adding
>
> (c as ElementWrapper).setParentEventTarget(this);
I think it would be:
(c as ElementWrapper).setParentEventTarget(this.parent)
Still, though, we should also change Panel to use best practices and not
bubble the event. IMO, bubbling is only for interactive events. When you
bubble an event, the event type/name becomes global. That can pose a big
problem for mashups and other aggregations. PanelView should listen to
TitleBar (to be PAYG, PanelViewForTitleBarWithCloseButton should listen to
TitleBarWithCloseButton), and dispatch the "close" event from the Panel.
No need for the parents of Panel to have to think about a "close" event.
-Alex
>
>in UIBase.addChild() but that crashed my test app with an endless
>recursion.
>
>For future reference, I think the problem is that in this piece of code:
>
>goog.events.EventTarget.prototype.dispatchEvent = function(e) {
> this.assertInitialized_();
>
> var ancestorsTree, ancestor = this.getParentEventTarget();
> if (ancestor) {
>
>ancestor is undefined.
>
>I'll see if I can easily fix the Panel 'close' event relying on bubbling
>from the title bar.
>
>
>
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Bubbling-Probl
>em-tp54796p54823.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Bubbling Problem
Posted by yishayw <yi...@hotmail.com>.
I tried adding
(c as ElementWrapper).setParentEventTarget(this);
in UIBase.addChild() but that crashed my test app with an endless recursion.
For future reference, I think the problem is that in this piece of code:
goog.events.EventTarget.prototype.dispatchEvent = function(e) {
this.assertInitialized_();
var ancestorsTree, ancestor = this.getParentEventTarget();
if (ancestor) {
ancestor is undefined.
I'll see if I can easily fix the Panel 'close' event relying on bubbling
from the title bar.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Bubbling-Problem-tp54796p54823.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.