The action service is also used to trigger a particular application-specific
action using an ActionLink
component, and its listener.
The action service may also be used by the Form
component to process HTML form submissions.
An action service encodes the page name and component for the request. It also includes an action id.
The request cycle for the action service is more complicated that the direct service.
This sequence assumes that the component is an
ActionLink
, the details of handling form submissions are described in a later section.
The point of the action service is to restore the dynamic state
of the page to how it was when the ActionLink
component rendered the link. Only then is
the listener notified.
The process of restoring the page's dynamic state is called rewinding. Rewinding is used to
go beyond restoring a page's persistent state and actually restore the page's dynamic state.
Whatever state the page was in when the action URL was rendered in the previous request cycle
is restored before the ActionLink
component's listener is invoked.
Use of the action service is convenient, but not always appropriate.
Deeply nested Foreach
components will result in a geometric increase in
processing time to respond to actions (as well as render the HTML).
If the data on the page is not easily accessible then the action service should be avoided.
For example, if the page is generated from a long running database query.
Alternate measures, such as storing the results of the query as persistent page state should be used.
Another alternative is to use the direct service (and DirectLink
component) instead, as
it allows the necessary context to be encoded into the URL, using service
parameters. This can be very useful when the dynamic state of the page is dependant on
expensive or unpredictably changing data (such as a database query).
For example, a product catalog could encode the primary key of the products listed as the service parameters, to create links to a product details page.