On 9/6/16, 1:38 AM, "Harbs" <harbs.li...@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
