When a form is submitted with Makumba, the following things happen:

* Makumba constructs (or loads from cache) a so-called form responder, that will take care of responding to the submission to the form.
* the implicit validation takes place, using the field attributes of the fields used in the form
* the explicit validation takes place, defined using validation rules
* additional, form-specific business logic handler methods are executed
* the action-specific changes are written to the database (depending on new, edit, delete)
* the response message is displayed on the action page

If at any point of this process, a validation constraint fails or a [LogicException|api:LogicException] is thrown by the business logic, the submission stops. If a validation constraint fails, Makumba can deal with this in several ways:

* forward to the action page and display the error using [mak:response|ResponseTag]: in this case, the action page is displayed, and if used, the error message is displayed
* reload the form and display errors using [mak:response|ResponseTag]: in this case, the form page is displayed, and all errors are displayed together using the [mak:response|ResponseTag] tag
* reload the form and display errors using annotations: in this case, the form page is displayed and errors are displayed next to the fields containing errors. Validation errors that span over more than one field are displayed before the form
* validate the form as the user fills it in using live validation: in this case, the validity of the data entered by the user is checked on the fly and errors displayed next to the field when it is left.

Business logic exceptions are displayed using the [mak:response|ResponseTag] tag.

If everything goes fine, the request is forwarded to the action page, where a message might be displayed (see the message attribute).


%%(display:none;)[Category Documentation]%%
