Many forms, one processor.

spookztar

Hi Guys,

Newbie in the process of making an admin interface for an app here. I have a little issue I would like som clarity on, before I really get into it.

I have a collection of forms and would like them all to be processed by just one file (formprocessor), but if a user makes adjustments several times in different forms, how do I prevent the earlier changes in other forms from being re-processed? I want to avoid the resubmitting of information previously submitted when a user makes adjustment later down the script in other forms.

One way that might work is to unset the buttonvariable for that specific form after a change has been successfully made, so only a form with a set button variable get's processed with the code relevant to that sepcific form. Would that do it? is it even necessary?

Is there a standard way this is usually done design-wise?

Thanx for reading.

Bye,

Scriptmaker

Look into using SESSIONS variables. You can set sessions variables after every submission and then have your processor handle all of the sessions variables rather than the POST variables.

spookztar

Ok, didn't exactly make me much wiser as to how that should be done...

How about the unsetting of a given formbutton after successful submission. Wouldn't that work? In this way, earlier forms with unset buttons wouldn't re-submit earlier supplied data in those forms when other forms are submitted later down the script, correct?

rulian

how are these forms related structurally?

?
because that way, keep all your form names unique, use $SESSION as suggested to maintain their values, that way if a form gets resubmitted with different information you simply reestablish the $SESSION variables. Otherwise, you can also update the DB on each different page, or include hidden inputs into the form to keep the previous submission's values.

Scriptmaker

spookztar wrote:
Ok, didn't exactly make me much wiser as to how that should be done...

Did you even look into Sessions before saying that? Sessions store data unique to the user. If you have your forms processors add the data from each post into sessions variables, you can also prevent the variables from being changed just by checking if the variable is empty before filling it. I don't know if you were looking for a tutorial or something, but since you didn't post any specific code or structure of your forms, I wasn't about to give you an entire script.

spookztar wrote:
How about the unsetting of a given formbutton after successful submission. Wouldn't that work? In this way, earlier forms with unset buttons wouldn't re-submit earlier supplied data in those forms when other forms are submitted later down the script, correct?

I really would need to know more about the structure of your forms, because your initial description was kind of confusing to me. If the forms are already built, why not include some code for us to look at? (make sure to wrap it in code tags)

spookztar

I already knew about sessions thank you, and just telling me to use sessions wasn't exactly procedure-specific and concrete.

"I wasn't about to give you an entire script."

? I didn't think presenting code would be necessary, when all I did was specifically ask about a general procedure for doing something like this.

Two pages:

20 forms on one page and a formprocessor on another page to handle them all and the formprocessor only processing data coming from the form who's specific button was set regardless of what other formbuttons may have been set ealier to submit other forms. Pretty simple.

A typical form would look something like this:

<form method='post' action='formprocessor.php'>
<fieldset>
<legend>product.</legend>
<p><label>Name:</label><input name='product' type='text' size='15' maxlength='20' /></p>
<p><label>Product category:</label><input name='product category' type='text' size='15' maxlength='20' /></p>
<p><input type='submit' value='Process' name='button0' /></p>
</fieldset>
</form>

I thought about naming the buttons "button0" up to "button20 to make them stand out from each other. Might also come in handy if a loop should be used.

I was thinking about unsetting a forms button upon finished processing and then have people click a link back to the form page. Wouldn't having a large if/else structure in place in the formprocessor itself that looks for set form buttons prevent the re-processing of previously used forms if their respective buttons got unset after finished processing earlier?

Hope it's more clear now guys.

and thanx for replying by the way...

etully

You can put multiple forms on one page like this:

<form action="processor.php" method=post>
<input type=hidden name=formid value=1>
<input type=text name=a>
<input type=text name=b>
<input type=text name=c>
<input type=submit value="Process This Form">
</form>

<form action="processor.php" method=post>
<input type=hidden name=formid value=2>
<input type=text name=a>
<input type=text name=b>
<input type=text name=c>
<input type=submit value="Process This Form">
</form>

