Submitting Form onto Itself

Do you ever submit a Form back onto itself?

Or do you prefer to let the Form Display be one page and the Form Action/Results be a separate page?

TomTees

Thinking about it, I tend to agree now.

For me, the main thing I would have to do differently in the form page is check at the top if the sent form data exists and if it does then include the script that contains all the form data processing code.

This way I can still keep the data collection and data processing code in separate files.

Yes, I do. That way, I can do the form values validation and show any errors in the form in the same script. And if everything is ok, I’ll redirect to the result page.

I’m not sure why you would need to replicate any code even if you use separate input and processing.

If you redirect back to the input page from the processing page the input page can check if a session error messages array is set, and if it is then output some js to change font colors to red or whatever and then display the error messages wherever you like in appropriately located elements on the web page.

I normally have one page that say for example displays a form to add a new product to a database catalogue - addProductForm.php

The form’s action attribute would be a separate script - addProduct.php.

addProduct.php does all the form data validation/sanitising and if all is ok, adds the form data and any uploaded product images to the database and disk respectively. The form then redirects to the page that displays all the products so the user can see the new product has been added to the database.

If any errors occur during validation/db ubdating, the error messages are stored in an array as they occur and when addproduct.php has completed processing, the contents of the errors array can be displayed in either addProductForm.php or addProduct.php

I like to keep the code that collects the input data and the code that processes the input data separate.

I do it in other situations as well when I need it.

Separation can be better achieved through separate methods or includes rather than going to different places for essentially the same thing but a change in state. I don’t see any advantage to using completely separate routes. You should never place all the code into a single file put separate it out across files, methods or classes. Just because you go to the same place to initial display the form and process it doesn’t mean you have to be disorganized in your approach.

The simple fact of having two separate scripts (one to handle the form, one to handle the form data) instead of one that contains two very distinct blocks of code (one to handle the form data, one to handle the form) for me doesn’t sound like an advantage, considering I’d have to manage the correct passing of form values and errors back to the form handling script instead of errors.

I’m not saying that my method is better (as this might be something personal like you say), but I’m interested to hear some other opinions. Looking at it from a “separate logic from content” point of view, is it better to follow Kalon’s method? Is there more to using two separate scripts than a personal like/dislike?

I don’t see that as an issue.

You can

$_SESSION['firstName'] = $_POST['txtFname'];

The advantage for me is that the data collection and data processing code is separate and easier to maintain rather than have all the code in one large file. But that might not be an advantage for others.

You’d have to store all form values in session too.

I like to keep the code that collects the input data and the code that processes the input data separate.

Why? I like to keep it together, because I don’t have to save the form values and errors in session, and redirect back to the form in case of errors. What is the advantage of putting the input processing code in a separate script?

This isn’t completely on topic but I always redirect after receiving a POST even if it means storing form variables in a session following invalid data entry. I find there are too many browser issues when you simply put out html following a POST.

Having said that, I do usually process GET and POST in the same file. Never saw a big advantage in breaking them up.

It looks ontopic to me :slight_smile: Could you elaborate a bit more?

I do it ofthen for contact forms so that the error messages appear next or above the fields that people need to log in.

I prefer to submit forms onto themselves so that the proper feedback and/or validation errors can be placed next to form input fields without replicating the same code.

User click the submit button, POST action is kicked off, collects and validates the input and oops something is wrong with the data.

You send the form back along with an error message of some sort. At this point the user might do something like refresh the browser which will kick off another post process. I think I also have ran in to issues with the back button. Always redirecting seems to keep the browser and user happier.

My apps also tend to have a number of forms which I want to keep “sticky” which means that if I navigate away from the form and then come back again I want the data to still be there. This requires saving all the form data in the session.

So always redirecting after a POST really does not make things any more difficult for me.

But you don’t do it for other forms? Why?