royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: List Item renderer Click event finds a component in its way
Date Tue, 03 Jul 2018 16:11:19 GMT
Hi Carlos,

If I understand the code correctly, you are getting null because you are listening for click
on Navigation not each individual NavigationRenderer.  currentTarget will be the Navigation.
 The way currentTarget works is specified by the W3C, not us.

This is a good example of how each layer in the DOM should be responsible for dispatching
higher and higher-order events.  I think you mentioned upthread that the NavigationRenderer
might have widgets in it that when clicked, aren't supposed to change the Navigation's selection.
 Having Navigation listen for click on itself or on its NavigationRenderers is not a recommended
practice, because MouseEvent clicks bubble so any click on any widget in the renderer, regardless
off what that click means will be seen by click handlers higher in the DOM. So, higher levels
in the DOM like Navigation should rarely listen for low-level events like "click".
Instead, each NavigationRenderer should abstract the click events and determine which ones
mean that the renderer was clicked and dispatch an itemClick event from the NavigationRenderer.
And the selection management code for the Navigator should be listening for itemClick and
translate that into a "change" event that says that it received an itemClick that changed
the selection.  Click, itemClick and "change" are events with increasingly higher-order semantics/meaning,
and provide abstractions that allow for more complex renderers to interact with the mouse
in ways that don't affect selection.

The most basic List would not redispatch itemClick "just-in-case".  That would not be PAYG.
 Some other version of List could if folks actually need it.  Instead, as you discovered,
using the appropriate level of event for the control means that you don't have to worry about
the low-level events that add up to the event that really was the one you wanted.


´╗┐On 7/3/18, 1:05 AM, " on behalf of Carlos Rovira" <
on behalf of> wrote:

    Hi Alex,
    taking into account the code from JewelExample I just posted. This code:
    private function clickHandler(event:MouseEvent):void
    var renderer:INavigationRenderer = event.currentTarget as
    shows a trace = null, whatever place you click on the renderer (in the
    subcomponents or directly in the renderer). is right but only
    in the renderer as expected.
    So it seems currentTarget is not working right at least in List component.
    2018-07-03 4:10 GMT+02:00 Alex Harui <>:
    > If event.currentTarget is not working, we need to make it work.  That is
    > the recommended way to handle bubbling of events.  The browsers and Flash
    > work that way so folks will expect it to work.
    > The List's change event is not a bubbling event.  Only interaction events
    > like Mouse and Keyboard events should bubble.  There were lots of folks
    > overusing bubbling in old Flex code, but in Royale we should discourage
    > it.  Instead each layer of the DOM should dispatch an appropriate
    > higher-level semantic event.  IOW, while you can "click" anywhere in an
    > item renderer, logic in the item renderer gets to determine whether to
    > dispatch a higher-level semantic event like "itemClick" and "itemClick"
    > events should not bubble.  Some higher-level layer might listen for
    > "itemClick" and turn it into "rowClicked" for a DataGrid, and even
    > higher-level might turn that into "change" or "selectionChange".
    > So, IMO, instead of trying some new mechanism, it would be better to
    > understand why currentTarget is not working for Mouse/Keyboard events, or
    > add the code to propagate semantic events up the parent chain.
    > My 2 cents,
    > -Alex
    > On 7/2/18, 2:44 PM, " on behalf of Carlos Rovira"
    > < on behalf of> wrote:
    >     Hi Yishay,
    >     thanks for let me know about it. I'm playing with it but I didn't get
    > to
    >     work.
    >     The case is that maybe List component is not ready for this yet.
    >     * event.currentTarget seems not exists in ItemRenderers
    >     * I can use "itemClicked" event in a MXML List (I think is not set the
    >     metadata and the rest of wiring)
    >     * List change event doesn't work as well.
    >      Hope you or other could point me to a more elegant solution since
    > right
    >     now, since for me the actual solution is a hack that must be converted
    > to
    >     something more final.
    >     Thanks
    >     2018-07-02 16:38 GMT+02:00 Yishay Weiss <>:
    >     > Take a look at ItemRendererMouseController.handleMouseUp() in
    > Basic. It
    >     > uses currentTarget.
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >
    >     > ________________________________
    >     > From: <> on behalf
    >     > Carlos Rovira <>
    >     > Sent: Monday, July 2, 2018 5:27:08 PM
    >     > To:
    >     > Subject: List Item renderer Click event finds a component in its way
    >     >
    >     > Hi,
    >     >
    >     > what's the best way to handle a click event in a List when the Item
    >     > renderer has some components that can interfere in the click event?
    >     >
    >     > I have an icon and a Label in the item renderer and if I click on
    > one of
    >     > those "" is logically set to this components.
    >     >
    >     > How to make "" always resolve to the item-renderer, even
    > if I
    >     > click in the label or the icon.
    >     > If the label or the icon has a click event, then clicking on one of
    > those
    >     > components should call it's own click handler, but if nothing is set
    > up, a
    >     > click in any part of the renderer should call the list click event
    > handler.
    >     >
    >     > In JS I can set pointer-events : none for sub components in item
    > renderers
    >     > but does not seems the best way to handle this
    >     >
    >     > thanks
    >     >
    >     > --
    >     > Carlos Rovira
    >     >
    > 7C6a108592eeb643ebcf2b08d5e0650676%7Cfa7b1b5a7b34438794aed2c178de
    > cee1%7C0%7C1%7C636661646889224052&sdata=YbiK4qjpjqCpxmvP%2BHBytWFauyvIL%
    > 2BloI7dxNOF6lew%3D&reserved=0
    >     >
    >     --
    >     Carlos Rovira
    > 7C6a108592eeb643ebcf2b08d5e0650676%7Cfa7b1b5a7b34438794aed2c178de
    > cee1%7C0%7C1%7C636661646889224052&sdata=YbiK4qjpjqCpxmvP%2BHBytWFauyvIL%
    > 2BloI7dxNOF6lew%3D&reserved=0
    Carlos Rovira

View raw message