<form action="processor.php" method=post>
<input type=hidden name=formid value=3>
<input type=text name=a>
<input type=text name=b>
<input type=text name=c>
<input type=submit value="Process This Form">
</form>

and then processor.php would look like this:

if ($formid==1) { 
// do whatever you need to do with the variables from form #1
}

if ($formid==2) { 
// do whatever you need to do with the variables from form #2
}

if ($formid==3) { 
// do whatever you need to do with the variables from form #3
}

That way, if they hit the back button and submit a different form, a different value comes through for formid.

"unsetting" of buttons is unprofessional. But if you really wanted to do that, use session variables to record which forms have already been processed. It's the right way to do the job because "unsetting" (whatever that is) is going to vary by platform and therefore be unreliable.

spookztar

Thanx. This is exactly the kind of info I was looking for.

What if they hit an outputted link back to the main formpage instead of using the "back" button?

"unsetting" (whatever that is)"

?? Unsetting a variable like this: unset($variable); has been quite... normal in earlier PHP versions, hasn't it?

http://dk.php.net/manual/en/function.unset.php

etully

?? Unsetting a variable like this: unset($variable); has been quite... normal in earlier PHP versions, hasn't it?

The PHP function [MAN]unset()[/MAN] is very normal... but it's a server side command and doesn't apply to the behavior of forms in your client side browser. When the user is filling in the forms page (no matter whether they got there from a back button or an outputted link), the server side script has stopped running so those variables don't exist anymore - the server side unset() command becomes moot.

"unsetting" (whatever that is)"

"unset" can mean so many things on the client side (disabled submit buttons, fields cleared of their values, or client side variables that remember which forms have been submitted), that it was unclear what kind of client side behavior you meant by unset... but more importantly, the definition of an unset form becomes moot since these behaviors aren't reliable cross browser while server side records (session variables) are.

What if they hit an outputted link back to the main formpage istead of using the "back" button?

If you use session variables to record events, it doesn't matter if they use the back button, outputted links, or even leave your site and come back to the forms later, the form processor will remember which forms have been processed for this user. Trying to accomplish that with Javascript by playing form behavior tricks is harder and less effective - why would you want to do it the hard way when it doesn't work as well?

spookztar

Ok then, thanx for your thorough elaboration.

"When the user is filling in the forms page (no matter whether they got there from a back button or an outputted link), the server side script has stopped running so those variables don't exist anymore"

so what I can deduce here, is that whether a user returns to the forms page to work with more forms by using the "back" button or by an outputted link, it doesn't matter as all variables used in a given form get's blanked no matter which way the user returns to the forms page, so no danger of constantly re-submitting earlier submitted data, and therefore no real need to "record" anything with session variables.

Using sessions to record actions might also require doing more code if the user decides to use the same form again to correct a mistake.

etully

Looking back at your original post, your goal was to make sure that he could fill out one form on the page without worrying about the contents of the other form(s) getting reprocessed.

The sample code I gave you will make sure that when he submits Form #2, it's not going to matter what the contents of the fields are in form #1. They will be ignored because he's submitting form #2 (and formid=2 when he clicks that submit button).

If you wanted (and I'm not saying you have to do this), you could do something like this: When he submits form X, you could process that form and then say $_SESSION['formX']='processed';

That way, if he ever tries to submit form X again (no matter whether he hit the back button, followed a generated link, or even left your site and came back), your code could say, if ($formid==X and $_SESSION['formX']='processed') { print "you can't resubmit that form. That form has already been processed"; }

That's an example of using a session variable to keep a record of what's been done so far so that you can (if you want to) make sure that only certain things are allowed from now on.

You don't have to use session variables. We're not forcing anything on you. Do it any way you want. We're just answering your question: If you want to make sure that a form doesn't get reprocessed, you can easily use sessions to keep track of what's already been submitted.

spookztar

Thanx for further elaborating, etully.

I have been using sessions before briefly, but I'm just not really aware of all the possibiliteis they provide in different kinds of scenarios.

Sessions don't spook me, I don't feel any pressure... I just like to keep the application logic- and footprint as small as possible as bloated code by beginners pose more potential problems later down the road and possibly more security issues.

Thanx,