[Jakarta-taglibs Wiki] Update of "ReusableDialogComponents/Tutorials/RDCTemplate" by RahulAkolkar

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-taglibs Wiki" for change notification.

The following page has been changed by RahulAkolkar:
http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutorials/RDCTemplate

New page:
''Prototypes, and quick too''

----

The RDC template provides a mechanism for rapid prototyping of components in the RDC framework, aimed at further cutting component development time. Template instances are also useful for authoring one-off application specific RDCs, giving the application development team the option to clearly define speech interaction components without writing application specific RDC tags (that being a design decision).

The RDC template provides barebone support for executing a component in the RDC framework. By instantiating the template appropriately, it can be made to function as any atomic component. Templates allow for rapid prototyping since you don't need to author a tag file or regenerate the TLD. Also, the development of the instances is completely detached from the RDC codebase.

Templates have three required attributes, an id, a grammar and a prompt configuration file. Thus, the simplest instances look like this:
{{{
    <rdc:template id="myRDC" grammar="myRDC-grammar.grxml" 
     config="myRDC-config.xml" />
}}}

Think of the above as a souped up VoiceXML 2.0 <field>, with the given grammar and prompts. It is more powerful that a vanilla field because it is a component allowing control over confirmation, echo, confidence thresholds, n-best results and initialization of its value via the respective tag attributes. 

The grammar attribute may be a {{{java.lang.String}}}, treated as a URI, an {{{org.apache.taglibs.rdc.core.Grammar}}} object or array of any combination of {{{String}}} and {{{Grammar}}} objects. The config attribute expects an RDC prompt configuration (XML) file.

Going one step further, the instance author can define the private data model, which can carry out any custom canonicalization, validation etc. The private data model can be passed in to the template instance like so:
{{{
    <rdc:template id="myRDC" grammar="myRDC-grammar.grxml" 
     config="myRDC-config.xml" bean="my.components.myRDC" />
}}}
The data model must subclass {{{org.apache.taglibs.rdc.core.RDCTemplate}}}.

Moving along, constraints may be passed in to the template instance via a constraints attribute, which is a name -> value map.
{{{
    <rdc:template id="myRDC" grammar="myRDC-grammar.grxml" 
     config="myRDC-config.xml" bean="my.components.myRDC" 
     constraints="${myRDC_constraints}" />
}}}
In addition, templates support dynamic tag attributes, so constraints may also be passed in as a set of attributes.

The instance author may also pass in some data that is template instance and data model specific. This data can be used to generate prompts etc. For example, the select1 RDC needs the set of options.
{{{
    <rdc:template id="myRDC" grammar="myRDC-grammar.grxml" 
     config="myRDC-config.xml" bean="my.components.myRDC" 
     constraints="${myRDC_constraints}" data="${myRDC_data}" />
}}}

Finally, the default RDC FSM may be overridden by using the fsmFragment attribute:
{{{
    <rdc:template id="myRDC" grammar="myRDC-grammar.grxml" 
     config="myRDC-config.xml" bean="my.components.myRDC" 
     constraints="${myRDC_constraints}" data="${myRDC_data}" 
     fsmFragment="myRDC_fsm.jsp" />
}}}

All attributes, except id, can be determined at run time.

---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org