HTML5 pushState place manager

297 views
Skip to first unread message

James Roper

unread,
May 7, 2012, 8:58:34 AM5/7/12
to gwt-pl...@googlegroups.com
Hello all,

Today I implemented a new PlaceManager that uses HTML5 pushState, rather than the GWT history API:


It treats the entire path/query string as the history token, and falls back to setting window.location if pushState is not available.  It could easily be made to fall back to using the GWT history API, but in my view that defeats the biggest reason for using pushState(), that is, to allow proper URLs that can be easily maintained on the server (using redirects etc).  If one browser has one representation, and another browser has another, then you no longer have maintainable URLs, so no reason to use pushState other than aesthetics.

By itself it works ok, but the following other things could be modified to make the usage of it even better:

* Implement a new token formatter that uses ordinary query string parameters (this could/should be combined with the other work I've done in allowing parameterized place names, see https://groups.google.com/forum/?fromgroups#!searchin/gwt-platform/pushState/gwt-platform/O4hNzXTJkoE/C9zhpm0KPVwJ)
* Modifications to the original PlaceManagerImpl so that handling a place request can be cleanly aborted when pushState is not available (so the browser will just handle the window.location request)
* It overrides a number of package private methods in PlaceManagerImpl, so must live in the same package as this.  Inclusion in GWTP proper would be a much better solution.

To use it, simply make sure it lives in the com.gwtplatform.mvp.client.proxy package (so it can override the package private methods), and then bind it to PlaceManager.class, eg in a Gin module:

bind(PlaceManager.class).to(Html5PushStatePlaceManager.class);

So anyway, would be nice for this to be included in GWTP, GWTP isn't using GitHub or anything where I can submit a pull request yet is it?

Cheers,

James

Christian Goudreau

unread,
May 7, 2012, 9:39:22 AM5/7/12
to gwt-pl...@googlegroups.com
No yet, but I think I'll convince Philippe to move the project to Git and then do a mirror on GitHub.

There's another issue where Raphael modified the tokenformatter to use links like : #!place1/id/{0}

Which can be used instead of window.location and using history,newplace from gwt will give you the same exact thing as it. That is, I use often server side redirection and I don't see why it creates less maintainable URLs.

Cheers,
--
Christian Goudreau

James Roper

unread,
May 7, 2012, 9:49:56 AM5/7/12
to gwt-pl...@googlegroups.com
No yet, but I think I'll convince Philippe to move the project to Git and then do a mirror on GitHub.

That would be great :)
 
There's another issue where Raphael modified the tokenformatter to use links like : #!place1/id/{0}

Actually, that was me, I work with Raphael, and that's what I was referring to :)
 
Which can be used instead of window.location and using history,newplace from gwt will give you the same exact thing as it. That is, I use often server side redirection and I don't see why it creates less maintainable URLs.

By maintainable URLs, what I'm referring to is committing to maintaining a resource at a particular URL, either by it being directly there, or using redirects if it does change.  This is so that external links, which you don't control, don't break when you change your URL structure.

So, let's say an IE user visits a page, and because IE doesn't support pushState they end up on a page that uses hashbangs, and they decide to reference this page from somewhere else.  They copy the current URL (which contains the hashbang) in their browser, and post it to the external site.  Since half the URL is in the hash, if the URL were ever to change, you couldn't implement the change just using redirects, you would have to also maintain Javascript on the site that implemented the client side redirect, which we'd very much like to avoid.  So, the link they posted to the external site will break if you ever change your URL structure, and server side redirects won't help you because it is a hashbang URL.  This is why falling back to hashbangs breaks the maintainability of URLs.
 
 
Cheers,

Christian Goudreau

unread,
May 7, 2012, 10:00:21 AM5/7/12
to gwt-pl...@googlegroups.com
Gotcha, I really misunderstood what you wrote, you're right!
--
Christian Goudreau

Raphael André Bauer

unread,
May 25, 2012, 5:45:45 AM5/25/12
to gwt-pl...@googlegroups.com
On Mon, May 7, 2012 at 4:00 PM, Christian Goudreau
<goudreau....@gmail.com> wrote:
> Gotcha, I really misunderstood what you wrote, you're right!
...
We just finalized the sample apps and changes at the core classes:
http://codereview.appspot.com/6257054/

Feedback heavily appreciated!

Cheers

confile

unread,
Jan 30, 2014, 10:06:02 AM1/30/14
to gwt-pl...@googlegroups.com
Will the new PlaceManager that uses HTML5 pushState be a part of GWTP?

Christian Goudreau

unread,
Jan 30, 2014, 10:07:06 AM1/30/14
to gwt-pl...@googlegroups.com
I'm not sure if it will be part of 1.2 or 1.3, but definitely in our short term plans


--
You received this message because you are subscribed to the Google Groups "GWTP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwt-platform...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
Christian Goudreau | CEO - Président
M: 1.877.635.1585 | S: christian.goudreau

confile

unread,
Jan 30, 2014, 5:27:48 PM1/30/14
to gwt-pl...@googlegroups.com
Great Christian!

There is also this gwt-pushstate lib which seems to bee nice. What about that one?

Christian Goudreau

unread,
Jan 31, 2014, 7:54:20 AM1/31/14
to gwt-pl...@googlegroups.com
GWT-Pushstate is made by one of GWTP contributor, Johannes and the implementation should be based on his work ;) (His first proposal was to introduce that into GWTP) 

confile

unread,
Feb 1, 2014, 9:51:10 AM2/1/14
to gwt-pl...@googlegroups.com
GWT-Pushstate work great but when you have the url http://www.examlpe.com/somepage you still have an ajax page. I did not see a way to use the GWTP Crawler here. 

The problem is that you need to know if a page request comes from a search engine or from a user browser.

1. if the request is from a user browser you can deliver the GWTP page as usual
2. if the request is from a search engine you have to use the GWTP Crawler to get the html content of an Ajax page.

Any idea how to solve this?

Christian Goudreau

unread,
Feb 4, 2014, 6:53:48 AM2/4/14
to gwt-pl...@googlegroups.com
That's a small example in PHP of how to know if the client is a crawler:

confile

unread,
Feb 4, 2014, 7:26:11 PM2/4/14
to gwt-pl...@googlegroups.com
Thank you Christian. Then, I think it must be possible to work with the GWTP Crawler.

Am I right?

Shawn Johnson

unread,
Dec 23, 2014, 3:48:12 PM12/23/14
to gwt-pl...@googlegroups.com
Hi,
Was this (pushState PlaceManager) ever integrated into GWTP?  Sorry if I've missed it in the Documentation.
Thanks!

Christian Goudreau

unread,
Dec 23, 2014, 4:05:57 PM12/23/14
to gwt-pl...@googlegroups.com
No it did not, but is planned to :D

Christian Goudreau | CEO - Président

--
You received this message because you are subscribed to the Google Groups "GWTP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwt-platform...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Richard Wallis

unread,
Dec 24, 2014, 2:16:33 AM12/24/14
to gwt-pl...@googlegroups.com
https://github.com/rdwallis/gwt-pushstate will let you use pushstate with GWTP.

Maybe arcbees wants to take over management for it?

Damien Irving

unread,
Jul 4, 2015, 4:15:22 AM7/4/15
to gwt-pl...@googlegroups.com
I'd love to see this! Seeing pushState used quite a lot these days.
Reply all
Reply to author
Forward
0 new messages