Created by: null on 10-11-2005 03:28:04 AM Hi, Am wanting to understand a real scenario under which a Dymnamic Element Configuration would be used - a specific example I can talk about during a training session.
On reading the Audium Knowledge Base, item titled "Dynamic Element Configurations", it gives an example for time-of-day. Can't this be as easily achieved using a purpose-built Configurable Voice Element?
Or is it that a Configurable Voice Element MUST produce VoiceXML, and that the use of a Dynamic Element Configuration allows a standard audio element to be changed, thereby preventing the need to know any VoiceXML?
Is there another scenario under wich a Dynamic Element Config is appropriate: where the developer does not have access to the source of an existing element that might do most of what is needed, but needs some variation?
And is there another possible scenario where an Custom Element exists, and whilst it might be configurable, is capable of being used in any application, but needs some variation based on some run-time information. Perhaps an example is where a Credit Card collecting element exists, with Studio configuration for Bankcard, Master, Visa, Amex as options, yet only at runtime is it known which of those should really be avaailable to the caller?
Perhaps I'm answering my own question. But any real, specific example, which can't be practically achieved by a configurable element would be much appreciated.
Thanks in advance. Regards, Strafford
Subject: RE: Seeking a real-world example of Dynamic Element Config Replied by: Vance Vagell on 15-11-2005 03:57:12 PM Hi Strafford,
First, here are some key points:
Much of what can be done with a dynamic configuration class can also be done with substitution, and far easier
Anything that can be done with a dynamic configuration class can also be done with a custom configurable element
Because of these two points, we have begun to de-emphasize dynamic configuration classes. Dynamic configuration classes were added before substitution was usable in as many places as it is now; it was the only means by which certain settings could be changed at runtime. That said, dynamic configuration classes still have their uses. As you mentioned, their primary use is to add features to an existing element without having to use the VFCs or rewrite the core functionality. An example of this would be a dynamic config class for a Form element that changes the URI of the grammar the Form uses at runtime, here is a sample scenario:
The app asks the user for their state
The app dynamically configures a Form to use an external grammar (via URI) of cities in the chosen state
The app asks the user for their city (and uses the new grammar)
This can also be done with a custom voice element that changes its active grammar as needed, but that requires extra programming effort. This can also be done with substitution in the grammar URI setting, but the grammar to use would still need to be chosen by an Action (or other) element. So in this case, the best solution in a dynamic configuration class.
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:
