I'd like to ask for a solution. For example we have a page. And I have a link to a another action from this page. I want to have an ability to save the values of entered data on the page.
For instance I go to another page enter data and go back. Like the wizard. But the problem is that we can come to the action from different pages. And it need to save several data types.
Is it understand?
Any suggestions?
I'd like to have common solution....
You could also use TempData to persist data between requests.
In the past for wizards I have used Session to store data as it gets built up along the way.
One thing to not forget is to validate the data you are storing in the session everytime you go to use it. If not a user can exploit the back button to fake certain scenarios. For example:
User uses the wizard and gets to step 3 in the wizard.
They then go to another page that is not part of the wizard.
Then the user enters the wizard again and
only gets to step 2 of the wizard.
User then uses the back button to go all
the way back to the original wizard
that they were on step 3 for.
In this case the data in your session if posted will think it came from the original wizard even though the data in the session is reflecting only up to step 2 from when the user accessed the wizard the second time. Use a unique key each time someone starts a wizard and validate it at each step.
Hope that helps and isn't too confusing (it was a bit to me typing it).
An alternative is to persist the data via the TempData but each time you will need to pull it out and persist it for posting back to the next step. Then rebuild it, add to it and repeat. This can be a lot of work as well but at least you don't have to worry about things happening out of synch.
Related
It is kind of a multi-step form. I need to bring back the user to the step he's left off the previous time. There is no user login.
I'm stuck with "whether it is possible to maintain user details without login?!".
Can anyone please tell me what would be the best way to do it in rails?!
TIA!
There are 2 ways of going about it. You can either store the half-filled form on your server or you can store the half-filled form on the user's browser in LocalStorage.
1) Server Method
When the user clicks next step you can have an AJAX call send the data to server. Your server can store this in a table and return the id back to the browser. Store this id in browser's LocalStorage or in cookies.
When the user comes to your form next time, check if your id is present in your choice of storage, if yes then fetch the data from server and move the user to next step of the form.
You might need to think about security implications in this method as well. If a user can figure out you are storing ids and get the fetch URL of half-filled form, they can iterate over them and fetch other user's form as well. So you might store something other than id and still use this approach.
2) LocalStorage method
Everything is same as the previous approach but we are not using server to store the form. Simply use browser to store the form and fetch when the user comes on the website later. LocalStorage is a persistent storage so it'll also be available when the user re-opens their browser.
I hope this clears your problem here.
Wicked is ruby gem that is used to make step wizard forms. I think it should help you.
Perhaps it is my lack of experience still with really stretching MVC and Entity Framework but I've run into a problem I can't really figure out.
Up until now my applications have been simple: I show and hide a few divs in a View, and when the user has entered all data they hit submit and I save it to the database using EF. The complication I have now is I have basically have to have a flow where:
Person Registers -> Register Another Person? If Yes -> Person Registers -> And So On...
EDIT* To Clarify: Person comes in to Register a group of people. The first screen is a form where they enter identification info, next is clicked, and then They are asked if they'd like to add someone else, if they click yes they repeat that process. I create a Registration Object each time this happens until they don't want to add anymore, after which they are directed to a "Confirmation" action that shows them their registrations and let's them submit their registrations.
I need to have a way to temporarily hold that data while the user jumps to different actions and ultimately submits it to be saved. I'd prefer not to hold a bunch of models in a Session variable.
Well, in your given example, you shouldn't be holding on to anything. After each person is registered, that data can be saved to the database immediately before redirecting back to the form to allow the user to register another person. At each step, you're dealing with a discrete unit, so there's no reason not to just save it immediately.
In a different scenario, perhaps something like a wizard, where you collect partial info in multiple steps, which culminate to produce one discrete unit, your only real option is to use something like TempData. TempData is still session-based, and uses the Session object under the hood, but it does have the advantage over traditional use of Session that the data is only persisted through the next request, whereas Session data is persisted for the life of the session, which can be anywhere from minutes to weeks based on configuration.
I have a object that i want to store for a moment. The object is in a controller for now, the controller will generate a view. A AJAX request is made from the view to next controller. For that moment i need the object previously stored. Previously, i used session and it worked well. But not sure it is the right thing to do. Is session the answer for this or is there anything else?
I have used cache also.but as per the cache concept.It will access for all the users.So one user data will be override to another.So the cached object data will be change for the same user.I need to handle the data storage for an particular user(Independent).
How is it possible? anyother approach is there please share me.
In Controller I have used Httpcontext.cache["key"]=dataset;
but some one suggested like this.but its not displaying
Explain:
In Controller: httpcontext.current.cache is not coming.
HttpContext.Currenthandler and HttpContext.Currentnotification properties only coming.So How can we handle the temp data storage in MVC.
Please help me.
You could use TempData if you want to store data for the next request only. If data should be accessible between multiple requests, then use Session. Here is short explanation of each one with examples.
As Alex said you could use TempData but if you want to use the data in multiple request, you could use TempData.Keep("YourKey") after reading the value to retain the data for the next request too. For your Information TempData internally uses Session to store your data (temporarily)
I would recommend URL parameters for a HTTP Get, or hidden form fields for a HTTP Post, if this is short lived. This is highly about avoiding the session.
But if it should really persist, then a database might be a reasonable location. Imagine a shopping cart that you don't want to dump just because a session timed out; because you'd like to remind the user next time about items they still haven't purchased.
Why not use the session? I don't generally recommend using the session, as you could find yourself with a global variable that two different browser windows are manipulating. Imagine a glass. One window is trying to fill it with Ice Tea. Another window is trying to fill it with Lemonade. But what do you have? Is it Lemonade? Is it Ice Tea? Or is it an Arnold-Palmer? If you try to put too much stuff on the session, and overly expect it to just be there, you might create an application that is non-deterministic if heaven forbid a user opens a second window or tab, and switches back and forth between the windows.
I'm more ok with Temp Data, if you truly have no other options. But this is not for persisting data for more than a second. Temp data will disappear after the first request reads it, as in, it's meant for a very temporary usage.
I personally only use TempData if I have to do a redirect where I can't otherwise keep it with me, or if I need to have that data for say generating a PDF or image that is going to be called via a HTTP Get by a viewer on the actual page, and then only if the model data is too large for the GET url ( many browsers only support just over 2000 characters, which long description or many fields could fill up.)
But again, pushing items around in hidden form variables, or in url parameters can be safe, because you have no multiple window use conflicts (each carries around its own data for peace of mind.)
My application (Asp.Net MVC) has great interaction with the user interface (jQuery/js). For example, setting various searches charts, moving the gadgets on the screen and more .. I of course want to keep all data for each user. So that data will be available from any page in the Dumaine and the user will accepts his preferences.
Now I keep all data in a cookie because it did not seem logical asynchronous access to the server each time the user changes something and thet happens a lot.When the user logout from the application I save the cookie to the database.
The Q is how to save the settings back to the db - from the client to the server.
because the are a lot of interactin that I want to record.
example scanrios: closing widget,moving widget,resizing menues, ordering columens..
I want to record that actions. if I will fire ajax saving rutine for each action
ןt will be too cumbersome. Maybe I have no choice..
Maybe I should run an asynchronous saving all of a certain interval seconds.
The problem is the cookie becomes very large. The thought that this huge cookie is attached to each server request makes me feel that my attitude is wrong.
Another problem cookies have size limit. It varies from your browser but I definitely have been close to the border - my cookie easily become 4kb
Is there another solution?
Without knowing your code, have you considered storing the users preferences in a/your database. A UserPreference table with columns for various settings is a possibility.
You could update it via AJAX/JSON if you had a 'Save Preferences' option, or just update it on postback.
EDIT 1: After thinking about it, I think having an explicit 'save preferences' button would be beneficial and practical.
Somewhere on your page, where the use edits the things that generate the cookie, put an button called save, then hook up a jQuery click handler. On click, build a CSV string or another method of storing the preferences for posting back to the server, then use $.post to send it back to an action method in a controller.
Once there, store it in the database somehow (up to you exactly how), then return a JSON array with a success attribute, to denote whether the preference storing was successful.
When the page is loading, get the preferences out of the database and perform you manipulation.
Another solution would be to store the user preferences into the session and write some server side logic (like action filter) that would write those preferences as JSON encoded string on each page (in a script tag towards the end of the markup) making them available to client scripts.
I'm making a simple CRUD app with ASP MVC and I want to have a confirm page when creating a new object and inserting it into the database.
The problem is that I'm having trouble passing the object between actions. I tried to save it in the session after it's created and then retrieving it when the user confirms, but I'm getting an InvalidOperationException when I try to insert it into the database ( I'm using Entity Framework )
I'm not even sure if I'm approaching this the right way. Any ideas?
What I like to do if the schema allows for it, is to have an active flag (and timestamp field) on the record. You insert on the first page without setting that flag. The confirm page merely sets the active flag. Another process can clean dead records that were not confirmed within a certain range of their timestamp. And the object or entity never ties up session memory.
edit for clarity: as a result you only pass the id of the created entity to the confirm page
Tim's is the best basic answer to this but if you don't want to include the extra logic you could also consider using hidden fields on the confirm page so confirming actually resubmits the form data (this means less DB trips and means that you don't have old unconfirmed entries sitting in the DB to filter out but means more data to and from the client).
Another alternative that might be preferred from a UI point of view is to have Tim's answer but if JavaScript is enabled make the submit button instead pop up a confirm screen, clicking OK would submit both the form and the confirmation in one go.