Viewstate as valid json

[SimonF]

Hi,
we currently working with viewState and are wondering, why the output of the viewstate is non valid json. The RFC about json or a newer version from march 2014 also defines that the keys should be encapsulated by quotes. This is also stated in multiple posts on stackoverflow (e.g. here). Also in known styleguides the json key should be set with quotes Google.

There are multiple sources, which all of them references valid json has surrounding quotes
http://www.json.org/js.html
https://docs.python.org/2/library/json.html
http://json-lib.sourceforge.net/advanced.html
http://help.convertigo.com/latest/to...heoncalls.html
http://cjihrig.com/blog/json-overview/

Since the viewstate is returned as string and not as an object, i think the answer should be valid json.

[Isomorphic]

The format of viewState is intentionally undocumented.

Not only should you not depend on it being valid JSON, you should not depend on it being in any format in particular.

[SimonF]

thanks for stating this out.

The origin of this request is the following:

Using viewstate is surely a nice addition to the smartclinet-framework and it helps the end-user to continue working like he has manipulated the listgrid (same widths, sorting, grouping etc). But there is one big issue that the viewstate cannot deal with procentual widths.

The current state of the implementation is like this:
The end-user is working with a HD-display (1920x1080) and only one listgrid is visible at the whole screen. Then I could save all changes the user has made with the listgrid. Even if the user comes back to the same view, it's all like he has never been gone :-). So far - so good.

If the end-user switches his workplace or does resize his window, the current implemented viewstate is not good. If we assume he has worked with full-screen and saved the viewstate. After that he resized his browser and comes back to the same view with the one listgrid. Then the viewstate ignores the current size of the window and set the old viewstate.

This results that if you revisit the previous view with a smaller window again, the size of the listgridfields is not correct anymore. If you resized all fields, the widths of the fields are now higher than the listgrid itself.
This destroys the whole scenario of the viewstate like it's now implemented. You cannot assume the user doesnt resizes his browser while using the application. Nor can you assume he has always the same resolution of the screen.

Here are some screenshots of the current implemtation:
1. At first we have a simple listgrid


2. the user changes the listgrid, so that he likes it.


3. the user saves the current state

4. after that the user closes the browser and comes back with a smaller resolution (in the example with half the size)
the normal listgrid with %-width would look like and without saved viewstate

but if you set the viewState which was saved by the user it looks like that (this is the current implementation of the viewstate):

I think it should look like that:
http://i.imgur.com/TOx34F3.png (only 4 images allowed)

I think there should be/has to be a possibility to set the viewstate in a valid way, so the user could see all columns.
This could be solved if the viewstate is saved with relative pixel-widths of the listgridfields.
Otherwise you have to use a script to convert the absolute-pixel-widths to relative-width of the listgrid like this

viewState = theListGrid.getViewState()
viewState = viewState.replace(/width:(\d*(\.\d*)?)/g, function (s, aWidth) {
		var percentageWidth = "width:";
		if (aWidth != "") {
			percentageWidth = percentageWidth + "\"" + ((parseInt(aWidth) / gridWidth) * 100) + "%\"";
		}
		return percentageWidth
	});

But then you end up in the point that you have to set the viewState with setViewState(), because you have calculate the relative-with back to pixel widths, because the viewstate string doesn't accept relative widths.

Is there any supported method to assure, that the end-user doesn't get any bad setting list-grid (e.g. unable to see all fields at the beginning) cause of the using the saved viewstates?

[dencel]

Why don't you simply store the resolution in the viewstate and only apply the saved viewstate if the resolution matches the saved viewstate?

[Isomorphic]

It's not clear, when the user resizes a field, whether he intends proportional widths or not. In our opinion, proportional widths are more often the wrong choice than the right. For example, very often the user resizes a field so that it neatly fits typical values, and making that field larger or smaller according to screen width would be wrong (and extremely annoying to the user).

If you're interested in new features that could cause viewState to be recorded as percent widths for specific fields, or perhaps would cause a certain set of fields to soak up extra space proportionally, consider Feature Sponsorship.

With or without such new features, the viewState format will remain undocumented.