Cisco Cisco Customer Voice Portal Downloads Release Note
A
PPENDIX
A:
T
HE
V
OICE
F
OUNDATION
C
LASSES
P
ROGRAMMING
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
R
ELEASE
7.0(1)
96
also versions of the VoiceXML standard. There are separate VFCs for VoiceXML version 1.0
and version 2.0, and the similarities are encapsulated in a common base class. Figure 16-3 shows
this graphically with the
and version 2.0, and the similarities are encapsulated in a common base class. Figure 16-3 shows
this graphically with the
VForm
class. The main
VForm
class extends the
VRoot
class and is itself
extended by
VFormV1
and
VFormV2
, representing VoiceXML 1.0 and 2.0 compliance. Luckily,
there are only a few differences between these versions, so the developer can still do most coding
to the base
to the base
VForm
class. The Gateway Adapters introduce VFCs that extend
VFormV1
or
VFormV2
depending on whether the voice browser it supports is compatible with VoiceXML 1.0 or 2.0.
Figure 16-3
The last concept is that VFC objects are not instantiated using the
new
keyword. A static factory
method named
getNew
is used instead. The reason for this is related to the abstraction of the
voice browser differences. As mentioned previously, a developer need only code using the base
VFC classes. At runtime, the factory methods used to instantiate VFC classes actually returns the
appropriate voice browser-specific VFC (for example,
VFC classes. At runtime, the factory methods used to instantiate VFC classes actually returns the
appropriate voice browser-specific VFC (for example,
VFormFoo
in the example in Figure 16-3).
But since the developer treats the return object as the base VFC, that object is downcasted. This
is the heart of the VFC abstraction design. Since all VFC derivative classes extend their base
VFCs, a developer need only code to the base VFCs and that automatically makes their code
compatible with any voice browser represented by a Gateway Adapter.
is the heart of the VFC abstraction design. Since all VFC derivative classes extend their base
VFCs, a developer need only code to the base VFCs and that automatically makes their code
compatible with any voice browser represented by a Gateway Adapter.
In order to identify which voice browser VFC to return, every factory method must include as its
first argument an instance of
first argument an instance of
VPreference
.
VPreference
, while a VFC class, does not match to
a VoiceXML tag, it is used instead to hold preferences made by the user in Builder for Call
Studio for the application, such as the voice browser and default audio path. By passing this
object to all factory methods, the appropriate object can be returned. The
Studio for the application, such as the voice browser and default audio path. By passing this
object to all factory methods, the appropriate object can be returned. The
VPreference
instance
is automatically created for the developer and made available through the Session API passed to
voice elements, hotevents, or call end classes.
voice elements, hotevents, or call end classes.