Hi Alex,
thanks for the explanation, so if I understand right, there's not problem
with currentTarget, only that I was trying to use in an incorrect way.
And that the right way to deal with this concrete behavior is through
CHANGE event like I finaly did.
I'm ok as well with the fact that itemClicked is something not needed in
the most basic version to make it PAYG.
Thanks! :)
2018-07-03 18:11 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
> 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, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> 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 <aha...@adobe.com.invalid>:
>
> > 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, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira"
> > <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org>
> 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 <yishayj...@hotmail.com
> >:
> >
> > > Take a look at ItemRendererMouseController.handleMouseUp() in
> > Basic. It
> > > uses currentTarget.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ________________________________
> > > From: carlos.rov...@gmail.com <carlos.rov...@gmail.com> on
> behalf of
> > > Carlos Rovira <carlosrov...@apache.org>
> > > Sent: Monday, July 2, 2018 5:27:08 PM
> > > To: dev@royale.apache.org
> > > 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%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636662019355371776&sdata=cv0ARXbINuhO3IwWt1RDf8UA789U9z
> n7gcerSsncUGA%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
