This is probably a pretty easy one, but I'm trying to think of the best way to tackle this problem.
I have a BookItem that I'm adding to a DB and have the following action:
//GET
public ActionResult Add()
The user fills out the form and when they click "save" they post to this action
//POST
public ActionResult Add(BookModel model)
{
return RedirectToAction("AddImage", "Book")
Which then redirects to another page, where a user can add an image.
Now, if the user clicks the back button in the browser, GET Add() is executed. The add book page is displayed, and is filled out with all the data the user entered.
If the user clicks save again, they will post the data and we'll have unintended duplicates in the database.
Seems like a simple problem, but I can't think of a nice solution.
I don't really want to use JavaScript...
It's an MVC2 app.
Thanks in advance!
I believe clearing the form with javascript once the DOM is loaded will be your only option (that I'm aware of).
Related
this is my first post and my English isn’t that good. So I hope you will understand my question/problem.
I'm using the Codeigniter framework for most of my projects and I always have the same problem. Let's have an example:
1.) A logged in user can change his profile with some basic information’s (e.g. displayname, firstname, lastname). The user submits the form and the controller will handle everything and load another view.
2.) In the administration an administrator wants to change the profile of a user. No problem, he clicks "edit" in his userlist and change the last name and submits the form. I have a second controller for that which does almost the same as the profileController but loads a different view.
That's a lot of code duplication and if I want to add a new attribute (e.g. birthday) I have to update many files.
I think a RESTful approach could be a solution for that problem but I am not very familiar with that. Is there another solution?
Do you get the problem?
Thank you for your patience and help!
Let's consider a scenario like below :
Symfony2 provides a removal form for an entity
User selects remove button
Symfony2 controller will remove the entity and redirect the User to confirmation page
If user select browser back button he/she will see the record and removal form again
Selecting Remove button will throw an exception because it was removed already
What is the best way to avoid back button and re-submissions ?
The controller for this question is the same as here.
All data changing requests should be done using the POST method — or PUT, POST or DELETE if you're doing it in the RESTful way. After such a request, redirect to a GET page. If a user will push the back button, the browser will show a warning saying that the request should be sent again and that it can lead to unwanted results. If the user insists on resending the request, she should get a 404 error page because she's trying to do stuff with something that doesn't exist anymore.
I am working with Wicket, trying to create a form where users choose options which correspond to files, which are then merged when the form is submitted and are presented to the user. Currently, the onSubmit() code for the form looks something like this:
ResourceStreamRequestHandler mergedFileHandler = new ResourceStreamRequestHandler(new FileResourceStream(mergedFiles));
mergedFileHandler.setFileName(mergedFiles.getName());
getRequestCycle().scheduleRequestHandlerAfterCurrent(mergedFileHandler);
This works fine when the Submit button is clicked once as the file is offered for download, but when clicked again the page seems to reload itself and the onSubmit() method is not run. Is there a better way to do this, so the user can make changes and re-submit the form to get a different download without having to reload the page or re-enter their options?
Have you tried using AjaxSubmitLink, and then make sure you do not return the file names? It seems like you reload the entire form, and the file names are cleared during reload.
In my page (which displays a list of information), I call a webapage that gets user information and then calls a webservice and a a stored proc for a database on a page (the stored proc inputs or updates a row of data in the db). WHen I click submit, the page is supposed to completely reload the first page with the new updated data and display it to the user. Well, the data does submit to the db, and service, but my page reloads with the old information for some reason, even though I make a call to the entire action that generated the first page. If I navigate back to the home page and then go to the page in question, the data does appear. Should I be waiting or something to call this action again or something?
I do in fact have
[OutputCache(CacheProfile = "ZeroCacheProfile")]
attribute peppered on my actions and in my web.config. Am I missing something? Are there any catches places where I should be carefull when doing this?
I actually recall the entire action that creates the first page.
If you're returning a view directly from the post it may be using the old data. Try redirecting to the GET action to show the results.
This seems to work right now.
Random number = number Random();
RedirectToAction("Action", "Controller", new { value1 = number.Next(0, 100)});
I will go with it for now.
Below is an image of the sections I'm talking about:
What I'm doing is very similar to eBay:
1) a form at the top for "search terms" and then a category.
2) filters on the left that a user can click to refine the search even further.
3) sorting those results.
I played with eBay a bit and it looks to me like they are posting back every time a filter (box on the left) is clicked, or when they sort the results. Do they then store a copy of all the "settings" used to display the page in the form and use that to post back on a submit click?
How can I emulate this functionality? I don't like the idea of wrapping an entire page in a form element... it seems dirty. Should I use jQuery to collect all of the user input and then somehow pass it along?
I'm not sure how eBay does it, but if it were me, I'd have some javascript object that keeps track of all the search options on the page. Each of the elements you've highlighted would fire an event that would cause my javascript object to update this information, send it via AJAX to a controller action, and update the results area with the changes.
That's a somewhat simplified version of events, but hopefully it can put you on the right track.
I've decided that the best solution is to use jQuery Ajax. Otherwise, I'd have to make sure that every peice of user input is a form element and wrap the entire page in a form tag.