Interchange form actions

Table of contents
1. Introduction
2. First level actions
2.1. Calling an action using the page name
2.2. Calling an action using mv_action
3. Second level actions
3.1. back
3.2. cancel
3.3. refresh
3.4. return
3.5. search
3.6. set
3.7. submit

Introduction

Interchange form processing is based upon an action (first level) and a todo (second level). This can be gated with the mv_form_profile variable to determine which action should be called, and which form values should be set, based upon whatever checks and preconditions are required by your application.

First level actions

First level actions can be called by page name, or by setting the mv_action variable in a form.

Predefined first level actions are as follows:

Name	Description
process	Perform one of the second level actions.
search	Form-based search.
scan	Path-based search.
order	Order an item.

Additional actions can be defined using the ActionMap configuration directive.

The "process" action has a second level, called with mv_todo or mv_doit The mv_todo takes preference over mv_doit, which can be used to set a default if no mv_todo is specified.

As mentioned above, the first level action can be specified with a page name or via the mv_action variable. For example:

Calling an action using the page name

Calling the "search" page will request the "search" action and calling the "process" page will request the process action etc.

For example:

The above causes a simple text search of the DefaultTables table(s).

The [process] tag is often seen in Interchange forms. The above example can be rewritten as follows:

Calling an action using mv_action

Setting the mv_action form variable causes the page name to be ignored as the action source. The above examples can use this as a synonym:

The page name will be used to set mv_nextpage, if it is not otherwise defined. If mv_nextpage is present in the <form> then it will be ignored.

Second level actions

Second level form processing actions are only available if the first level action is set to "process", and can be selected using either mv_todo or mv_doit.

If the first level action is "process" then the following second level todo actions will be available:

Name	Description
back	Go to mv_nextpage, and don't update variables.
cancel	Erase the user's session.
go	Go to mv_nextpage (same as return).
refresh	Go to the mv_orderpage or mv_nextpage and check for ordered items.
return	Go to mv_nextpage (update variables).
search	Trigger a search.
set	Update a table in the database.
submit	Submit a form for validation (and possibly a final order).

Additional second level form actions can be defined using the FormAction configuration directive.

To specify a default second level form action, set mv_doit as a "hidden" variable, as follows:

In the above, if the mv_todo value is not found as an action, then the refresh action, specified using mv_doit, will be used instead.

The pre-defined second-level actions are as follows:

back

Goes to the page in mv_nextpage. No user variable update.

cancel

All user information is erased, and the shopping cart is emptied. The user is then sent to the mv_nextpage. The "canceled" SpecialPage is used if no mv_nextpage is specified.

refresh

Checks for newly-ordered items in mv_order_item, (also looking for on-the-fly items, if defined), then updates the shopping cart with any changed quantities or options. Finally updates the user variables and returns to the page defined in mv_orderpage or mv_nextpage (in that order of preference).

return

Updates the user variables and returns to the page defined in mv_nextpage.

search

The shopping cart and user variables are updated, then the form variables are interpreted and the search specification contained therein is dispatched to the search engine. Results are returned on the defined search page, as set using the mv_search_page variable.

set

Update a table in the database.

submit

Submits the form for order processing. If no order profile is defined with the mv_order_profile variable then the order will be checked to see if the current cart contains any items. If so then the order will be submitted for finalisation.

If an order profile is defined then the form will be checked against the defined rules and only submitted if the profile's "&final" pragma is set true.