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.

HTH,
-Alex

On 7/3/18, 1:05 AM, "[email protected] on behalf of Carlos Rovira" 
<[email protected] on behalf of [email protected]> 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
    INavigationRenderer;
    trace(renderer);
    }
    
    shows a trace = null, whatever place you click on the renderer (in the
    subcomponents or directly in the renderer). event.target is right but only
    in the renderer as expected.
    
    So it seems currentTarget is not working right at least in List component.
    
    Thanks
    
    
    2018-07-03 4:10 GMT+02:00 Alex Harui <[email protected]>:
    
    > 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, "[email protected] on behalf of Carlos Rovira"
    > <[email protected] on behalf of [email protected]> 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 <[email protected]>:
    >
    >     > Take a look at ItemRendererMouseController.handleMouseUp() in
    > Basic. It
    >     > uses currentTarget.
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >
    >     > ________________________________
    >     > From: [email protected] <[email protected]> on behalf of
    >     > Carlos Rovira <[email protected]>
    >     > Sent: Monday, July 2, 2018 5:27:08 PM
    >     > To: [email protected]
    >     > 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 "event.target" is logically set to this components.
    >     >
    >     > How to make "event.target" 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
    >     > https://na01.safelinks.protection.outlook.com/?url=
    > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
    > 7C6a108592eeb643ebcf2b08d5e0650676%7Cfa7b1b5a7b34438794aed2c178de
    > cee1%7C0%7C1%7C636661646889224052&sdata=YbiK4qjpjqCpxmvP%2BHBytWFauyvIL%
    > 2BloI7dxNOF6lew%3D&reserved=0
    >     >
    >
    >
    >
    >     --
    >     Carlos Rovira
    >     https://na01.safelinks.protection.outlook.com/?url=
    > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
    > 7C6a108592eeb643ebcf2b08d5e0650676%7Cfa7b1b5a7b34438794aed2c178de
    > cee1%7C0%7C1%7C636661646889224052&sdata=YbiK4qjpjqCpxmvP%2BHBytWFauyvIL%
    > 2BloI7dxNOF6lew%3D&reserved=0
    >
    >
    >
    
    
    -- 
    Carlos Rovira
    
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc01361909eb24a3e70e908d5e0bbbec1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636662019355371776&sdata=cv0ARXbINuhO3IwWt1RDf8UA789U9zn7gcerSsncUGA%3D&reserved=0
    

Reply via email to