Welcome aboard Snappa!
Something like this, I do this all the time. This is actually a good first step to recycling and re-using code, so you don't have long redundant blocks or script after script using the same stupid code over and over again across many files. :-)
First you define, somewhere, a list of fields used in the form. This is so you can more or less "black box" the function and not rely on globals. It will be the only required parameter for the function. I'll explain why that's important in a bit . . .
$edit_user_fields = Array(
'fname' => 'First Name',
'lname' => 'Last Name',
'email' => 'Email Address'
// etc.
);
Then you have a function
function edit_user_form($formfields,$state=null, $uid=null) {
if (($state and is_numeric($uid) and ($uid > 0)) {
$submitlabel='Update User';
$formaction='1';
// or the URL for your add script, if you don't combine them like
//you do with this your form - which you should. :-)
// do some stuff here to look up the user $uid
// populate $_POST with these variables
}
else {
$submitlabel = 'Add User';
$formaction='0';
}
foreach ($formfields as $key => $value) {
$_POST[$formfield] = isset($_POST[$formfield])?$_POST[$formfield]:null;
}
// build your form
return $form;
}
(<aside> you could probably eliminate $state altogether and only act on edit if there is a $uid is present and found. Error checking is your friend.) This function accepts the form field names array and optionally the form state and uid (if it's edit.) You compose the form itself into the scalar $form, and return it, like
if ($my_uid) {
echo edit_user_form($edit_user_fields,'1',$my_uid);
}
// Otherwise add
else { echo edit_user_form($edit_user_fields); }
Why pass the fields to the function? One of the basic concepts of user input security is
accept only what you want, throw everything else away. It may be a little tedious, but by controlling the list of fields your form will accept you eliminate a large portion of potential attacks, and can focus your cleansing on those fields (which of course would all be cleansed and validated before hitting this form.)
This allows us to do the little foreach before outputting the form, using the (already cleansed!) $_POST values - if they have not been set, we set them now, to null, so you can do things like
$form .= "<label for=\"email\">" . $formfields['email'] . "</label> <input type=\"text\" name=\"email\" id=\"email\" value=\"" .
$_POST['email'] . "\">";
You can now see two advantages of the external list, if you want to change the form labels, you just do it in the centrally located array - not go digging through your script looking for the form. Values populate automatically to re-populate under error conditions.
In practical application, you'd want to add another parameter to pass errors to your function if they exist:
function add_user() {
// return NULL or a string containing the errors
$errors = check_user_input();
if ($errors) {
echo edit_user_form($edit_user_fields,null,null,$errors);
exit;
}
// Normal updates here
}
... this further isolates your form from dependency on other parts of your program.
This is not really a full optimized way of working with forms as it still involves a bit of hard coding in the function, but it's a little better and will allow you to determine the form state externally, using one form for add or edit.
Once you go down this path I swear, you will start combining functions everywhere and your speed will increase tenfold. You won't have an add_user and edit_user function you'll have one update function that adjusts based on the state. You'll compile select statements based on that state. Error checking will adjust based on the state as well. Overall you'll code a lot less, your programs will be easier to debug, and here comes the really cool part - as you build programs for new clients, you really WILL be able to go through a few scripts and copy and paste and it will all just work, because your functions are independent.
