878Part VCase StudiesThe object types that index.phpcares about (Web host sites)
878Part VCase StudiesThe object types that index.phpcares about are GameDisplayand Game. The Gameobjectcontains all the state information that needs to be preserved from page to page about wherethe user is in the game (score, questions asked already, and so on). The GameDisplayobjectcontains a Gameinstance and does everything necessary to produce an HTML page from it. If the user is starting off for the first time, we create a new Gameobject, relying on the object sconstructor to initialize it appropriately. For subsequent pages, though we rely on the auto- matic object serialization feature of PHP sessions to store the Gameobject for us. (The actualdefinitions of get_session_value()and set_session_value()are in certainty_utils. php, but all that is happening is that we stash the Gameobject in a session. PHP takes care ofthe serialization that is necessary to read the object into a session and back out again.) For more on what it means to serialize an object, see Chapter 20; for an explanation of ses- sions and their workings, see Chapter 24. If the user is in the middle of a game, we expect both a Gameobject stored in the session anda form submission representing either a guess at the answer or a request to be listed on theHigh Scores page. Regardless of whether we create a new Gameobject or retrieve the one from the last page, wecreate a new GameDisplayobject around it and then ask that object for a string that repre- sents the entire HTML page. We store this in a string, ready to echo it out to the browser inthe very last code line. ExceptionsMany things can go wrong with the execution of this game s code. For one thing, of course, there s always a possibility of a code bug that leaves the game in a strange state. In addition, though, the code relies on at least three external services, any of which might misbehave: .The database, which stores the questions and answers .The session mechanism, which is in turn probably relying on files on the hard disk .Cookies stored on the user s browser, which may refuse themIf any of these services turn out to be unreliable, the game will not be playable. Our goal inthis situation should be to fail as gracefully as possible. In a previous edition of this chapter, the code had to catch all the possible failures and propa- gate an error up to this page, which would then detect the failure and display an appropriateerror string. This time, though, we can use PHP5 s exception mechanism, which makes itmuch easier to structure the code. Whenever we encounter a problem that cannot be recov- ered from, we throwthe problem, along with a descriptive string. The catchstatement inindex.phpis the only one in the game s code, and so will receive any of the exceptions thathappen as a result of its calls to functions in other code files. In addition, it will catch theexception thrown in Case 4 of index.php, which probably indicates that the user s browser is not accepting cookies. See Chapter 31 for an introduction to exceptions and error handling. game_display_class.phpAlmost all of the look-and-feel action for this game is in game_display_class.php, as shownin Listing 46-2. Cross- ReferenceCross- Reference52
Note: In case you are looking for affordable and reliable webhost to host and run your j2ee application check Vision J2ee Web Hosting services.