when a PHP form posts to itself...advantages?

[sneakyimp]

I have a rather massive form i've created for a dating website profile. there are about 40 or so fields...the form is rather huge i must say.

and i'm trying to decide if the form should post to itself or whether i should make a separate PHP file to handle the form action. I'm having a little trouble getting my head around the pros and cons of each approach...seems like having a separate file to handle the action makes MUCH more readable code. On the other hand, when a form posts to itself, it has a chance to validate the information one more time before finally proceeding. I plan to implement some javascript form validation so that one particular advantage is invalidated (harhar).

at any rate, i was hoping some more experienced PHP master could shine some light on my confusion.

POST to self or to a separate file? what say ye?

[AstroTeg]

Tough call. Either will work. Its a matter of your coding style, what's easier for you, and what will get the job done.

This is just my opinion, but I find tossing everything in one file works out well (key is I do use templates so my PHP files have only trace amounts of HTML). Putting it in one file allows me to group my Add/Edit/Delete/List/Validate functions together. For me, this works well. The edit is almost like an add, but I have to retrieve the data to edit and use UPDATE instead of INSERT in the SQL query (and some minor other changes). But otherwise, the two operate about the same.

But I'll also admit none of my forms are that big. Since its that big, it may be easier to toss it in a seperate file, but if server-side validation fails, you'll have to be ready to reload the form with the user's data.

[sneakyimp]

thanks for your response...that's good advice.

to me, the extra stuff in all in one file makes the code less readable. I started to get in the habit of putting the database interface code into classes...let them handle all the gory detail.

I also found it was helpful to put the code to print the form into a function....call it only when you needed it rather than having to nest that code in an IF clause somewhere to explicity avoid it.

the eternal puzzle of coding!

[Sxooter]

I tend to build complex form handling pages by making functions / classes to handle everything, and then the main page looks something like this:

<?php
if (!isset($action)){
    print_default_form();
} else if ($action=="add"){
   add();
} else if ($action=="edit"){
  edit();
} else if ($action=="delete"){
  delete();
} else {
  errorout();
}

# Then comes all the function / class definitions or include them from another file.
?>

[sneakyimp]

interesting, Sxooter...

so you define all your functions at the bottom of your PHP script and keep the main routine super simple? that sounds good.

also of interest is the action=edit part.

the script i just finished determines whether to SAVE or SHOW FORM depending on whether it gets info from GET or POST.

if POST is empty, my code assumes that a simple GET was done...i.e., not much data was passed and we should show the data...and no other forms will POST to this particular document.

if POST contains data, we don't show the form...we run queries to store the posted data.

[AstroTeg]

My processing follows Sxooter's approach. Although after I've fiddled with if statements and switches, I found this snippet of code works great for add/edit/delete dispatching:

$function = '';
if(isset($_GET['Action']))
	$function = 'Do_' . $_GET['Action'];

if(function_exists($function))
	$function($_POST, $_GET);
else
	Do_Default($_POST, $_GET);

What happens is you clear out the variable called function. You check for a URL parameter called "Action" (you could make yours be whatever you like). For "Action", I set it to whatever major thing I need my script to do. Such as add, edit, delete, etc. So I might have Action=Add or Action=Edit.

As you see, if someone fiddles with my Action parameter, if the function doesn't exist, it just boots them back to my default function which is called "Do_Default()" (again, you can rename to suit your needs).

Now when you wish to add functionality, you just figure out what you want your Action= to be, then you setup a function called "Do" and the name of the Action you just created - in this example, I pass along POST and GET data so all my functions are something like "Do[action]($post, $get)". This allows you to add functionality to your script without having to tweak the dispatcher code (such as using if or switch statements).

Of course, this comes at a small price. You have to validate your data. For add, edit, and delete, your have to make sure the data coming in makes sense for that function (which in theory, you should be doing anyways).

I put this snippet of code almost at the top of my index page. I'll wrap my header and footer functions around it. Although in some cases, I'll put the header/footer function calls from within the "Do_" function depending on how many unique header/footer situations I have.

This is just one way (of many many ways) to do it. I prefer checking for an "action" parameter to ensure if you're doing an edit, an edit actually gets performed and I can do the necessary checks for an edit action (versus just testing if the form submitted was a GET or POST).

[sneakyimp]

that sounds brilliant. i think i'm sold.

what exactly do you mean by header and footer functions. I think I'm hip to the header function idea...start sessions, acquire any existing environmental data that might be needed (username, admin priveleges, etc) but would appreciate your more experienced perspective.

and as for footer functions...this is still essentially a complete mystery to me. I haven't been able to think of anything that needs to be done at the end of every single page. I know I'm missing something here...

[tony_l]

I always use header and footers as well.

You can use the INCLUDE() function and have the header in a seperate place- makes things SO MUCH BETTER. Reason I use it is because of my menu scheme. If anything needs to be changed in the menu options- like I need to add something or take away something- I only deal with one file.

