Now that I am ready to start processing the submissions fropm the page I constructed in the previous chapters, I have to be concerned with maintaining state information on the server in order that the pages drawn as events are submitted make sense in terms of what was entered previously on the page. In other words, if I have recorded that the batter has hit a double, the next page drawn should have that batter on second base as a runner.

Before I get into that, however, I have to set the stage a little bit. Well, actually, more than a little bit. As the reader may recall, as I developed the new entry interface I simply hung it off the game option under the league menu. Obviously, I will ultimately need to move that back under the entry option under the game menu. More significantly, I want to implement a better way to select the game that the user wants to enter, as well as modifying the get_session() subroutine (remember that?) to better support the modifications I will be implementing. Finally, I need to add the new tables to the database, including the table that will be used to store state information.

Once I get all that set up, of course, I can start choreographing the dance between the server and the browser. (I kinda like that metaphor.)

Next: Setting the Stage
Setting the Stage, part 2
Setting the Stage, part 3
Coordinating the Dance Between the Server and the Entry Page
Beginning to Process Event Submissions
Processing At Bat Form Submissions, and Extending the Progressive Selection of At Bat Events and Results
Smoothing the Operation of the Interface