URIFragmentUtility : Possible to update URL without a history entry?

Hello All.

  1. Is it technically possible to change the URI Fragment (and therefore update the URL in the browser) without the change going into the browser’s history
  2. If it is possible, would it be possible to change the UriFragmentUtility component to do this via a flag/property?

Background : all of our views are driven by the URL, using the UriFragmentUtility, giving us the joy of full history support, and the ability to link/jump to a specifc part of the application via a URL enabling third parties/systems to drive users to a specific part of our application (with specific data).
We will have many search screens that contain both fields for the search criteria and the results (master/detail); if values for the criteria are specified on the URL, we do the search as as part of loading the view. Now, if the user modifies the criteria, and searches again, it would be good to be able to update the URL in the browser to show the new criteria values (so that the user could bookmark the search, or cut-and-paste it in a email, etc). However, if a user does lots of searches, we don’t really want to clutter up the history with every set of criteria.

At the moment, I just want to find out if it possible - and then if it’s possible, find out it it’s desirable!

Cheers,

Charles

I don’t think this will solve your problem but we had something similar here:

Page 1> List/search screen and user clicks ‘create new’
Page 2> User enters in basic information to create parent object and clicks ‘save’
Page 3> User views the created parent object and adds child entities, etc.

We use the history mechanism as you described (e.g. when the user clicks a ‘close’ button, the app calls ‘mainWindow.executeJavaScript( “history.back();” );’)…so if they click ‘close’ or press back on Page 3 it will take them to Page 2. The user will be confused because it’ll look like the object was not saved and needs to be reentered. Instead, it should return to Page 1 (the list/search).

How we solved this: there is hashset of fragments that we keep for the session. Before page 2 redirects to page 3, it adds the current fragment to this list. We check the list in fragmentChanged( ) event and automatically invoke ‘History.back( )’ instead of displaying the page. The ‘auto closed’ URLs will flash on the screen but it’ll land on the proper page.