SproutCMS

class MultiStepFormController

Supports multistep forms

• File: /sprout/Controllers/MultiStepFormController.php
• Namespace: Sprout\Controllers
• Extends: Controller
• This class is abstract

Variables

Should this controller log add/edit/delete actions?

Appendage to route, where user is redirected after save on final step

Page title to be displayed on form steps

Route to form, relative to site root

Key for partitioning session data associated with this form, i.e. $_SESSION[$this->session_key]

Steps and functions/views used to implement them
Keys are step numbers, values are function (and matching view) names
e.g. [1 => 'intro', 2 => 'personal_details']

Table into which data will be saved at the final step

Directory in which views are stored, without trailing slash

Functions

public __call (from BaseController)

Handles methods that do not exist.

public __construct (from BaseController)

public _run (from BaseController)

The router/kohana will invoke this method to invoke an action.

If you please, you may wrap this method to create before/after hooks.

protected autoSetEmptyParam (from Controller)

Auto-set the "empty" param for fields with foreign keys to be NULL

This greatly reduces the number of foreign-key constraints hit in day-to-day use,
especially with file fields.

protected buildUrl

Builds a URL to the form at a particular step

protected checkStep

Check the user has access to a step

public complete

Display the thanks message after the process has been completed

protected deleteRecord (from Controller)

Deletes a record, and logs the deletion
This should be used by all _deleteSave methods
Starts a transaction and commits it if not already in a transaction when called

protected firstStep

Gets the number (should be 0 or 1) of first step of the process

protected form

The method used to drive the forms at each step
This should be called by the entry function of the subclass controller

protected generateFormView (from Controller)

Generates a form view from a JSON config file

public getCssClassName (from BaseController)

Return the class name for this controller, expressed in CSS style, i.e. with dashes

Example: When called from BlogPostController --> 'blog-post-controller'

public getModulePath (from BaseController)

Gets the relative path to the module the controller lives in, or sprout itself

protected getSession

Instantiate the session and make sure the session key is useable

protected jsonExtraValidate (from Controller)

Do any additional validation prior to saving the record

protected loadEditJson (from Controller)

Loads a JSON config file for an automated edit-type form for this controller

protected loadFormJson (from Controller)

Loads a config file for a JsonForm associated with this controller

protected loadRecord (from Controller)

Fetches the pre-update record from the database.
Used by the action log system, and disabled if the action log system has been turned off

protected logAction (from Controller)

Stores a history item in the database, recording an add (i.e. insert), edit, or delete.
Should be called AFTER the action has been made.
N.B. This is a low-level method; the friendlier wrapper methods are preferred;
e.g. Controller::logAdd, Controller::logEdit

protected logAdd (from Controller)

Logs an add action. This is a wrapper for Controller::logAction

protected logAddCategory (from Controller)

Logs the adding of a record to a category. This is a wrapper for Controller::logAction

protected logDelete (from Controller)

Logs a delete action. This is a wrapper for Controller::logAction

protected logDeleteCategory (from Controller)

Logs the removal of a record from a category. This is a wrapper for Controller::logAction

protected logEdit (from Controller)

Logs an edit action. This is a wrapper for Controller::logAction

protected replaceSet (from Controller)

Inserts records which are in $new_records, but are not in the specified table
Deletes records which are in the specified table, but not in $new_records
Updates records which are in both

Matching is done on the 'id' field, as a result the $new_records arrays MUST contain an id field.

protected save

Do any final preparation / data massaging; then call saveData and finally redirect.
This should generally be overridden.

protected saveData

Save the data, e.g. into a database, after successful validation at the
final step

protected saveJsonData (from Controller)

Automatically saves the data associated with a submission on a JSON-generated form

protected submit

The method used to drive the form submissions at each step
This should be called by the submit function of the subclass controller

protected validate