4

I would like to basically do what Jason asked for here

In one sentence, I would like the url bar to represent the state of the AJAX application so that I can allow to bookmark it as well as allow the user to return to the previous state by using the back/forward buttons in the browser.

The difference for me (From what Jason asked) is that I am using JSF 2.0. I've read that JSF 2.0 added the ability to use get, but I am not sure what the correct way to use this.

Thanks for the help.

Further Clarification

If I understand correctly, to be able to bookmark specific states in the AJAX webapp I will have to use the location.hash. Am I correct? I'm trying to achieve a gmail-like behaviour in the sense that, while the app is complete AJAXified and no redirects occur, I can still use Back/Forward and bookmark (And that's why I would like the URL bar to be updated from the AJAX app itself and not through redirection)

Update

Just found this similar question

Community
  • 1
  • 1
Ben
  • 10,020
  • 21
  • 94
  • 157

2 Answers2

3

The difference for me (From what Jason asked) is that I am using JSF 2.0. I've read that JSF 2.0 added the ability to use get, but I am not sure what the correct way to use this.

Please note that this is not the same as maintaining the Ajax state. It usually happens by fragment identifiers (the part starting with # in URL, also known as hashbang). JSF doesn't offer builtin components/functionality for this. As far I have also not seen a component library which does that. You may however find this answer useful to get started with a homegrown hash fragment processor in JSF.

As to using GET requests, just use <h:link>, <h:outputLink> or even <a> to create GET links. You can supply request parameters in the h: components by <f:param>. E.g.

<h:link value="Edit product" outcome="product/edit">
    <f:param name="id" value="#{product.id}" />
</h:link>

In the product/edit.xhtml page you can define parameters to set and actions to execute upon a GET request

<f:metadata>
    <f:viewParam name="id" value="#{productEditor.id}" />
    <f:event type="preRenderView" listener="#{productEditor.init}" />
</f:metadata>

In the request or view scoped bean associated with product/edit.xhtml page -in this example #{productEditor}-, you just define the properties and the listener method. The listener method will be executed after all properties are been gathered, converted, validated and updated in the model.

private Long id;
private Product product;

public void init() {
    product = productService.find(id);
}
Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Thanks @BalusC. If I understand correctly, to be able to bookmark specific states in the AJAX webapp I will have to use the location.hash. Am I correct? I'm trying to achieve a gmail-like behaviour in the sense that, while the app is complete AJAXified and no redirects occur, I can still use Back/Forward and bookmark (And that's why I would like the URL bar to be updated from the AJAX app itself and not through redirection) – Ben May 05 '11 at 12:33
  • Yes you are correct and yes I already understood the functional requirement. Ajax-navigating is unfortunately not exactly trivial as it would need to be specific to the JSF impl and component library used. I *guess*, if Cagatay Civici from PrimeFaces get enough feature requests on that, he will implement it as one of the first JSF component libs with Ajax bookmarkability (shebangs/hashbangs). – BalusC May 05 '11 at 12:36
  • 1
    So is your answer [here](http://stackoverflow.com/questions/3475076/retrieve-the-fragment-hash-from-a-url-and-inject-the-values-into-the-bean) the solution? – Ben May 05 '11 at 12:50
  • 1
    Yes, you can use it. Thank you for the link, I totally forgot that I ever posted this answer :) – BalusC May 05 '11 at 12:55
0

Normally you'd use AJAX to prevent complete page refreshes. AFAIK all current browsers would issue a page refresh if you change the base uri. Thus you would have to use the hash part as suggested in the question you provided.

We had a similar problem and did something like this:

  1. We settled for the fact that users cannot bookmark the url.
  2. For URLs that should be unique/bookmarkable we used different links that issue a redirect. Those URLs are provided in a sitemap.
  3. For browser back, we added an intermediate page after login. This page does navigation and a redirect to the application. The navigation is stored in the session and when the server gets a navigation request (which can be a history back) the corresponding state is restored. A browser back opens that intermediate page which issues a redirect along with a navigation request on the server side.
Thomas
  • 87,414
  • 12
  • 119
  • 157