deko wrote:
making progress...
The <?php echo bits cause the form to redisplay what was entered since
the only times the user will see the form are a) if this is the first
time or b) if there was some error in processing the values supplied
to the form.
I was just trying to put the form processing code into a separate file
(not echo it). That's more of a managability thing - for
troubleshooting, I'll put the code in-line.
I'm still having trouble getting the form action working:
<form action="<?php
//write to file for testing - production code will send email
$message_file = "/home/username/public_html/cgi-bin/messages.txt";
$message = $_POST['message'];
$fp_msg = fopen($message_file,"a");
fwrite($fp_msg, $message."\n");
fclose($fp_msg);
?>" method="post" name="feedback" >
<textarea name="message" rows="12" cols="22"
maxlength="4096"></textarea></p>
<input type="submit" value="Send">
</form>
I think you are confused about what the 'action' attribute is about. The
'action' is used by the browser to process the 'submit'. As such, it is
executed on the browser system not the server system.
The problem is nothing gets written to messages.txt!
The redirect is working, now that I have this code at the very top of
the page:
<?php
$message = $_POST['message'];
$email = $_POST['email_address'];
if (!empty($message) && !empty($email))
{
header("Location:http://www.mysite.com/send-confirm.php");
exit;
}
?>
But does this prevent the form's in-line code in the from running?
Should I put the form action code in just above the redirect?
(see below: There is a required separation of the processing of the data
and the capture of the data you need to understand.)
A couple of other questions:
Is "4096" an acceptable value for maxlength? That's about a full page
of text (counting spaces).
Yes. maxlength is more typically used in conjunction with databases
where the text fields have pre-defined maximum sizes.
Should I use the $_REQUEST['message'] variable? I've seen this in a
couple of examples - what is it for?
$_REQUEST is used if you don't know if the form will be sending data via
the POST or GET methods. REQUEST shows both. Personally, I tend to stick
with POST unless I am moving between web portals since POST obscures
the data being transmitted between the browser and the server a bit more.
Thanks!
Here's the deal.
1. break your code into two pieces. I'll call them email.form.html and
email.ctrl.php (ctrl for controller).
2. set up your form as follows:
DOCTYPE ...
<html>
<head>
</head>
<body>
<form action="email.ctrl.php" method="POST">
<input type="text" ... (as per previous email)
</form>
</body>
</html>
Notice that this file is pure HTML.
3. Now set up your controller as:
<?php
if( isset($_POST['message']) {
//write to file for testing - production code will send email
$message_file = "/home/username/public_html/cgi-bin/messages.txt";
$message = $_POST['message'];
$fp_msg = fopen($message_file,"a");
fwrite($fp_msg, $message."\n");
fclose($fp_msg);
}
header("location: email.form.html");
?>
4. Now execute your form - the message should be stored on your browser.
5. In depth:
a) the HTML code in email.form.html paints the form
b) the user fills out the form and clicks the submit button
c) the browser puts the form data into a POST action and sends it the
email.ctrl.php program.
d) the email.ctrl.php sees if there is any POST data and, if so,
saves it to the file
e) it then redirects the browser by telling the browser to load the
email.form.html page again.
f) we are back at a)
This is a rudimentary MVC model where the form is the View and the ctrl
is the Controller.
Now, some people combine the ctrl and the form into one file. In this
case, you would place the ctrl code before the form code in the file. I
tend not to do this because I like to separate the business/validation
logic from the presentation code, but others argue that its nice to have
all the code in one place. Either will work.
Once this is working, you can flesh it out with integrity checks and
other input types (email address, subject, CC, BCC, etc.)
-david-
