Add a method PlaceManager.replaceHistory() that is similar to updateHistory() but that does not create an entry in the browser history

[bsautel]

The new HTML5 history API provides a replaceState method that does not create an entry in the browser history.

I would need to use it in a GWTP application. I suggest to create a replaceHistory() method in the PlaceManager that is similar to updateHistory() but that uses the replaceState() History API method.

For browsers that does not support this API, I suggest to fallback to the updateHistory() behavior, they will have several history entries but it will work.

[christiangoudreau]

Fully supporting HTML5 history api with fallback seems to be the way to go for future releases.

I'm going to prioritize this one for minor release after 1.0

[bsautel]

Any news regarding scheduling of this enhancement?

[christiangoudreau]

Will be released in the next version @olafleur, please plan in the next iteration that starts Monday

[bsautel]

Ok, thanks a lot!

[confile]

Well I need this feature too that would be great.

[confile]

@olafleur What do you use at the moment as a workaround?

[steffimueller]

+1 is anyone working on this issue?

[confile]

placeManager.updateHistory(request, true); is only working if the passed PlaceRequest has the same name token as the current place request.

[christiangoudreau]

Bad method: https://github.com/ArcBees/GWTP/blob/b6c8b9e1d210933c4bc60a25c16a2dbb4b8e86ed/gwtp-core/gwtp-mvp-client/src/main/java/com/gwtplatform/mvp/client/proxy/PlaceManager.java#L315

[confile]

This does not solve the problem. I think the point here is to replace the browser url without navigating to another place.

[christiangoudreau]

I know, I was answering that for you ;)

[christiangoudreau]

Closing, that can be done with GWT: http://www.gwtproject.org/javadoc/latest/com/google/gwt/user/client/Window.Location.html

[jmesny]

I think there is a misunderstanding here. The need isn't only to replace the last browser history entry but mainly doing it without refreshing the page.

If what you linked is Location.replace() then according to the description, it's not what we need.

Replaces the current URL with a new one. All GWT state will be lost. In the browser's history, the current URL will be replaced by the new URL.

The only way to replace the last browser history entry keeping the page state is to use the new HTML 5 History API that added a replaceState() function.

[kuhnroyal]

Right, it is not the same. Have you tried https://github.com/jbarop/gwt-pushstate ?

[confile]

GWT-Pushstate does not work with RoutePlaceTokens

[kuhnroyal]

Maybe GWTP should get a HTML5 Placemanager?

[confile]

Yes. HTML5 Placemanager would be great using HTML5 PushState Api if supported and the current PlaceManager otherwise as fallback.

[bsautel]

Is this issue considered as a not important one? The HTML5 History API is necessary to build modern apps. The application that we are building contains several issues that users see as bugs. We cannot solve them because GWTP's PlaceManager does not enable to update URL without creating a new history entry (replaceState in the HTML5 History API)

[rdwallis]

gwt-pushstate works with RouteTokenFormatter now

It's a close to drop in replacement that I've had no issues with.

The gwt-pushstate version in sonatype has some bugs, you can use my version at https://github.com/rdwallis/gwt-pushstate/tree/ohfix just check it out, run maven install add it to your gwt.xml and your pom and you're sorted.

On Mon, Aug 18, 2014 at 10:18 AM, Benoit Sautel notifications@github.com wrote:

Is this issue considered as a not important one? The HTML5 History API is necessary to build modern apps. The application that we are building contains several issues that users see as bugs. We cannot solve them because GWTP's PlaceManager does not enable to update URL without creating a new history entry (replaceState https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history#The_replaceState%28%29.C2.A0method in the HTML5 History API)

— Reply to this email directly or view it on GitHub https://github.com/ArcBees/GWTP/issues/266#issuecomment-52463566.

[confile]

But it does not work with route place tokens like this: !/#somePlace

You can use my fix to make it work: https://github.com/confile/gwt-pushstate

[rdwallis]

it works with tokens like this: /somePlace

with pushstate you no longer need the crawler stuff because you can read the route on the server.

On Mon, Aug 18, 2014 at 1:31 PM, Confile notifications@github.com wrote:

But it does not work with route place tokens like this: !/#somePlace

You can use my fix to make it work: https://github.com/confile/gwt-pushstate

— Reply to this email directly or view it on GitHub https://github.com/ArcBees/GWTP/issues/266#issuecomment-52480493.

[confile]

I think you need the crawler stuff because the crawler bot might not execute the javascript. Therefore it must obtain a prerendered page. This can be done with java prerender.

[rdwallis]

In a day or so I'll be able to demo this privately for you with an app I have in development.

This is a bit complicated but it is a very powerful pattern:

Basically when you get a call on the server at /myrouteplace you make the calls to the dispatcher that the presenter bound to that place will want to make and you include the result in the header of the html you're going to return. Big win so far because now your presenter doesn't need to contact the server before it can display.

While still on the server you can use the results of your dispatch call to generate a very basic html version of your page. And if you structure it similar to the response you're including in the header it won't even add to the payload because of gzip.

This way you get a faster app and suddenly there's content to show bots or users who are frightened of javascript.

On Mon, Aug 18, 2014 at 6:18 PM, Confile notifications@github.com wrote:

I think you need the crawler stuff because the crawler bot might not execute the javascript. Therefore it must obtain a prerendered page. This can be done with java prerender.

— Reply to this email directly or view it on GitHub https://github.com/ArcBees/GWTP/issues/266#issuecomment-52515962.

[confile]

Great I would like to see this solution. Please post a like if you can.

[xak2000]

Very interesting. Are there a library for that or something?

[rdwallis]

I did a write up for this pattern at: https://groups.google.com/forum/#!topic/gwt-platform/-n94IPKWMHU

And you can see the example project at: https://github.com/rdwallis/alice/

[kuhnroyal]

Nice job, I did something similar before with PHP & Javascript, works well.

[jmesny]

@christiangoudreau I really don't understand why you close this issue. One year later the need is still really present.

I'm about to start building a new Single Page Application with GWTP, because I think it's the best choice for my needs, but not having the HTML 5 History API is really disappointing.

Could you please reconsider your choice?

[christiangoudreau]

Will reopen and take a closer look.

[abdulbasitkay]

is anybody working on this? I'm taking a look at it. But wouldn't this be better if it's implemented in GWT's History as a native method? Or does anyone have any direction to point me ?