In one article I was reading on ViewState, I saw a sentence saying that I should not fall into a mistake to believe that the value of a TextBox is stored in ViewState; it is stored in PostBack data.
From here what I understand is when I post back a web form, the input controls values are stored in HTTP Request body. Not in the Viewstate. But as far as I know ViewState values are stored in an hidden field called __VIEWSTATE anyway.
Then does it mean that __VIEVSTATE value is not posted in HTTP POST Request body as a postback data? Sounds nonesense to me.
In another words, basically if I say the ViewState mechanism for such scenerio works like this, am I seeing it right or skipping something:
You enter a value on an empty TextBox and submit the page
The value of text box is posted back inside POST HTTP Request body. Nothing inside __VIEWSTATE at this point from the TextBox
On the server side, the TextBox is created with the default value on OnInit method of the page
The TrackChange property of ViewState is set to true.
The posted back data of TextBox is loaded. Because it is different than the TextBox defalut value(because the user entered something), the ViewState of this text box is marked as DIRTY.
The new value of the textbox is written into __VIEWSTATE hidden field
From now on __VIEWSTATE hiddenfeild contains the last given value of the TextBox
The page is sent to the user's browser having the __VIEWSTATE hidden field. But this time containing the last value entered by user which will be ready to be rendered
Thanks guys!
burak ozdogan
ViewState is a hidden input on the page that allows the server to maintain state across multiple requests for the same page. ViewState is maintained by the server, so it stays the same unless the server changes it. ViewState is just a way for the server to talk to itself.
In your example, you wonder why the first time you put a value in a TextBox there doesn't seem to be anything in the ViewState. The reason is that the server has not yet put anything there. When the value of your TextBox reaches the server the first time, the server will place the value in ViewState so it can keep track of it across all subsequent requests.
On the subsequent requests, the TextBox value will be encoded into the ViewState and sent back to the server as POST data.
Related
I have one method which receive two parameters (int?, string). Action in my controller must save this variables and return view with form. After form is returned from client I need this variables from previous request. I can pass them to view with ViewBag and add to form as hidden, but it is very dangerous, anyone can change it in browser. Any ideas?
I think this question does not make sense.
If I have method which receives two parameters with HTTP GET method, so it's no difference where user change this two variables, in get method or in form.
If I store it in server side, he can change when passing parameters to first method and server will store wrong variables.For example:http://www.someurl.com/Controller/Action/?id=123&key=someKeyI can change parameters by editing url, so absurdly store it as variable at server side to make sure that user wouldn't change it by editig hidden fields. Moreover I can check if key is the same key as in database with this id.
Session time is 20 or 30 minutes. User can open this form and submit it when the time of session is out. Users don't like exceptions
It's pretty standard to allow forms to expire after a certain amount of time. You can keep sessions open forever as that's a security hole.
As for the actual value, you can remove it from the session as soon as the second page has been processed. If the value is not there when the second page is hit, simply redirect to the first one again and show a message that says that it took too long time.
Your second option is to use TempData with is specifically designed for storing values between two pages. TempData cannot be accessed by the user.
The third option is of course to store the value in a database (to keep it as long as you want, between logins etc)
You can store any object you like in the current session of the user. In your controller you can use:
// Save value to session
Session["MyVariableName"] = 32;
// Read value from session
int myVariable = (int)Session["MyVariableName"];
For more info regarding the session see: https://msdn.microsoft.com/de-de/library/system.web.httpcontext.session(v=vs.110).aspx
Autocomplete and dynamic dropdown pull data everytime when forms gets changed. Can I narrow down this behaviour, to download data only if a specific field would change?
Cheers
They shouldn't pull data every time form data changes, but only every time the URL changes.
You can use the value of fields in the URL, e.g. passing them as request parameters. In those cases the URL will be reloaded every time the value in those fields changes. But it won't be reloaded if the value in another field, not used on the URL, changes.
In an MVC4 project, I have a form that contains a partial view which is an index view of languages studied at school. It is a default type view template index, with Add, Delete, Edit links per row etc. When you Add or Edit, it opens an Add or Edit view for a Language. After e.g. adding a language, the updated partial view is returned.
My problem is that if the user opens the Language form, edits and captures on the main form will be lost. I can't just do an Ajax save before opening the Language form, as the main form may only be partially complete and fail validation. What I am thinking of doing though is using an AjaxPreserve action that takes a FormCollection, and stores it in session (o on disk, or anywhere) and therefore no model binding and server validation is performed.
I then have two problems: I will need to disable client validation before calling the AJAX action, and I will need to repopulate the main form using the FormCollection I saved earlier. I think there should surly be some jQuery voodoo to disable client validation, but I am completely stumped on repopulating the form.
ALTERNATE SOLUTION: Instead of using 'sub-forms', I can use editor templates, in pop-ip forms, where the FK IDs are not required, but that us only in certain cases, so my question still stands.
Could you use something like Knockout where you create javascript model and bind it to a grid/dialog edit/template view. I would transform the whole data to a JS model, bind it to a table/grid and then track all changes on the client side. When all is done, just serialize the whole model back to the server and update the data store.
If this is an acceptable scenario, it will save you a lot of trouble.
Familiarity with Knockout is required, but if you've used it before, you will be able to solve this in a very clean and efficient way.
This example on the Knockout website gives an idea of what I'm trying to suggest. Editing, deleting, adding is done on the client side until you send all of the data back to the server. You will need to track flags for each object to know if it's added, edited or deleted.
http://knockoutjs.com/examples/contactsEditor.html
Simple make the sub request for adding language using Ajax and repopulate the dropdown or what ever way you are accepting language on the main form on sucessfully save.
*This will save a lot of effort. *
Why don't you just use javascript?
E.g. You have main form, that stores some data. And when you need to add something specific like languages you open popup using partial view, allow user to fill form, but when user press submit you intercept action with js, save stuff to javascript array/object or whatever else and maybe store it in a hidden field of main form - for final submit
var newData = new Object();
newData.Field1 = $("#yourField1");
...
lanuageData.push(newData);
$("#languageContainer").val(JSON.stringify(languageData));
...
DataAnnotation validation works here as well like:
$.validator.unobtrusive.parse("your_partial_view_container");
When you need to edit some object that was already added to js array - open popup and fill it up with element of you js array. So basically you do all CRUD on client-side, saving changes only on final submit.
To make your code in a conrolller more clear you can use custom model binder which deserialize some string field from JSon to List or any other kind of object -> so it can be validated on server side.
Would saving your values to local storage be acceptable? What about using TempData?
I'm using MVC 3 C#.NET.
Is there any way to pass values between pages (two different page with different controllers) without exposing the value in the URL or as hidden values? Is the last resort using a Session variable? Or would you recommend encoding the hidden field (ala ViewState style) and parse that to the controller?
I'm passing several values that I want hidden from the user as they might try to play with the values.
Any suggestions?
Simply use a POST and hidden fields in your form. POST fields do not show up in your URL only GET's. Always try to minimize the use of session variables, those should be used to store user login information, user settings, preferences, etc.
Simply persist this data in some backing storage on your server (could be a database or whatever backing storage you are using). I am not fan of a Session myself so I don't recommend it using it at all. If the user is not supposed to see or modify this data, then this data should not even be passed to the view. It should stay where it belongs => on the server.
I still used hidden fields, but encoded it to Base64, ala ViewState style. It obscures the real values for most users.
While there are similar questions here, none gave a complete answer, so I am posting a new one.
I have a paged grid - jqgrid - which receives data from server by ajax, N rows (10, 20 and so on, depending on the user selection) each time. There is a boolean value in the grid row model, which is transformed into a checkbox in the displayed row.
When user checks the checkbox and then navigates to the next grid page, the state of the checkbox is obviously lost. What is the best approach to save it? Neither of the possibilities that I see fully satisfies me:
I can save the ids of the selected instances into a global javascript object on checkbox click. Thus when new dataset is obtained, I can iterate through all received instances looking for already selected ones. However this can mean a lot of javascript operations and possible slowdown for the final user, if there are a lot of selected instances.
I can store the selection on the server (session, database, whatever else). This way each time the model is generated, I will populate its boolean parameter with an adequate value. However, this can mean that when the user navigates away from my page without submitting the changes and then returns back, the record states will be restored. I am not sure whether this is good. Generally, I am strongly against storing anything on the server side before user submits the form.
So, what would you choose / offer?
I am using ASP.NET MVC 2.0, C# 4.0, if that matters.
Your question is essentially about preserving state in an ajax scenario that does not involve the evil webforms viewstate.
However, there is nothing wrong with viewstate when it is used to preserve state in the kind of scenarios you are working on (as opposed to providing a means to pretend a web page is a winform).
So, why not go for the best of both worlds and store the values in an encrypted hidden field, a sort of lean, mean, smart man's viewstate?
When you request the next page of data, pass back to the server the existing "viewstate" (if any) plus the new checked items, decrypt the viewstate on the server, see what is in there and if it is relevant to the next page, add the new list of checked items, encrypt that and send the new "viewstate" back to the user.
I haven't done this, so it is just an idea. However, it is logically feasible, and very practical. I say I haven't done this with a grid, but I have done it, with huge success, to design a wizard framework that works a dream.
My wizards preserve their state whilst the user is filling in the forms and only in the final step does anything get persisted (if at all, depending on what the app requires).
This framework is based on the wizard described in Steve Sanderson's book, but extended to work seamlessly with or without ajax. And with a very simple API for controllers derived from my wizard controller.
The code that makes this viewstate work is called from an OnActionExecuting method:
protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
var serialized = Request.Form["wizardData"];
if (serialized != null) // Form was posted containing serialized data
{
WizardData = (TModel)new MvcSerializer().Deserialize(serialized);
}
}
And then in the ViewResult returned to the user:
<%= Html.Serialize("wizardData", Model)%>
In your case, as you are just paging data, you would need to serialize and encrypt the equivalent of the wizardData object and send this back with the JSON data to store somewhere in a hidden field.
This is a bit vague, as a wizard is a not a grid of paged data. But the principles (essentially, roll your own viewstate) do apply to both scenarios.
I have addressed this very situation by writing a list of the 'selected' checkboxes in a hidden div when the next page is selected. That way the client maintains the selection list, and no server interaction is required. In addition, when the user finally submits the page, I simply iterate over all the checkboxes in the visible page and the hidden div.
In my system, even in examples where users select hundreds of items, performance is not an issue.