Written by: Jesse Stratford [email:jessestratford@actionscript.org]
Time: 15 - 30 minutes.
Difficulty Level: Beginner
Requirements: Flash 5 or higher
Topics Covered: How to convert basic HTML forms to basic Flash forms.
Assumed knowledge: First four Beginner tutes as always. A bit of HTML knowledge. There is no example source for this tute. :o)

Converting HTML Forms To Flash

OK boys and girls, this one warrants a tutorial based on the number of requests we get on the forums and about the place. Most people aren't server-side scripters and yet they like to be able to use things like CGI and PHP for simple things like contact forms and the like. And often as not we get people posting these huge reams of HTML form code, accompanied by "How do I do this in Flash? Thanks!"

Converting HTML forms to Flash is pretty easy (for the most part). The thing to remember is that (in general) the server-side script which processes the data you send doesn't know or care where the data came from, it just knows what it has to do once it gets it. With that in mind, it is safe to say that we can simply replicate the HTML form in Flash and call the same script for processing, and everything should work out just fine.

Most HTML form elements can be replicated in Flash based on rules. Let's make up a basic HTML form. Something simple. OK here's a simple HTML form which takes one input via a text field, has one hidden field, and submits using POST to some backend script. (Don't try and run it, it doesn't work.)

What's your name?

The HTML source to this form is about as simple as it comes. See it here.

So here's where our 'rules' come in. First the input field. Flash's equivalent of this is... you'll never guess it... an Input field! The only trick is that you have to give the field the variable name the form processor expects. In this case, line 3 specifies that the input field stores the variable 'myName' so you create your Flash input field (on the main stage) with the variable 'myName' assigned to it. Next the hidden field. Again this is really easy. Line 5 shows we have a hidden field, marked by the variable 'secret', whose value in this case is the shamelessly self-promoting string, "ActionScripts.org rules!". This is even easier to replicate in Flash, since it's just a variable with a non-editable value. In the Actions panel on the main stage, enter:

[as]secret = "ActionScripts.org rules!";[/as]

That's the fields done. Turn the page *bling*.

Finally, the submit button. This is the hardest bit, which is indicative of how easy this tutorial really is. We ignore the junk on Line 7 of the HTML above and go back to Line 1 which tells us the method and the action of this form, the two important bits of info for submission. In most cases, the method will be either 'get' or 'post' and the action will be the URL of a processing script. Submission can be performed using GetURL or loadVariablesNum (we'll get to which is best in a moment). The syntax is as follows: [as]getURL ("process.php", "", "POST");
// or
loadVariablesNum ("process.php", 0, "POST");[/as]

So as you can see, in each case the 'action' is entered into the URL field and the method is chosen from the 'Variables' drop down. Note that in each case POST could be replaced by GET. For those of you who are unfamiliar with these 'methods', they take all the variables on the timeline from which they are executed (in this case the main timeline, _root) and pass them to the URL specified. GET is great for debugging as it will show the variables in the browser URL line, allowing you to check that your variables are being passed correctly. Of course, if you're passing sensitive information this is the last thing you want, so POST is preferable as it does not show the variables anywhere. POST is also preferable if you're passing more than a few hundred characters, as GET has a character limit. For the purpose of this tutorial I have used POST because it's the most common method used in HTML forms so I wanted to be consistent, but you should always use GET until you are sure your script is working, then change to POST. Also note that there are some documented problems with Flash 5 and the POST action, specifically when executed from a Projector presentation.

So which to use? LoadVariablesNum or GetURL? Well this really comes down to two things. Firstly, if the script you're calling processes data on the fly and outputs results to the browser, you will have to use GetURL so that the results can be viewed, as Flash will not interpret them. You can set the window property of your GetURL command to "_blank" if you want to show the data in a new HTML window without taking the user away from your Flash site. If the processing script simply takes data for storage, or addition to a database, etc. and does not require a visual output, then I would use LoadVariablesNum as it allows your script to run in the background without detracting from your neat Flash environment.

As I said before, the GET and POST methods attach variables stored on the timeline from which they are executed. If your variables are within a MovieClip, run the actions from there.

For those of you who are Intermediate level scripters, you can actually make your own routines in Flash which will process your data. The benefit of this is that you could then use Flash to display your output without having to open a new window or what-have-you. Check out the LoadVariables Interaction tutorial in the Intermediate section for more on this.

Jesse Stratford [email:jessestratford@actionscript.org] is the Co-Master of ActionScript.org and a freelance Flash developer and teacher. He is based in Australia and enjoys all things Flash. NB: If you have comments or feedback please feel free to email me, but please do not email me Flash questions; the forums are provided for that purpose and you will get a faster answer by posting you question there.

If you have found this tutorial helpful, I hope that you will take 30 seconds to visit The Hunger Site where, with just one click you can make a free donation of food to a starving person in a third-world country. We do not benefit financially from this action; it is purely an act of charity.

This tutorial is protected by International Intellectual Property Rights laws and may not be reproduced or redistributed in full or part, without the prior written consent of the author. Unauthorized reproduction of this tutorial or its contents may result in prosecution. I've worked hard on this tutorial, please don't steal it.