Re: Selecting list items from history actions using Activities and Places

I saw that...I meant in my specific Place class. Is it best practice to explicitly implement my own equals() method even if the standard Object.equals would suffice?

Do you see any advantage?

Furthermore, how does this relate to the cachedActivityMapper? I read in a post on this board somewhere that's it's better to implement the cached/filtered mappers rather than override equals(). Thoughts on this?

On Thu, Mar 1, 2012 at 10:34 AM, Chris Price <price.c@gmail.com> wrote:

See the highlighted line in the link I posted, or here's the code -

 public void goTo(Place newPlace) {
   log().fine("goTo: " + newPlace);

   if (getWhere().equals(newPlace)) {
     log().fine("Asked to return to the same place: " + newPlace);
     return;
   }

   String warning = maybeGoTo(newPlace);
   if (warning == null || delegate.confirm(warning)) {
     where = newPlace;
     eventBus.fireEvent(new PlaceChangeEvent(newPlace));

   }
 }

On Thu, Mar 1, 2012 at 3:31 PM, Shaun Tarves <shaun@tarves.net> wrote:
> Hi Thomas/Chris -
>
> Thanks for the responses. I was missing the part about the build-in check
> for Place equality. Any idea how the equality check is implemented?
>
> For example, if my Place has 2 fields - an integer and a string, is it
> implicitly true that 2 places are equal if those values are the same in
> both, or do I need to explicitly define an equals() method?
>
>
> On Thu, Mar 1, 2012 at 10:28 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
>>
>>
>> On Thursday, March 1, 2012 3:23:01 PM UTC+1, Shaun Tarves wrote:
>>>
>>> @Thomas - In the example you pointed me to, what prevents this from
>>> essentially creating an infinite loop? OnSelectionChange fires a new history
>>> event. The history handler responds, gets info and changes the selection,
>>> which would in turn fire a new history event. No?
>>>
>>
>> If the value to be selected is the same as the already-selected one, then
>> no SelectionChangeEvent is fired.
>> If the place to go to is the same as the current place, then this is a
>> no-op too.
>>
>> So there's no infinite loop.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Web Toolkit" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/google-web-toolkit/-/EMJeu1Io5yEJ.
>>
>> To post to this group, send email to google-web-toolkit@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-web-toolkit+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.