Cisco Cisco Unified Customer Voice Portal 11.0(1) Developer's Guide
C
HAPTER
9:
C
ONFIGURABLE
E
LEMENTS
V
OICE
XML
P
ROGRAMMING
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
45
creating and editing a configuration object, a custom element uses these classes basically to read
their information. There is little reason to edit the configuration classes within a custom element
as the configuration object applies only to that particular use of the element (revisiting the
element will provide it with a new configuration).
their information. There is little reason to edit the configuration classes within a custom element
as the configuration object applies only to that particular use of the element (revisiting the
element will provide it with a new configuration).
Action Elements
A configurable action element extends the abstract Java class
ActionElementBase
found in the
com.audium.server.voiceElement
package. This class has default implementations for the
abstract configuration methods inherited from the
ElementBase
class. The default
implementation sets an empty configuration (null name, folder name, description, element data,
settings, and one exit state named “done”). This was done because this same base class is
extended to create standard action elements as well as configurable action elements. What makes
a configurable action element different is the fact that it defines a specific configuration, so the
custom action element must re-implement all the configuration methods rather than relying on
the default implementation. Some of the default implementations, though, may be appropriate
even for a custom action element. For example, the default implementation of the
settings, and one exit state named “done”). This was done because this same base class is
extended to create standard action elements as well as configurable action elements. What makes
a configurable action element different is the fact that it defines a specific configuration, so the
custom action element must re-implement all the configuration methods rather than relying on
the default implementation. Some of the default implementations, though, may be appropriate
even for a custom action element. For example, the default implementation of the
getExitStates
method returns a single exit state named “done”, which applies to all action
elements and so a custom action element need not implement this method.
The execution method,
doAction()
, receives an instance of the API class
ActionElementData
.
This class belongs to the Session API and is used to access session information (See Chapter 3:
Session API for more on this API). In addition to providing access to session information, this
API class is also used to return the action element configuration that drives the functionality of
the element. The
Session API for more on this API). In addition to providing access to session information, this
API class is also used to return the action element configuration that drives the functionality of
the element. The
getActionElementConfig()
method in
ActionElementData
returns an
ActionElementConfig
object. The VoiceXML Server takes care of obtaining the appropriate
configuration and returning it in this method, whether or not the configuration is dynamic. The
element need not worry about where the configuration came from.
element need not worry about where the configuration came from.
ActionElementConfig
is almost a direct extension of the base
ElementConfig
class. It is kept
separate for future differentiation.
Decision Elements
A configurable decision element extends the abstract Java class
DecisionElementBase
found in
the
com.audium.server.voiceElement
package. This class has default implementations of the
abstract configuration methods inherited from the
ElementBase
class. The default
implementation sets an empty configuration (null name, folder name, description, element data,
settings, and exit states). This was done because this same base class is extended to create
generic decision elements as well. What makes a configurable decision element different is the
fact that it defines a specific configuration, so the custom decision element must re-implement all
the configuration methods rather than relying on the default implementation. Some of the default
implementations, though, may be appropriate even for a custom decision element. For example,
if the decision element creates no element data, the custom decision element need not implement
the
settings, and exit states). This was done because this same base class is extended to create
generic decision elements as well. What makes a configurable decision element different is the
fact that it defines a specific configuration, so the custom decision element must re-implement all
the configuration methods rather than relying on the default implementation. Some of the default
implementations, though, may be appropriate even for a custom decision element. For example,
if the decision element creates no element data, the custom decision element need not implement
the
getElementData
method as the default implementation is sufficient.