redirect GWT application URL

329 views
Skip to first unread message

maq

unread,
Sep 4, 2011, 11:54:52 PM9/4/11
to Google Web Toolkit
Hi,

I want to have people bookmark some internal state of my GWT app.
The URL has format of http://mything.com/#blah or http://mything.com/#!blah
(! added for google crawler).
This URL doesn't look good. It will be nicer to just have http://mything.com/blah

I am playing with a filter in the web.xml so it can redirect, but
having issues.

Has anyone dealt with this problem?

Thanks in advance!

-maq

Y2i

unread,
Sep 5, 2011, 1:05:41 AM9/5/11
to google-we...@googlegroups.com
Are you worried about aesthetic aspects of URL or do you have other considerations?

My URLs, generated by a request factory, look like 

They go deeply into the application internal state, are bookmarkable and work with browser taps as regular URLs.

Thomas Broyer

unread,
Sep 5, 2011, 3:58:18 AM9/5/11
to google-we...@googlegroups.com
Recent browsers implement pushState/onpopstate which allows changing the URL (and not only the "hash" part) without unloading the page. You can see it at work in Google Plus, GitHub's repository browser or even Facebook.
In GWT, you could use deferred binding to replace the Historian implementation used by PlaceHistoryHandler (I bet you could even replace the HistoryImpl instead, at a lower level) if the browser supports pushState/onpopstate, and use the default implementation using the URL's "hash" otherwise.

Qiang Ma

unread,
Sep 5, 2011, 7:52:37 AM9/5/11
to google-we...@googlegroups.com
Thanks Y2i and Thomas.

One of the reason is I wonder if I  can redirect a full domain name to a internal state of my application. For example , I go to a domain hosting to redirect
         http://someotherdomain.com
to
         http://mything.com/#someotherdomain
But the domain hosting service complains about the URL format, it has to be without the hash sign.
         http://mything.com/someotherdomain


Thomas, is your proposal only applicable to new browsers? I wish a solution applies to old browser as well.


-maq


On Mon, Sep 5, 2011 at 2:58 AM, Thomas Broyer <t.br...@gmail.com> wrote:
Recent browsers implement pushState/onpopstate which allows changing the URL (and not only the "hash" part) without unloading the page. You can see it at work in Google Plus, GitHub's repository browser or even Facebook.
In GWT, you could use deferred binding to replace the Historian implementation used by PlaceHistoryHandler (I bet you could even replace the HistoryImpl instead, at a lower level) if the browser supports pushState/onpopstate, and use the default implementation using the URL's "hash" otherwise.

--
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/-/15RjXbOQJqcJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

Qiang Ma

unread,
Sep 5, 2011, 9:27:49 AM9/5/11
to google-we...@googlegroups.com
Just an update...
In the filter, redirect seems not working request.getRequestDispatcher(New_Url);

maq

unread,
Sep 5, 2011, 9:40:00 AM9/5/11
to Google Web Toolkit
Sorry, hit enter before completing the posting.

In the filter, redirect seems not working
request.getRequestDispatcher("http://mything.com/#blah");

Instead, I generate a page that contains the meta tag for redirecting:
PrintWriter out = httpResponse.getWriter();

out.println("<meta HTTP-EQUIV=\"REFRESH\" content=\"0; url=http://
mything.com/#blan\">");
out.close();

This seems working.

On Sep 5, 8:27 am, Qiang Ma <mumay...@gmail.com> wrote:
> Just an update...
> In the filter, redirect seems not working
> request.getRequestDispatcher(New_Url);
>
>
>
>
>
>
>
> On Mon, Sep 5, 2011 at 6:52 AM, Qiang Ma <mumay...@gmail.com> wrote:
> > Thanks Y2i and Thomas.
>
> > One of the reason is I wonder if I  can redirect a full domain name to a
> > internal state of my application. For example , I go to a domain hosting to
> > redirect
> >          http://someotherdomain.com
> > to
> >          http://mything.com/#someotherdomain
> > But the domain hosting service complains about the URL format, it has to be
> > without the hash sign.
> >          http://mything.com/someotherdomain
>
> > Thomas, is your proposal only applicable to new browsers? I wish a solution
> > applies to old browser as well.
>
> > -maq
>

Thomas Broyer

unread,
Sep 5, 2011, 10:15:45 AM9/5/11
to google-we...@googlegroups.com


On Monday, September 5, 2011 1:52:37 PM UTC+2, maq wrote:
Thanks Y2i and Thomas.

One of the reason is I wonder if I  can redirect a full domain name to a internal state of my application. For example , I go to a domain hosting to redirect
         http://someotherdomain.com
to
         http://mything.com/#someotherdomain
But the domain hosting service complains about the URL format, it has to be without the hash sign.
         http://mything.com/someotherdomain


Thomas, is your proposal only applicable to new browsers?

 
I wish a solution applies to old browser as well.

In your entry-point, you could look at the current history token, and if empty, then look at the path (treating /foo the same as #foo, i.e. a history token of "foo"). I.e. do it manually, and only at "initialization" time. If you then navigate into your app, then you'll have http://example.com/foo#bar URLs, which can be confusing.
So redirecting from /foo to #foo might be better (caniuse.com does just that: redirect /history to #feat=history). Then, if you want, you could use replaceState in browsers that support it to redirect once more to /foo, though on the client-side this time, without request to the server for this history change.

As for your redirect issue, request.getrequestDisplatcher() won't help redirecting the client-side, it will "rewrite" the URL on the server-side, but the client won't be aware of that: it requests a URL and is sent a response back. With sendRedirect, a "meta refresh" (as you did), or a JS location.replace() or location assignment, it requests a URL, and is told (at different levels: HTTP, HTML, JS) to rather request another one.
You might want to try several alternatives in many browsers though, as redirecting to a URL containing a "hash part" might not always work as expected (search the GWT issue tracker, I seem to remember an issue with IE)

Qiang Ma

unread,
Sep 7, 2011, 7:04:59 AM9/7/11
to google-we...@googlegroups.com
Hi, Thomas,

I learned a lot from your latest answer. Thanks!

caniuse.com's approach is exactly what I want. Can you give more details on how the redirecting is done for the comment below?
"So redirecting from /foo to #foo might be better (caniuse.com does just that: redirect /history to #feat=history) "?

-maq

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

Thomas Broyer

unread,
Sep 7, 2011, 8:47:01 AM9/7/11
to google-we...@googlegroups.com


On Wednesday, September 7, 2011 1:04:59 PM UTC+2, maq wrote:
Hi, Thomas,

I learned a lot from your latest answer. Thanks!

caniuse.com's approach is exactly what I want. Can you give more details on how the redirecting is done for the comment below?
"So redirecting from /foo to #foo might be better (caniuse.com does just that: redirect /history to #feat=history) "?

Can't you use Firebug or the Chrome Developer Tools (or anything else) to look at the HTTP traffic and/or HTML response?

It actually looks like I was wrong about "caniuse", it doesn't do redirects; but Twitter does redirect from, say https://twitter.com/tbroyer to https://twitter.com/#!/tbroyer (when logged in). They simply use an HTTP redirect (sendRedirect() in servlet parlance).
Reply all
Reply to author
Forward
0 new messages