search

neo09 / gwt-platform

Automatically exported from code.google.com/p/gwt-platform
0 stars 0 forks source link

PlaceManager.navigateBack() Only Works The First Time #201

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
For a presenter that has an event triggering PlaceManger.navigateBack() try the 
following:
1. reveal the presenter
2. force the event that triggers PlaceManager.navigateBack() 
3. reveal the same presenter again
4. force the same event that triggers PlaceManager.navigateBack()

What is the expected output? What do you see instead?
The app place should be updated with the previous history token.  Instead, the 
token is not updated.

What version of the product are you using? On what operating system?
gwtp-0.4

Original issue reported on code.google.com by daniel.s...@gmail.com on 13 Sep 2010 at 10:36

GoogleCodeExporter commented 9 years ago

Original comment by philippe.beaudoin on 13 Sep 2010 at 10:38

GoogleCodeExporter commented 9 years ago

Original comment by philippe.beaudoin on 22 Sep 2010 at 1:35

GoogleCodeExporter commented 9 years ago 
I have a similar problem but my situation might reveal more information related 
to the issue.  I have two pages I'm navigating back between.  I double click a 
row in my grid, and it takes me to a details page that has a cancel button.  
The cancel button takes does a navigateBack().  Here's the the sequence of 
actions:

1) Double click client with ID #1, this takes you to the details page for 
client with ID #1.
2) Click cancel.  This takes you back to the grid.
3) Click client with ID#2.  This takes you to the details for client #2.
4) Click cancel.  This takes you to the details for client #1 again, instead of 
the search grid.  The navigateBack() might need push the history token of the 
returned to page back in.

Original comment by sazwer...@gmail.com on 9 Oct 2010 at 8:20

GoogleCodeExporter commented 9 years ago 
I experience the same. Shouldn't navigateBack() just call History.back() ?

I we look at the code we are re-adding the previous token to History as a new 
item, which is wrong because it breaks the browser history.

  public final void navigateBack() {
    if (previousHistoryToken != null) {
      setBrowserHistoryToken(previousHistoryToken, true);
    } else {
      revealDefaultPlace();
    }
  }

  void setBrowserHistoryToken(String historyToken, boolean issueEvent) {
    History.newItem(historyToken, issueEvent);
  }

I have replaced the previous with: 

  public final void navigateBack() {
    History.back();
  }

and it works great. It works even without the previousHistoryToken != null 
check. If the browser does not have a previous token, it just remains there on 
that page.

However, I do not know (haven't look at it) what implications this would have 
on the PlaceHierarchy if any.

As for the previousHistoryToken variable it could be removed as its only 
purpose is to be used in the navigateBack() function.

Original comment by chemamol...@gmail.com on 17 Oct 2010 at 12:58

GoogleCodeExporter commented 9 years ago 
I'm fine changing it to History.back(), or even leaving it out altogether. 

The _only_ reason it was not calling it was so that it would not navigate out 
of the application if you happen to call navigateBack() from the first page 
visited. Now, however, I believe hierarchical places are a much better way of 
handling situations that required navigateBack() before.

Original comment by philippe.beaudoin on 18 Oct 2010 at 12:02

GoogleCodeExporter commented 9 years ago 
@Philippe: Are you suggesting an alternative to using navigateBack()?  In the 
situation I illustrated above in comment #3, how would I use the alternate 
method?

Original comment by sazwer...@gmail.com on 18 Oct 2010 at 5:31

GoogleCodeExporter commented 9 years ago 
The alternative is roughly what I coded, with the (worse) drawback that it only 
works once. Alternatively, one could keep a counter of every inapp navigation 
and decrement this counter on each call to navigateBack()/History.back(), this 
is getting a bit involved though.

The more I think about it, the more I'm inclined to have navigateBack() call 
History.back() and clearly document its limitation on the first page. What do 
you think?

Original comment by philippe.beaudoin on 18 Oct 2010 at 3:12

GoogleCodeExporter commented 9 years ago 
That was my proposition months ago ! So I'm for it :D

Cheers,

Original comment by goudreau...@gmail.com on 18 Oct 2010 at 8:29

GoogleCodeExporter commented 9 years ago 
Bumping to 0.6, preparing release 0.5.

Original comment by philippe.beaudoin on 25 Jan 2011 at 6:33

GoogleCodeExporter commented 9 years ago 
Changed the behavior. The getPreviousHistoryToken method has also been 
deprecated and will be removed in 0.7, as per Issue 317.

Original comment by philippe.beaudoin on 30 May 2011 at 9:23

GoogleCodeExporter commented 9 years ago 
After a quick survey, getPreviousHistoryToken was introduced in 0.6, so it's 
simpler to remove it entirely. If you really required the previous behavior, 
consider keeping your own stack of visited history tokens via the 
NavigationEvent.

Original comment by philippe.beaudoin on 30 May 2011 at 9:40