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. [. . . ] See the ReusableComponents example application to view the source code for this component. The AlertPanel lets you not only set the message displayed to the user, but also the message's font size and color. These font handling features aren't provided by the AlertPanel itself but by an embedded reusable component, FontString. FontString itself is a versatile component that's used in many other components. · Document the reusable component's interface and requirements. If you plan to make your components available to other programmers, you should provide simple documentation that includes information on: · · · What attributes are available and which are required. For example, is it possible to have a submit button in the same form as the one that contains this component? · In addition, it's helpful if you provide an example showing how to use your component. 108 Chapter 7 Managing State Most applications must be able to preserve some application state between a user's requests. 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. 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. 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. [. . . ] For example, the following code excerpt produces the NSString sectionPreference with the contents "non-smoking": id preferences = [NSMutableDictionary dictionaryWithObjects:@("window", "non-smoking", "747") forKeys:@("seatAssignment", "section", "aircraft")]; id sectionPreference = [dictionary objectForKey:@"section"]; Adding, Removing, and Modifying Entries Warning: The following methods are not supported by NSDictionary. They are available only to NSMutableDictionary objects. ­ setObject:forKey: Adds an entry to the receiver, consisting of a specified key and its corresponding value object. If the receiver already has an entry for the specified key, the previous value for that key is replaced with the argument for setObject:. 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:. [. . . ]