User manual APPLE WEBOBJECTS 3.5 DEVELOPPER GUIDE

[. . . ] WEBOBJECTS DEVELOPER'S GUIDE Apple, NeXT, and the publishers have tried to make the information contained in this manual as accurate and reliable as possible, but assume no responsibility for errors or omissions. They disclaim any warranty of any kind, whether express or implied, as to any matter whatsoever relating to this manual, including without limitation the merchantability or fitness for any particular purpose. In no event shall they be liable for any indirect, special, incidental, or consequential damages arising out of purchase or use of this manual or the information contained herein. NeXT or Apple will from time to time revise the software described in this manual and reserves the right to make such changes without obligation to notify the purchaser. [. . . ] For example, if you're writing a catalog application, you must keep track of the items that the user has selected before the user actually fills out the purchasing information. By default, WebObjects stores application state on the server. If this doesn't meet your needs, WebObjects provides several alternatives strategies for storing state. This chapter describes why, when, and how to store state in a WebObjects application. It compares all of the available state-storage strategies, shows you how to implement your own state-storage strategy, plus it describes how to control the amount of application state stored. If you're fairly new to WebObjects programming, you'll probably just want to read the first three sections of this chapter and skip the rest. As you begin to write larger, more complex applications, memory demands and performance become an issue. At that point, you should read the rest of this chapter to learn about alternative state-storage strategies and how you can control the amount of state stored. Before reading this chapter, you should be familiar with concepts presented in the chapter "WebObjects Viewed Through Its Classes. " Why Do You Need to Store State? Originally, the World Wide Web was designed solely for "stateless" applications. An application could display pages and even request information from the user, but it couldn't keep track of a particular user from one transaction to the next. Such an application is like a person with no long-term memory. Each interaction begins with not so much as a "Haven't we met somewhere before?" and ends with an implied "Farewell forever!" Stateless applications aren't well-suited for online commerce since it wouldn't do to lose a customer's order between the catalog and billing pages. Given the ingenuity of software developers, not one but several solutions have been advanced. They fall into two basic categories: · Storing state information on the client's machine. With each transaction the client passes the state information back to the server, in effect "reminding" the server of the client's identity and the state information associated with that client. 111 Chapter 7 Managing State · Storing state information on the server. With each transaction, the web application locates the state information associated with a request from a particular client. The state information might be stored in memory, in a file on disk, or in a standard database, depending on the application. Passing state back to the client with every transaction simplifies the accounting associated with state management but is inefficient and can constrain the design of your site. Storing state on the server, on the other hand, requires sophisticated applications that can keep track of per-session information no matter how many users are accessing the application simultaneously. However, without support from your programming environment, storing state on the server is not an attractive option. As you'll see in this chapter, WebObjects lets you easily make use of any of these state-storage solutions. For a given application, state management can be as simple as selecting the management strategy you want to use and identifying the information that you want stored on a per-session basis. The WebObjects framework does the rest no matter how many users will be accessing the application simultaneously. When Do You Need to Store State? Web applications that store state information are somewhat more complex than those that don't. [. . . ] For example, the following code excerpt produces the NSMutableDictionary dictionary with the value "nonsmoking" for the key "section" and the value "aisle" for the key "seatAssignment. " Notice that the original value for "seatAssignment" is replaced: id dictionary = [NSMutableDictionary dictionaryWithDictionary: @{"seatAssignment" = "window"}]; [dictionary setObject:@"non-smoking" forKey:@"section"]; [dictionary setObject:@"aisle" forKey:@"seatAssignment"]; It is an error to specify nil as an argument for setObject: or forKey:. You can't put nil in a dictionary as a key or as a value. ­ addEntriesFromDictionary: Adds the entries from a specified dictionary to the receiver. If both dictionaries contain the same key, the receiver's previous value for that key is replaced with the new value. ­ removeAllObjects Empties the dictionary of its entries. 204 Commonly Used Dictionary Methods ­ removeObjectForKey: Removes the entry for a specified key. ­ removeObjectsForKeys: Removes the entries for each key in a specified array. ­ setDictionary: Removes all the entries in the receiver, then adds the entries from a specified dictionary. Representing Dictionaries as Strings ­ description Returns a string that represents the contents of the receiver. For example, the following code excerpt produces the string "{"seatAssignment" = "Window"; "section" = "Non-smoking"; "aircraft" = "747"}": id preferences = [NSMutableDictionary dictionaryWithObjects:@("window", "non-smoking", "747") forKeys:@("seatAssignment", "section", "aircraft")]; id description = [preferences description]; Storing Dictionaries ­ writeToFile:atomically: Writes the dictionary's string representation to a specified file using the description method. [. . . ]