CGI is a module that takes care of all the GET-ing and POST-ing of parameters and can make and read all your forms and their elements. It is definitely something worth looking into.

Now for your question, I see a few possible solutions:

1. You loop your script rather than using it once only. Every time you summarize the previous order(s) and you allow the user to add a new order. Only when he pushes the "I'm done ordering!" button, you go to the final screen.
2. You use AJAX and dynamically add lines to your webpage for ordering more pizzas. Modules such as CGI::Ajax, HTML::AjaxTags, JQuery or OpenThought (it has a restaurant demo, which you might find inspiring) or ... can make this easy. For more info on AJAX go here.

And of course, add use strict; and use warnings; to all your code.

Looks like a homework constraint

Well the .edu in http://nova.umuc.edu/~cm375a20/order_pizza.html is a dead giveaway, isn't?

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Sorry I don't understand. As long as I can see your script runs fine. To allow users generating multiple orders you should change the user interface, not the script behind

If this is what you want, I think that a couple of button "Add to your order" and "process order" in the response page could do the trick.

The first button could resend the first page with a hidden field containing a serialized version of the order so far (this is a shortcut, better way would be mantaining a session server-side with the content of the user "cart").

The second button would confirm the order as entered (sum of all the single entry)

PS. Remember to be careful using serialized data in a HTML page. The most obvious way of serialize through Data::Dumper and deserialize with eval open the road to code injection when used on the internet! You should always be aware that anybody can put anything in your hidden fields, and avoid the possibility of exploitation

it is supposed to be able to read in multiple orders and then output all of them. So far, I can only do one order at a time, and I'm not sure how to make it do multiple orders.

1. Store the data in a database (like mysql, sqlite, Oracle, etc.)
2. Store the data in a file on the server.
3. Store the data as client cookies.
4. Store the data as form variables which get continually passed between the pages.

Since this looks like a class assignment, you might see if the instructor has given any indication of a preferred way to do this. For instance, if this is an intro web programming class, I doubt you will be expected to learn how to interact with a database since that would take up a lot of time that could be used to introduce a lot of other concepts. On the other hand, if the class has already covered how to interact with databases, perhaps that's the approach you should pursue.

• Eliminates warnings of the type "Scalar value @topping[0] better written as $topping[0]" when you use warnings;
• Eliminates compiler errors of the type "Bareword "Cheese" not allowed while "strict subs" in use" when you use strict;
• Replaces N scalar variables with 1 hash. In your case, N=3; but N would grow as you add onions, mushrooms, etc. $cheese, $pepperoni and $sausage are replaced by %types.
• Reduces the number of lines of code by about 50% as N grows.

my %types;
for (@fields) {
    $types{Cheese}++     if /cheese/i;
    $types{Pepperoni}++  if /pepperoni/i;
    $types{Sausage}++    if /sausage/i;
}
my @toppings = sort keys %types;
[download]

As expressed by fellow monks- this seems like homework.

Aside of whether it is or not- you may actually want to solve the problem for yourself out of curiosity or interest- not just for a grade.

If you want to solve the problem- I suggest you set aside the code, get some pencil and paper.

Forget perl. Think of what an 'order' is. Think of it perhaps as a data structure, or a set of steps. Each of which may or may not be complete.

Think of orders as some concept you can take out of and put back into a bag. Try to separate the problems and create in your thinking a hierarchy of what is what.
You analize one order at a time, change it, etc.- Put it back in the bag. Be vague.

Look at GGI::Session.. Find a way to store an array of 'orders' in a CGI::Session object.

The Pizza Party script is, as you might imagine, written in Perl.