So the current goal is to make the data stick from Submit to Submit. Copy the following code into the body of index.php.
<body>
<form method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>">
<?php
$debug = true;
if($debug) {$ta = array_keys($_POST);for($ti=0;$ti<count($ta);$ti++) {echo $ta[$ti]."=".$_POST[$ta[$ti]]."<br>";}}
$FoodCount = $_POST["food_count"]; // Memory, Dr Memory
$FoodUnits = $_POST["food_units"];
$DrinkCount = $_POST["drink_count"];
$DrinkUnits = $_POST["drink_units"];
$FavoriteFlavor = $_POST["favorite_flavor"];
include "include/tutorial_functions.php"; // a collection of functions for various stuff
echo "Hello World...<br />";
echo "Fave Flav:<input type='text' value='".$FavoriteFlavor."' name='favorite_flavor' /> ";
select_command($_POST, $base_name="command"); // pick a command
echo "<br />Food: ";
select_quantity($prefix='food_', $FoodCount, $FoodUnits); // pick a quantity of food
echo "<br />Drink: ";
select_quantity($prefix='drink_', $DrinkCount, $DrinkUnits); // pick a quantity of drink
echo "<input type='submit' name='submit' /> ";
?>
<form>
</body>
The new parts are the block of assignments directly below our debugging statement and the use of those assigned values to inform the various elements of the form what their values should be. By now you recognize $_POST["food_count"] is an access to the array $_POST using the index "food_count" and assigning the value to $FoodCount.
Following the use of $FoodCount down to the function select_quantity() we see that $FoodCount is being fed to what we labeled $Ingredient_Count in the function. It might be occurring to us now that maybe $Ingredient_Count isn't the best sort of function name, it's too specific. Just $Count might be a more appropriate name, maybe $Amount, mumble.
You might also notice that the names don't match between the function call in index.php and the function template in tutorial_functions.php. This is a very good thing. This lets us change the poor names in our function template to good ones without having to find everywhere they were used and change those too. What does have to match is the order of the variables in function call and the function itself. It is best to put the required variables first in the function and the optional variables last.
But the really clever bits of this have probably passed unnoticed. If you look at the code above it makes sense. Once you understand the general syntax of C and a few operators the biggest help or hindrance to producing readable code is reasonable names. Reasonable descriptive names for variables and functions will make your life a lot easier. If you doubt the wisdom of this take a close look at the debug line again.
I know you have already mashed submit, I hope you saw something like:
But there is still something bothersome about the form. That Submit button looks like a pretty much otherwise useless piece of digital flotsam; let's get rid of it. What we would really like is for the form to be submitted when the command select is changed. This is going to need for us to do a bit of translation in the web browser. A change in the value of command needs to be transmogrified into the push of the vanished Submit button. We can't do this with PHP; it runs on the server, so it's
JavaScript to the rescue!
JavaScript to the rescue!
You can't use JavaScript on the forum for obvious reasons.
JavaScript runs on the client-side as opposed to the server-side where PHP runs. This makes it beautifully complementary to PHP. In another complementary fashion we are going to be editing the head of index.php not the body for this piece. Scripts may appear in-line, but I like to segregate them into their own little ghetto in the head. Replace all of the script element in the head with the following:
<script type="text/javascript">
/* These scripts are available globally to all the included files. The scripts
* are executed by the client machine in response to inputs by the user, typing
* input and selecting menus and such.
*
* Unlike the php source, these scripts are visible to the client when view source
* is used. The scrip functions are generally called by form elements when they
* are manipulated by the user, and cause things to happen on the client page.
*
* It is very important in general to test all objects for non-null values before
* attempting to write to them as writing to a null object will hang the script.
* You can tell this is happening when you see that the form doesn't update when
* the values of the <selects> are changed.
*/
function formSubmit()
{ // reload frm1 (everything is frm1) with the current input values
document.getElementById('frm1').submit();
}
function updateMenu() // runs every time any menu <select> is updated
{ //
formSubmit();
}
</script>
Now let's chat. In the opening tag we declare the script type to be text/javascript. We don't have to do this, it's the default. It's nice to make explicit the default though so that everybody is clear on the concept. Inside JavaScript C style comments work. Outside, HTML style comments are necessary. All of the comments are above are true and useful.
Those comments are pretty typical of what I write for comments. I'm lazy, to do this tutorial I swiped all this stuff from a program I already had written and working and deleted the stuff that isn't relevant. I don't like to write about what the code is doing; if I have named things properly I can read that. I comment about why the code is doing what it is doing. That I can't read in the code and I am unlikely to remember from one day to the next.
Our selects pretty much all have onchange='updateMenu();' in the opening tag. The attribute onchange is what we call an event. An event is something that happens to an element like changing value (onchange) or having the mouse move over the element (onmouseover). Events are things which happen to elements; think of them as verbs for elements. Mash here for a more complete treatment of events.
The event onchange causes a call to the function updateMenu() which calls formSubmit() which actually does the heavy lifting. The reason we didn't call formSubmit() directly is that we might want to do other things when a select changes that we don't want to do when some other element wants to submit the form. The actual submitting gets done by the document.getElementById('frm1').submit(); statement. To explain that statement we have to get into something known as the Document Object Model.
I don't want to talk in detail about DOM right now so just take a gander at that little bit of magic that simulates pushing the submit button and then look carefully in the opening tag of the form in the modified body that follows:
<body>
<form id="frm1" method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>">
<?php
$debug = true;
if($debug) {$ta = array_keys($_POST);for($ti=0;$ti<count($ta);$ti++) {echo $ta[$ti]."=".$_POST[$ta[$ti]]."<br>";}}
$FoodCount = $_POST["food_count"]; // Memory, Dr Memory
$FoodUnits = $_POST["food_units"];
$DrinkCount = $_POST["drink_count"];
$DrinkUnits = $_POST["drink_units"];
$FavoriteFlavor = $_POST["favorite_flavor"];
include "include/tutorial_functions.php"; // a collection of functions for various stuff
echo "Hello World...<br />";
echo "Fave Flav:<input type='text' value='".$FavoriteFlavor."' name='favorite_flavor' /> ";
select_command($_POST, $base_name="command"); // pick a command
echo "<br />Food: ";
select_quantity($prefix='food_', $FoodCount, $FoodUnits); // pick a quantity of food
echo "<br />Drink: ";
select_quantity($prefix='drink_', $DrinkCount, $DrinkUnits); // pick a quantity of drink
//echo "<input type='submit' name='submit' /> ";
?>
<form>
</body>
What's different about the opening tag of the form is
id="frm1". You can find all of the
standard attributes here, and
id is one. The short story is that it is a unique identifier for our form. The entire string
document.getElementById('frm1').submit(); is DOMinese for "submit 'frm1' in this document".
One more thing to notice is that the line that echoed out the raw HTML for our former Submit button has been commented out. If you don't do this the button and the DOM fight and things don't work. You want things to work. Don't have two objects try to do the same thing, it's bad and wasteful (also bad).
You'll find that if you copy the script and the body into index.php, save and refresh, that the Submit button disappears and that the form is now submitted every time the value of a select changes. Give it a whirl.
To recap, we learned about events, which are like verbs for elements. We learned that we can use JavaScript to link events to the actions of elements on the browser's page through the Document Object Model. And that the DOM itself is a big black box at the moment. That will change.
You can't use MySQL on the forum for obvious reasons.
xkcd: exploits of a mom. For more, click pic.