Created by: null on 24-05-2006 04:06:27 AM I'd like to write a class to dynamically configure Voice Elements. I have considered the XML API interface, but see less work in the following approach:
1. Write a class that implements the VoiceElementInterface interface,
2. Within the getConfig() method, to read the configuration from an XML file, and
3. Use the VoiceElementConfig(dom) constructor to parse the XML and populate the Voice Element Config object.
My questions concerns using this constructor. The JavaDoc warns "This method is used by the Audium Server internally and should not be called by the developer."
I'd reeeeealy like to use this method. Can you explain the reasons for this warning.
Thanks Mark
Subject: RE: VoiceElementConfig constructors Replied by: Vance Vagell on 31-05-2006 08:53:03 PM Hi Mark,
Please note that we offer an Audium Java API approach called Dynamic Configuration, which can be used to change the configuration of an element when it is visited at runtime. There is no need to use internal-only constructors or methods to accomplish this. Within a Dynamic Configuration class, you can perform any procedure you would like to find the desired configuration values (e.g. such as parsing XML, as you noted).
For an introduction to Dynamic Configuration classes, please refer to the following Audium Knowledge Base article:
Additionally, the following tutorial application includes a Dynamic Configuration class, with fully commented source code and step-by-step instructions:
You may also wish to download our Audium Java API code templates, which can be used as a basis for your custom components. Finally, the Programmer Guide provides a detailed look into creating all custom components, including Dynamic Configuration classes.
Regards, Vance
Subject: RE: VoiceElementConfig constructors Replied by: null on 01-06-2006 12:13:00 AM Vance,
Thanks for your reply.
It is my intention to use Dynamic Configuration as you have suggested. I plan to avoid hard coding the names of the audio files and TTS to be played, and instead make it configurable. I wish to store the information in an XML file and this is where I would like to reuse what Audium already provides, namely:
The VoiceElementConfiguration DTD to define the structure of the XML configuration file, and
The VoiceElementConfiguration(dom) constructor to initialise a configuration object from the XML file.
The only thing I can see preventing me from this reuse is the warning in the documentation. Can you see any other perils? And can you tell me anything about the reason for the warning?
Thanks, Mark
Subject: RE: VoiceElementConfig constructors Replied by: Vance Vagell on 01-06-2006 07:20:17 PM Hi Mark,
Internal methods (as indicated in the Audium Java API Javadocs) are intended for use only by Audium code, and should not be used by developers in their custom code. Please note that internal methods are subject to change or removal at any time, including service (e.g. dot-dot) releases. On the other hand, we make every effort to ensure that the publicly available Java API methods are consistent from version to version. It is highly recommend that you use only these methods in your custom code.
That said, you can still achieve what you are trying to do. For example, you could create a DTD that describes the data that your custom element will need, and then parse XML based on your custom DTD from within your custom element as needed.
Should you have further questions, please let us know and we would be glad to help.
Regards, Vance
Subject: RE: VoiceElementConfig constructors Replied by: null on 14-06-2006 09:45:32 PM I've used the following technique to handle a situation where the caller is attempting to transfer and I need to present a customized message based on the status of the transfer destination (closed, holiday, emergency, stall, etc.)
I define all the audio messages in the audio configuration pane then, at run time, eliminate the ones I don't need keeping only the ones that apply. That way nothing is hard coded except the natural keys that match the conditions that requires each message.
I originally tried the using the item name but either didn't do it right or it wasn't accessible in the version I'm using. I ended up just putting the associated state value in the TTS transcript then eliminating the transcript when updating the configuration at run time.
Subject: RE: VoiceElementConfig constructors Replied by: Michael Bochynski on 20-06-2006 09:21:52 PM Hi Kenneth,
The situation you described is a perfect scenario for a dynamic configuration class. You can either define all your audio prompts and remove unwanted ones or have no prompts at all and generate the one you need in your dynamic configuration class.
Would this approach work for you? Have you tried implementing it? If so, and you had errors, what kind of errors?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
