Notes:
The first two elements define the
TaskId which is a dynamically defined
enumerated type. PLACE_ORDER is the name, and 506 is an internal
numeric id. Both values are guaranteed to be unique.
Every task operates with a realm. The GENERAL realm has no owner,
and is considered the default realm. The PLACE_ORDER task operates
in a realm of type USER. Tasks are partitioned by their type,
because the operations, say, for a club are a distinct set from
those for a user. The type is validated to ensure the basic
context required to execute the task makes sense.
The name of the realm (RealmOwner.name) is extracted from the URL
or email address for the current request. The name identifies
the RealmOwner instance (row) uniquely.
The authenticated user has a user_id, which coupled with the realm_id,
identifes a role, and then the permission set for that user within
the realm. The user must have the DATA_WRITE and DATA_READ permissions
to execute the PLACE_ORDER task.
The task is authorized to execute if the permissions of the task are
a subset of the user's role's permissions for the realm. If not,
a FORBIDDEN exception is thrown, which can result in a login window
being shown or simply a FORBIDDEN return result to the user.
The next rows consist of a list of executable items. In this example,
the OrderForm model is executed followed by the place-order view.
A task must produce an output (Bivio::Agent::Reply) or redirect to
another task which does. The normal case is for a view to be the
last item to be executed, which renders the results of the business
logic which proceeds it.
The last element in this example identifies the next task to be executed
after the form data is processed and committed (usually occurs when an OK
button being pressed in the browser). There are many other attributes
which identify the flow, such as, cancel - task to go to when the user
clicks Cancel, FORBIDDEN - task to go to when a FORBIDDEN exception is
thrown, and so on.