AS FOR FOOTERS>>>>

My footer holds my copyright information.

In all actuality, My header and footer compose my page as a giant TABLE. This allows me to have the look and feel of FRAMES, but without the headache of using them.

Example-

HEADER file would have-

all INCLUDE() statements for authorization and such
PRINT("
<html tags and allt he crap that goes at the top of any html page>
<table tag with attributes>
<tr>
<td colspan='3'>My logo image goes here</td>
</tr>

 <tr>
      <td>Menu stuff goes here</td>
      <td>");

At this point you have a center "frame" that becomes your content panel basically. If you call the header.php file at the top of your content page, all you do is print what you want to- you can even have more tables in there- nested tables.

Then your Footer.php file would look like this-

PRINT("
</td> //this ends the content panel
<td>Thsi is where I usually put ads and the like</td>
</tr>
</table>
<center>copyright info goes here.</center>
";

Of course you will need to fill in the colors you want and so on, but this method has REALLY helped me over the years.

[Tracer]

I also use Include()....Works wonders...

Additionally you can use include to seperate your forms into seperate files, but not....

You would always
include('layout.inc')
which could be a basic template for your html, then depending on the situation use different files such as

 if($_POST['action']=='new')
     { include('new.inc'); }
 if($_POST['action']=='edit')
     { include('edit.inc'); }

etc etc

[sneakyimp]

no no...i understand header and footer HTML includes and stuff. i have a clue 😉

he said header and footer 'functions'. I thought he was referring to init type of functions (which i prefer to keep separate from html includes). osCommerce, for instance, has application_top.php....it's a file that sets INI stuff, turns off register_globals and so on, starts the session, and does all kinds of stuff.

they also have application_bottom.php...i just went and dug this up...it just does a session_close and stops a performance profiling function. i guess that kinda answers my question.

i've been thinking about AstroTeg's approach....sounds really handy. I imagine that I might put some code like this in my TOP.php file (included on every page):

$function = ''; 
if(isset($_GET['Action'])) 
    $function = 'Do_' . $_GET['Action']; 

if(function_exists($function)) 
    $function($_POST, $_GET); 
else 
    Do_Default($_POST, $_GET);

and then the various do_action functions will do a little validation an then possibly redirect to the appropriate page which handles the specifics. in effect your index.php file is like a master switching terminal for all your actions. when in doubt, post an action to index.php.

and if there is no action, your account_edit.php page will not be confused at all....its job is not to determine whether you are performing an action or whether you are saving data. by the time you get to the code in account_edit.php, your header functions have already deciphered whatever actions need to be performed...its job is not to reason why, its job is to look in the GET and /or POST variables and retrieve/save the appropriate data.

am i understanding this correctly?

[AstroTeg]

Yup.

As for the header and footer functions, I prefer to toss my headers and footers out using functions. It lets me feel like I have a bit more control over what happens for the process of doing the task(s) involved for a header or footer. Really, whatever works for you will be fine. I didn't mean to toss "function" out to confuse. Its just an approach I use with my code.

You are right about index.php being your dispatcher. It can control what code needs to be run and what files need to be included too. But what makes it handy is to add additional functions and functionality, you don't have to modify an if or switch statement or keep track of a ton of file names.

[TheDefender]

I subscribe to a similar school of thought as sxooter, except I tend to lean on case/switch instead of if/else.

<?php 
IF (!isset($action)): 
    print_default_form(); 
ELSE:

  SWITCH($action):
    case "add":
      add();
      break;
    case "edit":
      edit();
      break; 
    case "delete":
      delete();
      break;
    default:
      errorout();
      break;
  ENDSWITCH;

ENDIF; 

In any respect, I like to keep my functions all tidied up on a separate include.

[rachel2004]

I remember seeing a thread on the php-general list a few weeks regarding this same topic.

One of the posters had done some benchmarks on using includes and then trying it with less includes.

I figure those of you answering to sneakyimp's original post would probably want to know what the benchmark results were, so I checked through the php-general list archives and here you go:

http://marc.theaimsgroup.com/?l=php-general&w=2&r=1&s=php+website+architecture&q=t

[sneakyimp]

this is all good info. i think i have plenty to go on.

fyi, rachel, i tried that link and got something with 100s of posts.

[dalecosp]

And the real reason for putting all your eggs in one basket? <drumroll>

<cymbal cue> ...Cleaner looking directories!! I'm currently doing (among other things) a couple of intranet apps. When you have code that's handling checkbooks, customer contact info, customer purchase/service histories, invoicing, work logs, time logs, appointment calendars, communication logs, intra office messaging, etc., etc., etc. it's much nicer to have 50% fewer scripts in your DocRoot.

Common form/handler scripting --- works great, less filling. 😃