State save params object in 1.10 and Hungarian notation
State save params object in 1.10 and Hungarian notation
Hi,
I am currently migrating my 1.9 datatables code to 1.10. I use server side processing and I also save state to a database.
The object created by datatables for state saving still uses Hungarian notation. Is there a plan for this to change in the future? (Or is it possible to not use Hungarian notation now and I am missing it?)
It is not a major issue, I would just like to know if/when I would need to update my server side code to deal with changes to this object.
Thanks,
David.
This question has accepted answers - jump to:
Answers
Yes! For 1.10.1, and in fact it is a commit I'm hoping to make later on today. The state saving object hasn't really been documented in the past, but it will be with 1.10.1 and be an "official" API, so it won't change in future.
Does your server-side code actually care about what is in the object, or does it just store the object as a whole?
Regards,
Allan
Hi Allan,
Thanks for the reply.
The object gets converted into a .net object on the server side so names and structure do matter. It is not a big deal to change though, I was just interested to know if this change was on the cards and it looks like it is.
Is there a time scale for 1.10.1 being released? I ask because as well as this, it also contains a fix for a bug I have been experiencing.
David.
Heh - was planned for today, but its not going to happen unfortunately as I was firefighting other issues the last two days. Unfortunately I'm travelling tomorrow and Friday as well, so its going to slip into next week, which I'm really disappointed about, but so it goes...
Working on it just at the moment :-)
Allan
Committed.
The object structure is available in the documentation, which I'll push out to the site with 1.10.1.
I would recommend if you are storing the state object in the database that you just JSON encode the data as a string. Storing each parameter is not something I would recommend as it will be quite fragile.
Allan
Great, thanks.