5 ms·

I thought the work you did was cool but honestly? Hashes are not the place to store page state. See http://www.webmonkey.com/2011/02/gawker-learns-the-hard-way

I thought the work you did was cool but honestly? Hashes are not the place to store page state. See http://www.webmonkey.com/2011/02/gawker-learns-the-hard-way-why-hash-bang-urls-are-evil/ http://www.webmonkey.com/2011/02/gawker-learns-the-hard-way-... for an example. If you need to store page state RESTfully, I would suggest you create a page state resource and PUT your state there. If you need a page's state, ask for it by name. This also has the benefit of keeping URLs shorter and cleaner.

vjeux 15y ago
I'm not sure to understand what you mean. Could you tell me how I would implement that on a concrete example: http://db.mmo-champion.com/items/#table__search_results_item=2%3A-category http://db.mmo-champion.com/items/#table__search_results_item... I want to store: page number, sorted-column, reverse.
- roberthahn 15y ago
  Create a new /items/pageState URI that accepts POST, PUT, and GET requests. POST to /items/pageState to get a handle - this could be a randomly generated small sequence of characters. A response will contain a Location: header with a URL: /items/pageState/aA1 (the aA1 is just an example for this description - each user would get an unused sequence of characters) Anytime the user changes the state of the page, PUT the page number, sorted-column, and reverse fields to /items/pageState/aA1. Now, the url of the items page to http://db.mmo-champion.com/items/?pageState=aA1 http://db.mmo-champion.com/items/?pageState=aA1. When that page loads, the JS will make an Ajax GET request to /items/pageState/aA1 to fetch the state of the page, and re-render it appropriately. If you're concerned about speed, well, don't be. Add support for eTags on /items/pageState, and while the state is unchanged, that data will be fetched from browser cache instead of the network.
  - vjeux 15y ago
    One state per user is not what I want. If the user sorts in one way, give a link, then sorts in another way and put a link back. I want both links to be differents. Also, your solution adds a lot of extra server calls. The goal of client-side sorting & pagination is to avoid those. I don't want to get them back just for the sake of being RESTful.
    - roberthahn 15y ago
      Ah, new constraints on the problem! :) Love it! My solution does not have to add a lot of extra server calls - it all depends on the caching strategy you choose. For example, if you use maxAge, you would only be adding one extra request per new state created, or per new fetch; all subsequent fetches for the same state would automatically pull from the browser cache. To satisfy the linking requirement, I would redesign my solution to just POST the state to /items/pageState, and get back a URI that represents only that state (which can be shared across all users). Combine this with the maxAge, and yes, you would have to make more requests, but the extra overhead would still be way less significant than adding a link to an image on every page (especially in terms of bandwidth) But, chacun à son goût! Everyone prefers their own tradeoffs :)
stanleydrew 15y ago
You have to store state in the URL. Otherwise how can people link to particular "states" within your application? There would be no way to address them without being part of the URL.
- roberthahn 15y ago
  I outlined a way to do this nearby. :) State can be stored using query parameters. If you have enough state that URIs become unwieldy, then the method I suggested nearby would work very well.

vjeux 15y ago

I'm not sure to understand what you mean. Could you tell me how I would implement that on a concrete example: http://db.mmo-champion.com/items/#table__search_results_item=2%3A-category http://db.mmo-champion.com/items/#table__search_results_item... I want to store: page number, sorted-column, reverse.

roberthahn 15y ago
Create a new /items/pageState URI that accepts POST, PUT, and GET requests. POST to /items/pageState to get a handle - this could be a randomly generated small sequence of characters. A response will contain a Location: header with a URL: /items/pageState/aA1 (the aA1 is just an example for this description - each user would get an unused sequence of characters) Anytime the user changes the state of the page, PUT the page number, sorted-column, and reverse fields to /items/pageState/aA1. Now, the url of the items page to http://db.mmo-champion.com/items/?pageState=aA1 http://db.mmo-champion.com/items/?pageState=aA1. When that page loads, the JS will make an Ajax GET request to /items/pageState/aA1 to fetch the state of the page, and re-render it appropriately. If you're concerned about speed, well, don't be. Add support for eTags on /items/pageState, and while the state is unchanged, that data will be fetched from browser cache instead of the network.
- vjeux 15y ago
  One state per user is not what I want. If the user sorts in one way, give a link, then sorts in another way and put a link back. I want both links to be differents. Also, your solution adds a lot of extra server calls. The goal of client-side sorting & pagination is to avoid those. I don't want to get them back just for the sake of being RESTful.
  - roberthahn 15y ago
    Ah, new constraints on the problem! :) Love it! My solution does not have to add a lot of extra server calls - it all depends on the caching strategy you choose. For example, if you use maxAge, you would only be adding one extra request per new state created, or per new fetch; all subsequent fetches for the same state would automatically pull from the browser cache. To satisfy the linking requirement, I would redesign my solution to just POST the state to /items/pageState, and get back a URI that represents only that state (which can be shared across all users). Combine this with the maxAge, and yes, you would have to make more requests, but the extra overhead would still be way less significant than adding a link to an image on every page (especially in terms of bandwidth) But, chacun à son goût! Everyone prefers their own tradeoffs :)

stanleydrew 15y ago

You have to store state in the URL. Otherwise how can people link to particular "states" within your application? There would be no way to address them without being part of the URL.

roberthahn 15y ago
I outlined a way to do this nearby. :) State can be stored using query parameters. If you have enough state that URIs become unwieldy, then the method I suggested nearby would work very well.