This is a "pick-your-poison" situation. When you pass a URL parameter (?param=value) it has to be removed to avoid being passed in the future. The only clean way to remove that parameter is through a full page submit. So we should assume that there has to be 1 full page submit before AJAX submits can continue.
You mention that AJAX is not being re-enabled. Can you start with a parameter in the URL, do a few actions that trigger a submit, and then send us the log files? You can verify that the AJAX mode is working by looking at the log file. At the end of the request processing there should be a message "Returning partial update" in AJAX mode, or "Returning full HTML page" in non-AJAX mode.
Right now our implementation says that "first submit is full page submit". If that first submit happens to be a right mouse click on the table that changes table selection, that selection change result in full page submit (and a long wait, unfortunately). After that however, all submits should be AJAX submits so there should be no performance degradation. Is that not what you are experiencing?
Another alternative is to trigger a full page submit as soon as the URL parameter is detected. This would mean that the URL will never show the query parameters, so if a page is submitted to
http://localhost:8040/ajaxswing/apps/myapp?param=value then the browser will be redirected to
http://localhost:8040/ajaxswing/apps/myapp via a full page submit during the same request. It means waiting a little longer during the parameterized request but not having to experience a full page submit later.
It sounds like the second option is what you prefer - is that true? Do you see any issues with it?
We already have an example on how to remove URL parameters through a redirect (the example only works for "test" URL parameter):
if (agent.getRequestData().getParams().get("test") != null) {
TraceMgr.trace("Remove query string by redirecting to " + agent.getInitData().getSubmitURL());
responseData.setRedirectURL(agent.getInitData().getSubmitURL());
}
But we can make this a default product behavior, although it would require some testing.
