Search code examples
gwtgridhrefhistorygxt

GXT (3.1.0) Grid (?) causes browser address change?

I want to integrate a GXT-based view that includes mainly a Grid into an existing GWT application.

  • The grid contains some custom Menus, e.g. accessible from each of the Grid's cells.
  • The GWT application uses GWT's history menchanism.

After integration, the access of the Menu's causes the browser's address to change, e.g.

xxxx://.../?gwt.codesvr=...#MyPlace:param=value -> xxxx://.../?gwt.codesvr=...#

This leads the History mechanism to load a defaultPlace, which is not the desired behavior.

At first I thought GXT's stateful feature might cause the address change in order to maintain state information there. However, the grid is configured stateless and the default Provider used in StateManager is CookieProvider.

  • Is there any other GXT feature that I am not aware of that could cause this kind of behavior?
  • I don't know how to approach debugging this. Any hints on this part?
Solution

  • GXT itself has nothing that could do this - no calls are made to Window.Location (except to check if the web app is http or https), nor are there any JSNI calls to $wnd.location, no references to com.google.gwt.user.client.History or even inherits statements to Activities/Places.

    Without some custom code in your app that is listening to clicks, this pretty much reduces us to some <a href="#"> somewhere in the app, either in GXT itself, or rendered by your own code. Do you have any a tags rendered in your grid, or custom widgets in the menu that might have this?

    Can you reproduce this issue in the (also Activity/Place-enabled) GXT Explorer demo, for example at http://www.sencha.com/examples/#ExamplePlace:basicgrid with the menus and other grid interaction?

    (And yes, you are correct, the state feature only uses cookies if you explicitly ask it to - otherwise it only interacts with whatever other provider is used. None of the defaults will use the url to hold state, though there is no real reason you couldn't do such a thing.)

    To debug this, use your browser's tools to inspect whatever you are clicking on that seems to cause this - is it a <a> tag, with an href pointing at #? If so, why? Or, are there any errant calls to Window.Location.assign or replace, or to History.newItem? Any JSNI that might be doing this same thing?