Table of Contents Previous Section
Component Actions vs. Direct Actions
Figure 28 shows the sequence of events in processing a component action request and compares it to the sequence of events for processing the direct action. Note that in both component actions and direct actions, the bulk of the time is spent in the generate response phase, in which the component performs appendToResponse:inContext: and sends each of its dynamic elements appendToResponse:inContext:. This step is the same in component actions and direct actions.
Figure 28. Comparison of Component Action and Direct Action request processing.
- Component actions require state, primarily so that they can determine which component should perform the action.
- Component actions extract input values from the request without requiring you to write any code to do so.
- Component actions have dynamic, unpredictable URLs because the URL contains the session ID and context ID, which are unique to each session.
Direct actions are stateless actions. They do not require any state to be preserved between requests. For this reason, direct actions do not create session objects by default. WODirectAction defines a method that does create a session, so direct actions can create a session and store state if necessary.
Direct actions do not automatically extract input values from the request. If there are input values, the HTML element places them in the HTTP request, and the action method must explicitly request them from the WORequest object.
Direct actions have static, predictable URLs. Regardless of which session is performing the action, the URL for the action always refers to a specific action-one that was determined when the current page was generated (not when the request is handled).
Because their URLs are static and because they do not require state, direct action requests can be bookmarked by your application's users and can be revisited at any time.
Table of Contents Next Section