If you don't do so, CachingActivityMapper wont cache anything because it also does an oldPlace.equals(newPlace) to see if it can return the cached activity.
-- J.
Am Donnerstag, 1. März 2012 16:40:51 UTC+1 schrieb Shaun Tarves:
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 view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/QdFsGvp7AOYJ.
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.
No comments:
Post a Comment