ccxml elements

CCXML Voxeo 1.0 Development Guide

This documentation is for CCXML 1.0-Voxeo, which has been superceded by CCXML 1.0-W3C. The CCXML-Voxeo platform is not being updated any longer. The CCXML 1.0-W3C version, however, has many new features and is actively being enhanced. If you're writing a new CCXML application, you should use CCXML 1.0-W3C. Click here for the CCXML 1.0-W3C documentation.

<fetch> element

The <fetch> element, used in conjunction with the <goto> element, is used to transfer execution to a separate CCXML document. The <fetch> element allows for a pre-emptive fetch and parse of the target document to ensure that it is well formed and can execute before the <goto> ever executes. Execution returns from this element immediately, and the CCXML interpreter is free to continue while the execution context parses and prepares the target document for execution. If the target is fetchable, and parseable, an event 'ccxml.fetch.done' is sent, and the <goto> may now execute normally. However, if there is a problem with the target page, the event of 'error.fetch' is thrown to the invoking document.

usage

<fetch fetchid="(variable name)" method="(GET|POST)" namelist="STRING" next="(ECMAScript Expression)" synch="(variable name)">

attributes

fetchid	Data Type: (variable name)	Default: Optional
	The fetchid attribute is an ECMAScript expression which receives an internally generated unique string identifier to be associated with the completion event. This identifier can be tested by the fetch completion event handler to distinguish among several outstanding fetch requests. Every fetch request will receive a unique fetch ID, even requests for the same document.
method	Data Type: (GET\|POST)	Default: Optional (GET)
	The method attribute specifies the HTTP method to use when sending the request. If unspecified, then the value of ‘GET’, (default) is assumed, unless the submission of multipart/form-data is encountered, in which case the implied method will be ‘POST’.
namelist	Data Type: STRING	Default: none - attribute is optional
	The namelist attribute denotes the space-separated list of variable names to be sent along with the fetch. The variables will then be available as a variable/value pair in the resultant URI querystring that is sent to the server.
next	Data Type: (ECMAScript Expression)	Default: none - attribute is required
	This attribute simply indicates the URI of the XML document to be fetched.
synch	Data Type: (variable name)	Default: none - attribute is optional
	The synch attribute is an ECMAScript left-hand-side expression that is set to the fetch completion event. The specification of this attribute in a fetch element implies a blocking fetch, which will be executed synchronously. If this attribute is not specified, then the fetch is asynchronous by default.

parents

none

children

none

code samples

<Fetch next-method-fetchid-namelist> sample

<?xml version="1.0" encoding="UTF-8" ?>
<ccxml version="1.0">

<var name="state0" expr="'init'"/>
<var name="myVar1" expr="'foo1'"/>
<var name="myVar2" expr="'foo2'"/>
<var name="fetch1" expr="'some_fetch_id'"/>
<eventhandler statevariable="state0">


<transition state="'init'" event="ccxml.loaded" name="evt">
<assign name="state0" expr="'fetching'"/>
<log expr="'*** FETCH1 =' + fetch1 + '***'"/>
<fetch next="'http://myserver.com/mycool.xml'"
method="'get'"
fetchid="fetch1"
namelist="myVar1 myVar2"/>
</transition>

<transition state="'fetching'" event="ccxml.fetch.done" name="evt">
<goto fetchid="evt.fetchid"/>
</transition>

<transition state="'fetching'" event="error.fetch" name="evt">
<log expr="'*** FETCH ERROR [' + evt.error + '] ***'"/>
<exit/>
</transition>


<transition event="error.*" name="evt">
<log expr="'*** ERROR HAS OCCURED [' + evt.error + '] ***'"/>
<exit/>
</transition>

</eventhandler>
</ccxml>

additional links

W3C Specification

ANNOTATIONS: EXISTING POSTS

moshe

6/15/2004 8:32 AM (EDT)

Although the documentation states that if no fetchid is given, you can get the value from the event, in practice this attribute is required -- if you don't provide a fetchid, the parser will reject the script.

awirtz

8/26/2005 5:21 PM (EDT)

method is not a STRING, but rather an ECMAScript expression.

fetchid is not directly a variable name, but rather an ECMAScript expression that is evaluated to a string which specifies the variable name...

*bangs head against desk*

I remain happily ignorant of the details surrounding synch...

MattHenry

8/26/2005 7:02 PM (EDT)

Hiya Aaron,

You are indeed correct on this; I have updated the docs to reflect accurate information on this attribute.

~Matt

bpcamac

2/1/2006 8:31 PM (EST)

If I understand the spec correctly, when the goto statement has finished executing the interpreter will then be running the fetched document with its associated event handler, replacing the document which issued the goto and waiting for events to process.

If so, how can the fetched document begin executing an event as soon as its loaded? Can the event ccxml.loaded be relied upon for this? The alternative approach of placing a send statement after the goto wouldn't be guaranteed to execute (as I understand it) since the goto statement is replacing the current document (program).

Michael.Book

2/2/2006 1:48 PM (EST)

Hi bpcamac,

The 'ccxml.loaded' event is fired when a given CCXML document is parsed and ready to go (initialized). It doesn't matter if said document is the session's initial "start" document or a subsequent document initialized as a result of a <goto>. So, you can indeed rely on this event when using <fetch>/<goto>.

**NOTE: The 'ccxml.loaded' event is thrown in the new document when the doc is successfully initialized (i.e. via <goto>), not when it is successfully fetched.

Now, you mentioned using a <send> after a <goto>...

The key word here is "after." Yes, if you were to issue a <send> event *after* the <goto>, you would actually have to issue it in the new/target document, as the current/source document execution would have already been terminated. In other words, you will not be able to issue a <goto> followed by a <send> (or anything else for that matter) in the current document, as anything after the <goto> will not be executed.

However... If you were to issue a <send> immediately *before* the <goto> - let's say with a delay of '2seconds' - that event source, already in progress, would be inherited by the new, target document. In other words, about two seconds (given the aforementioned example) after the target document takes control, you will see the event issued by your <send> in the old, source document.

I hope this helps to explain...

Have Fun,

~ Michael