rf1234rf1234 Posts: 2,802Questions: 85Answers: 406

Learned something the hard way today. I was confused because overnight saved states
seemed to disappear and I didn't understand why.

The docs weren't too helpful either. While I found this sentence on the page linked above:

The stateDuration indicated to DataTables which API should be used (localStorage: 0 or greater, or sessionStorage: -1).

it doesn't say that the default state saving period is only 7,200 seconds. You must go to the linked page "stateDuration" to figure this out. I never went there because I didn't care about whether Data Tables uses localStorage or sessionStorage. I store it all on the server in a database.

At least I found this little sentence on the "stateDuration" page:

Please note that the value is given in seconds. The value 0 is a special value as it indicates that the state can be stored and retrieved indefinitely with no time limit.

After wasting many many hours doubting my mental health, and having disappointed a couple of my customers, I could finally fix this. Would be great if the docs could be updated to make this a little clearer. Many thanks. Also: Why is the default not unlimited = 0. Why is it just two hours? Two hours isn't much better than sessionStorage, is it?

This question has accepted answers - jump to:


  • allanallan Posts: 61,628Questions: 1Answers: 10,091 Site admin
    Answer ✓


    Sorry you had problems with this. I decided on two hours as the default, as I felt that would be an appropriate amount of time for someone to go to a site, leave and then come back to find their table in the same state. I didn't want the default to be unlimited, where someone might go to a site, forget all about it, come back in a year and wonder why it was on page 2 of the DataTable. Obviously, requirements change per application, which is why I made it configurable.

    I've made a change to the stateSave documentation to call out the roll of stateDuration a bit more. Would that have helped a bit?


  • rf1234rf1234 Posts: 2,802Questions: 85Answers: 406

    I think that's fair enough, Allan. It would have been sufficient to make me take a look at the "stateDuration" docs!

    I resolved the user problem that you described by offering state deletion buttons on data table and global levels. And I also excluded ordering, search and select from "stateLoading".

  • rf1234rf1234 Posts: 2,802Questions: 85Answers: 406

    My users are business users only. Many of them work with my solution every day. State saving isn't active on the public pages, only on the pages with the business solution.

    I am the tech guy and usually don't speak with my users. But last week I happened to speak with the CFO of a mid-size German town and she complained that "overnight" all the layout changes she makes are always gone. I couldn't belive it because I even saved her layouts (= states) in our database ... (you can set that for each user in our solution.)

    I offer local or database state saving. Some users are working on centrally administered machines, e.g. terminal server, where local storage is deleted centrally or they cannot change the settings that local storage isn't deleted when they close the browser. Hence I introduced database state saving. I also offer width changing of the data table. Either the default width or full screen. That is also saved and can always be changed using a custom button.

    If someone is interested in more details I am happy to share.

  • allanallan Posts: 61,628Questions: 1Answers: 10,091 Site admin
    Answer ✓

    Sounds like a great setup. And yes, for saving and restoring states remotely, I think an infinite state duration makes absolute sense.

    Many thanks for the feedback to help improve the docs!


  • rf1234rf1234 Posts: 2,802Questions: 85Answers: 406
    edited January 14

    @allan, I hope the above explanation gives you a little more background on the business requirements I have. I think that Editor and Data Tables are ideal tools for business, particularly back office solutions: Lots of tables with bloody numbers and dates in them. That's what you need in back office :smiley:

    Seriously, all the fancy stuff is mostly redundant in day to day business administration.

    Why Editor and Data Tables? In my case: Development productivity! I couldn't have developed 4 solutions (debt management, general contract management, VAT assessment solution, subsidy management) alone without using Editor and Data Tables. One of my competitors has 10 developers just for debt management! Yes, their solution is a little nicer and has a few more fancy features, but: we are winning public tenders against them. Fair enough for me. I'd rather be the "Aldi" in this game.

Sign In or Register to comment.