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

Putting The M in MVC

So far, we created two static pages that feed on data that's held in the view. That's not what MVC is about. Instead we should put the logic of where to obtain the data in our business model and the view should only be concerned with how to display it. It's about time we change that. In this chapter, we'll move the code to retrieve and handle posts into separate classes and start to created our business model.

Models in agavi are just plain classes. While they usually extend AgaviModel in one way or another, this is not a requirement. You can create your business model completely independent of Agavi and then use it in your application. However, you'll loose a couple of benefits that the framework has to offer, so consider carefully whether you'll ever have the need to use your models in a context without using Agavi. Unless you have a very specific reason we recommend that your models extend the applications BaseModel which has been created by the project wizard.

We'll be using two models to handle our business logic. First a "Post" model that represents a single post and a PostManager that handles all storage and retrieval operations for the post. That way we can easily exchange the PostManager for a mock implementation in testing contexts. That way it's possible to have tests run even without a database dependency.

The result of this chapter is available at http://www.agavi.org/guide/stages/stage3.tgz