|
|
The new
release of zeroCode, V3R0 (May 2001),
supports the construction and use of a
new kind of element – an “action
sequence”. An action sequence is a set
of actions (or action units) that will
be executed in a specific sequence,
triggered by a UDM. An action unit
can be anything that a zeroCode UDM node
supports – retrieval, addition,
modification and/or deletion of data
from/in a dataport and the expression
evaluations that a normal UDM supports.
The action sequence itself can be
triggered as the “action hook” for a
UDM, to be executed at any one of four
points in a UDM’s execution:
|
|
|
1. Before it is retrieved for data display.
|
2. After data is retrieved but before it is sent to the user's browser for display.
|
|
3. After the user submits the UDM to the server for adding/editing data but before those operations are carried out.
|
|
4. After the add/edit operations of the UDM are completed but before control moves on to an optional response UDM.
|
|
|
Being a
part of the zeroCode environment, the action sequence supports all the functions that the UDM does in
integrating designer-written dataports with zeroCode-delivered ones, mathematical and logical expressions,
data dereferencing, etc.
|
|
|
|
Action
Units
|
|
Action
units are specific actions that make up
a full action sequence. They are executed in the order of their appearance in an action sequence, subject to logical branching (described
below). Each action unit is intended either for data manipulation or flow control. There are four kinds of action units for data manipulation:
|
|
A get unit
retrieves data from its data port.
|
|
A put unit adds
(or inserts) data into its data port.
|
|
A modify unit
retrieves data from its data port, modifies
the retrieves data, and updates the content of
the data port with the modified data.
|
|
A delete unit
deletes records from its data port.
|
|
|
|
There are no
restrictions on the kinds of data ports
that can be used in an action sequence.
Thus, for example, you can construct an
action sequence that is invoked when the
customer presses your ‘buy’ button,
and it looks up the database for
someone’s pager number and dials it
(assuming that you have a data port that
can dial a pager).
|
In addition to
the standard actions that the action sequence
supports for data manipulation, the following
flow-control actions make programming-style
sequence construction a reality.
|
|
A terminate
unit, when executed, causes normal termination
of the action sequence.
|
|
An
immediate benefit of action sequences in
existing applications would be to
replace, say, stored procedures with
action sequences. That would make the
procedure more maintainable and
platform-independent, although it may
lose some of the throughput advantages
of a compiled stored procedure.
|
|
An abort unit,
when executed, causes abnormal termination of
the action unit, together with an optional
message that will be returned to the UDM.
|
|
A
conditional unit, which contains a
sequence of condition expressions, each
of which has an associated action
sequence. Each condition expression
returns a Boolean value. When a
conditional unit is executed, it checks
each of its condition expressions, in
the order of their specification. It
recursively executes the action sequence
associated with the first expression
that returns ‘true’ as its value.
Notice that each condition expression
may be associated, recursively, with an
action sequence. This allows action
sequences to be arbitrarily nested.
|
|
|
|
In effect,
the operational sequence of a normal UDM
would be affected as shown in the diagram
below, allowing for very complex
server-side processing to be built with no
programming whatsoever.
|
|
|
|
|
|
