1. Introduction
    1. About Agavi
    2. MVC in Agavi
    3. Overview of Agavi
    4. Overview of Application Execution Flow
    5. A Word About Actions
    6. Application filesystem layout
    7. Overview of application configuration
  2. Setting Up The Initial Application
    1. Installing Agavi
    2. Creating an Agavi Project
    3. Finishing The Setup
    4. Finishing The Basic Setup
    5. Installing a New Copy of Your Application
  3. Adding First Code
    1. Creating A New module
    2. Creating A New Action
    3. Tying Things Together — An Introduction To Routing
    4. Fixing The Bloggie Routing
    5. Accessing Request Parameters and Validation Basics
    6. Handling Validation Errors
  4. Putting The M in MVC
    1. Creating A New Model
    2. Adapting The Actions and Views
    3. Custom Validators
  5. Polishing It Up
    1. Layers and Layouts
    2. Applying Our Layout
    3. What Are Slots?
    4. Adding The Post's Title To The URL
    5. Routing Callbacks
    6. Using Callbacks for the Title in URLs
  6. Connecting to a database
    1. The Database Manager
  7. Handling Output Variants
    1. Output Types
    2. Exception Templates
    3. Generating an RSS Feed
  8. Form Processing
    1. Adding a Post
    2. Editing a Post
    3. The Form Population Filter (FPF)
  9. Creating a User Authentication System
  10. Adding To The Master Template

Overview of Application Execution Flow

Agavi handles user requests and organizes the execution flow of an application. This chapter gives a brief overview what happens when a web request lands in the Agavi dispatcher. Understanding Agavi architecture is key to write efficient and durable applications.

Request Dispatching

The first stage of execution is called the dispatch stage. The dispatcher script - typically index.php for web applications — boots the framework and commands the Agavi controller to dispatch the web request.

The controller looks up the request using the routing map to find out the identity of the action that should be executed. If no route matches, or the specified action can not be found, a substitute system action is executed instead to indicate an error condition.

When the requested action is discovered, the controller creates a special envelope object, called the execution container. Actions and views execute inside the execution container which isolates them from the outside world and provides them with shared space.

As soon as the initial action is loaded into the execution container, the controller creates the global filter chain (FC) which governs the execution of actions. The execution container is fed into the filter chain. One of the filters in the chain executes the container, and the resulting response is returned to the outside world — most often as an HTTP response.

Tip: Filter chains are configurable pipelines which execute filters. A filter is a plugin-like class that accepts an execution container and does something with it. Filters are nested, which means they can execute before or after other (inner) filters.

Running the Execution Container

Note: An action always selects a view that is destined to compose the response. A combination of such action and view is called an "action-view chain", it has nothing to do with filter chains.

The execution container encapsulates an action-view chain. It sets up the environment, runs both the action and one of its views and then invokes the rendering mechanism to apply templates if needed. The output of the view is collected and returned.

Internally, actions/views are executed inside another filter chain, which is called the "actions" filter chain. Unlike the global FC which is executed once per request, the actions FC is executed once for every action. Thus, filters of the "actions" FC would be applied to every action ever called, and the ones in the "global" chain will be applied globally.

The action itself is invoked through the Execution Filter, which is the last filter in the "actions" chain. Output caching is performed at this stage.

Note: Several other filters may be involved in the action chain: for example, the security filter would refuse to execute an action that the user isn't authorized to execute.

If the action requests input validation, the request data is checked by Agavi according to the rules laid out by developers. If the data does not conform to the specified constraints, execution of the action is aborted and error handling procedure begins instead.

After the validation and caching checks are finished, the action will be executed. This is where your code comes into play: the action interacts with models and tells Agavi which view should be executed.

The appointed view's respectable executeXXX() method is called. The view sets up the configuration for output rendering and prepares any data needed by the rendering mechanism, again querying models if needed.

After the view has finished executing, the rendering mechanism executes the rendering procedure. This procedure may involve calling other actions, which in turn get their own Execution Containers and action filter chains. Alternatively, a view may choose to skip the rendering step and compose the response itself (for example, encoding API response into JSON would not require any sort of external templates.)

The resulting output is collected and sent back to the client.