Smice
10-20-2006, 02:21 AM
I am totally stuck on learning how to create forms... can anyone point me in the right direction?
djr33
10-20-2006, 03:24 AM
Open/close tags:
<form>
</form>
<form action="page.php" method="post">
Action: where the data is to be sent:
1. mailto:your@email.com >>this is bad. Don't use it. It requires the user send the data with their mail application, and some don't have it configured correctly. And it just looks bad, from a coding standpoint.
2. Use a page, like page.php above, or a free formmailer (like "http://something.com/mailer.cgi").
Either of those options will allow the sent data to be interpreted. This is complex and a totally different issue for coding. google "form mailer" if you want a free one (usually not too good, and usually will have ads in the email sent), or look into PHP to learn how to code this yourself. It isn't that bad, but certainly more than html. It's a serverside programming language.
method:
This can be either post or get.
they both send the values to the next page.
however, get appends the values to the url, such as:
page.php?field=value&field2=etc
You have probably seen that before.
Only useful, most likely, if you are coding in PHP (and then it can do a lot of great things... mostly making dynamic pages).
Warning: Don't use GET if you are sending a lot of variables/long data. That will make an incredibly long URL, and that might cause issues, as well as just be annoying. And, obviously don't send passwords with GET. It won't be as secure, but more than that, it will just look insecure to the user who is seeing their password in the address bar.
POST is the other option. This does the same exact thing, but it submits without using the URL. They are in the background.
Post is cleaner, so generally use that, unless you have a need for get.
One note with get: since the values are actually just sent as part of the url, you don't need a form for it... you could just do <a href="gallery.php?image=fish"> and that would act in the same way and still be accessible as a get value.
This is probably too much information, but it's good to know.
For you, right now, almost always use POST. If you are using a free form mailer, generally using POST is required as well.
**If you are just using javascript with a form, you don't need to worry about the action or method so much. If you want, for example, something to be calculated without the page reloading and display the answer (etc.), then add to the form tag <form onSubmit="return false;">
This, though, requires javascript, so anyone without javascript will be sent to the action. If you use action="" it will use the current page, which is likely best in this case.
The next part of forms are the fields.
<field type="text" name="NAME" id="ID" value="VALUE">
Types:
>>text... a text field, like for a username or something.
>>password... like text, but it will use asterisks (****) instead of what is typed, for (at least the feeling of) security. Also note that using this prompts a "do you want me to remember this password" alert in most browsers. (doesn't need to be a password, though usually would be)
>>hidden... this won't show on your page and cannot be changed by the user (except through javascript, *maybe*). It is used to send along information. For example, I have used it to store the last page the user was on, so after the form is submitted, it will send them along to there. Basically, if you need to keep information going, then you should use a hidden value. Fairly advanced, though.
I think that's it for types like that.
NAME/ID: These attributes are very similar and do the same thing. I believe both are accessible with the next page (form mailer, php script, even javascript on the next page), but name is, I think, "better" for using in a situation in which you are sending to a "next page".
The name/id sets the title for the field/variable.
If sent using get, <input name="test"> it would be page.php?test=value
I thought that both name and id were ok to use with javascript, but I had trouble with name one time. I'm not sure if it's better to use ID, but I know that works. Someone else may be able to clarify.
VALUE: The value of an input is simple.. it's the value of the textfield, etc.
so... using get... page.php?fieldname=value would be how data is sent.
In php, for example, you can use:
$_POST['fieldname'] to access the value of that field.
With javascript (on the page where the form is) you can access the value of a field like:
document.write fieldname.value;
Note that these attributes are all optional, for the most part, though most are needed in most cases.
Note: there is no close tag for <input>. In xml, then, you would want to use <input ... />
Those are the similar types.
There are a couple others as well....
<input type="checkbox" name="check" id="check" checked>
this is a checkbox. there isn't a value for this.
If you want it to start out selected, then use "checked" as an attribute in the tag.
With a checkbox, javascript is different.
it's: fieldname.checked
So... if (box.checked == 1) {dostuff;}
Dropdown menu (css styling can change this a bit):
<select name="something" id="something">
<option value="1">one</option>
<option value="2" selected>two</option>
</select>
Somewhat similar, but new...
The select tags set the name/id/onChange (javascript), etc. attributes.
Each option in the menu is an option tag. the value of which is sent as the value of the field. the text between <option> and </option> is what the user sees. HTML isn't allowed, just text. (Some basic formatting might be... not sure, but for example, images are not.)
the selected attribute sets the starting value of the dropdown. If there isn't an option set to selected, then the top one is used.
<textarea name="" id="">text goes here</textarea>
This is a text area, like here, when replying to a post.
name/id are as above.
The text in the middle is displayed in the box, then editable by the user. It can be blank to start.
Some html is displayed within the textbox, the rest is put there as text. This is a bit complex.
Also, the attributes rows="5" and cols="20" are supported. This controls the size of the textarea. Rows... easy. Cols.... columns. Rows are significantly larger than cols (height to width), so about 1:4 is probably squarish.
<input type="button" value="label">
<input type="submit" value="send">
<input type="reset" value="reset">
These are all buttons. The first is generic and "does" nothing. It could be used to "click me if you want this to be sent" (like a checkbox, kinda), or for a javascript purpose, using onClick="dostuff();".
Submit submits the form. Simple as that.
Reset resets all of the elements of that form to their original (NOT just blank) values.
The value attribute is especially important here.
This is what is displayed on the button... so... value="send" would make a button called "send". If you don't specify, then it uses a default, which doesn't usually look good.
You can also use the value attribute later when the data is interpreted, like by php. If you want to see if the button was hit, or which submit button, etc. (as in preview or send, etc.).
One last special tag:
<input type="image" src="..." name="" id="">
This is interesting. This is like a normal image tag (width/height are ok, I believe, too).
But it automatically makes it into a pseudobutton that submits the form.
You could just use this for a fancy button.
OR.... the real value is that it adds two extra values to your form:
imagename_x
and
imagename_y
These are then accessible from php or the formmailer, etc.
It's fairly worthless day to day, but very useful in special situations.
I made a color picker a while ago and using allowed me to see which color in a gradient (image that fades from one color to another) was chosen.
That was a nice feature. (It's a cool script too. Twey helped, and now it's set with ajax so it works in realtime to change background color and such.)
It might also help to show where someone clicked... see if they "hit" a target, or something, in some strange game. Not sure, but it might help.
That's about it for the inputs. They are similar, but there are different options as well. I don't think I'm forgetting any, but I might be.
Using javascript is pretty easy with these. As I've hinted at:
field.value is the general way to use a value of a field.
like field1.value = field2.value.
that would set the first input to the vale of the second (in realtime, when called).
The form elements support (mostly):
onClick
onChange
onFocus
onBlur
onSubmit
click is... click. easy. then onClick="function();" (related to the script in the javascript on the page).
Change is AFTER it's changed, when deselected. Not when typing. (That's actually onKeydown or onKeyup, but that's a detail for later on.)
onFocus is when the element is selected.... when the cursor is moved there, etc.
onBlur is the opposite... the moment when it is no longer selected... either by selecting another, or clicking into the main part of the page, etc.
onSubmit is just for the <form> tag (I think). It would allow "return false;" (meaning it wouldn't submit), and other things, like an error checking function (*server side backups are ideal, 'cause javascript can be hacked).
That's a looooong post. Hope it helps. And isn't too confusing :)
Last bits of advice:
Except for some line breaks before/after the form and spacing around that, the form tags do nothing except designate the form area.
So you can have all the html and formatting you want in there. Nothing is special.
If you're just using javascript, no need for form tags... just an input by itself would work (not sure if this is valid, but probably mostly ok).
Lastly, note that you cannot embed one form inside another. this causes all sorts of nasty errors. End one, then you can do another.
codeexploiter
10-20-2006, 04:48 AM
W3 Consortium (http://www.w3.org/TR/html4/interact/forms.html) has a good article about HTML Forms. I think you need to read that also.
djr33
10-20-2006, 06:06 AM
Oh. I forgot radio buttons. Those things are weird. :p
tech_support
10-20-2006, 07:54 AM
Nice tutorial there, djr33 for the newbies :D
djr33
10-20-2006, 09:29 AM
It's more of a ramble than a tutorial, but, yes, I hope it's helpful.
the-disturbed
10-21-2006, 07:01 PM
*watches Smice's brain explode* thats alot of info all at once lol
Post is cleaner, so generally use that, unless you have a need for get.Au contraire... pages that accept GET requests can be bookmarked and used in the history just like an ordinary page with back and forward, whereas POST pages break the navigation model somewhat. If possible, use GET. Reasons to use POST include passwords, files, or if you're performing an action (such as sending an email) that you'd rather the user didn't accidentally perform again.
Powered by vBulletin® Version 4.2.2 Copyright © 2021 vBulletin Solutions, Inc. All rights reserved.