This is an example from the standard WebObjects distribution. It has been coverted to WOPerl.


Cyber Wind

The Cyber Wind application is a small application that allows you to browse electronic sailboard shops and "make a purchase." After making your selection, Cyber Wind requests information from you so your order can be processed. Although the application only implements the thinnest shell of an electronic shop, it's a good example of using the features of WebObjects and WebScript.


Notable Cyber Wind Components

Main
The Main.wos script comments include a description of the lifetime of a WOWebScriptComponentController. The description includes a discussion of initializing variables in awake.
Surfshops
Surfshops.wos contains an example of creating NSArrays, NSDictionaries, and NSStrings using WebScript's @ syntax for creating constant objects.
Buy
Buy.wos contains an example of creating NSArrays, NSDictionaries, and NSStrings using methods. In additon, Buy.wos provides an example of using persistent variables.
CustomerInfo
CustomerInfo.wos contains an example of using the request-response handling entry points willPrepareForRequest:inContext: and willGenerateResponse:inContext:.
Thanks
Thanks.wos contains an example of cleaning up session state using terminateSession.
Footer
Footer.wos contains an example of a reusable component that can be added as a footer to all the pages in an application. It provides examples of two different ways for accessing script variables. It also demonstrates how to format NSCalendarDates.

Interesting Issues From Cyber Wind

Expiring Sessions

Cyber Wind uses setSessionTimeOut: to get rid of all the state for a session if the session hasn't been active for more than 2 minutes. (See the discussion in Application.wos.) You don't have to set a session timeout, but it can enhance performance. By default, all state is kept on the server. For obvious scalability reasons, it's desirable to dispose of state belonging to clients that have been idle for a long time.

Cyber Wind also uses terminateSession to eliminate the state for a session in which the user has completed a "purchase."

WebObjects offers alternatives to storing state on the server. You can store state in pages using the WOStateStorage element. The Pro and Enterprise versions of WebObjects Framework (WOF) demonstrate how to store state on the client using NetScape cookies. The best solution, however, is to eliminate as much state as possible.

The Request-Response Handling Entry Points

Cyber Wind contains examples of four of the five request-response handling entry points: awake, willPrepareForRequest:inContext:, didPrepareForRequest:inContext:, and willGenerateResponse:inContext:.

The Difference Between Global and Session Application Variables

Application.wos defines both global and session variables. The difference between global and session variables is that global variables are shared by all sessions while session variables are not. WOF creates a new instance of a session variable every time a new session begins. A new session begins when the application gets a request for the application URL. For example,

        http://host/cgi-bin/WebObjects/Examples/CyberWind.
    

When subsequent requests are made, WOF automatically restores the instance of the session variable that belongs to the requesting session.

The Lifetime of a WOWebScriptComponentController

A WOWebScriptComponentController is transient. It's created when an application receives a request for its corresponding page, and it goes away when the application returns a response. Later, when a user performs an action from the page, the WOWebScriptComponentController is recreated to handle the user's action.

Whenever a WOWebScriptComponentController is created or recreated, the awake method is called (if it is implemented). For example, when a user opens the URL for the Cyber Wind program, the Cyber Wind application receives a request for the Main page. A WOWebScriptComponentController is created and initialized with this file. Upon its initialization, the awake method is invoked.

WOF creates a response containing the dynamically generated HTML for the Main page and then destroys the Main's WOWebScriptComponentController. Before destroying the component controller, WOF stores any variables that are declared persistent. (Main doesn't have any persistent variables, so no state is preserved in this case.)

When the user clicks in the Main page of CyberWind, on either the "See surfshop info" or "Buy a new sailboard" hyperlink, Cyber Wind receives a new request from the Main page. When Cyber Wind gets the request, it recreates the WOWebScriptComponentController for Main, so the Main component controller can handle the user's action. When it's recreated, awake is called again.

Choosing a Persistence Strategy for Component Variables

The awake method is a good place to create variables because it's called exactly once for every transaction (for requesting the page, and for processing an action originating in the page). For an example of using awake this way, see Surfshops.wos.

As an alternative, you can declare persistent variables. That way, WOF will automatically save and restore them for you. Use persistent variables sparingly, though. If the application serves a large number of clients and generates a lot of persistent state storage, the application will consume an inordinate amount of resources, and performance will degrade.

Sometimes you have to use persistent variables. For instance, in Buy.wos the variable selectedSailboards must be persistent. Since the variable is initialized with user-specified values, reinitialization isn't possible unless the user's choices are stored between transactions.

Reusable Footer with Connection Information.

The Footer component is a good example of gathering and displaying simple connection statistics. To support the Footer component, Application.wos provides global and session variables. These variables are updated in: