6.2. Controller Logic

There is a standard pattern you can use for controller logic when working with forms and model records. We can see this pattern in the blog demo controller:

 * @var Solar_Sql_Model_Catalog $_model A model catalog instance.
public function actionEdit($id)
    // was an ID specified?
    if (! $id) {
        return $this->_error('ERR_NO_ID_SPECIFIED');

    // fetch one blog article by ID
    $this->item = $this->_model->blogs->fetch($id);

    // did the blog article exist?
    if (! $this->item) {
        return $this->_error('ERR_NO_SUCH_ITEM');

    // did the user click the save button?
    if ($this->_isProcess('save')) {
        // look for $_POST['blog'] in the request,
        // load into the record, and save it.
        $data = $this->_request->post('blog');

    // get form hints from the record
    $this->form = $this->item->newForm();

In narrative language, the pattern is as follows:

  • Make sure we have enough information to fetch a record (e.g., the primary-key value).

  • Attempt the fetch the record, and make sure we actually found it.

  • Check to see if the incoming request is the result of a submit button being pressed via the _isProcess() method. The looks for a process key in the incoming request data and checks its value. (Incidentally, this means you can use one action method to process the results of different kinds of submit buttons: preview, save, cancel, etc.)

  • Retrieve data from the incoming request, load it into the record, and save the record. Note that the record does its own filtering (sanitize and validate). If you like, you can check the result of the save() call; it will be true if the save succeeded, or false if it failed for any reason (e.g., invalid data).

  • Finally, regardless of the status of the record, we ask it to generate a new form object for you via the newForm() method. The form object will reflect the current state of the record, including any invalidation messages for the record properties.

As you can see, the controller does not deal with the form object much at all. Instead, it deals with the record object, then asks the record to generate a form object based on that record's properties, and retains the form object as $form.