Note: This is the YUI 3.x site. Looking for the YUI 2.x site?

YUI 3: The IO Utility

IO Utility

IO is an HTTP utility that enables HTTP requests while maintaining a persistent client UI, for the purpose of data retrieval and content update. IO uses the XMLHttpRequest object for making "same-domain" requests. IO can make "cross-domain" requests, when instructed to do so, using an alternate HTTP transport.

Getting Started

Include Dependencies

To use IO Utility, include the following source files in your web page with the script tag:

NOTE: Cross-domain transactions with IO require the use of io.swf. Make sure this dependency is deployed and accessible by io.js.

A Simple Transaction

io() is the primary method for making an HTTP request. This method accepts two arguments: uri and the configuration object.

  • uri: This parameter specifies the URI for the transaction
  • configuration: This parameter is an object of keys and values of configurations specific to the transaction. Please see: The Configuration Object for more information on all available configuration properties.

YUI.io returns an object with the following members:

  • id: This is the unique identifier of the transaction.
  • abort(): Aborts the specific transaction.
  • isInProgress: A boolean value indicating whether the transaction has completed.

This is an example GET transaction, handling the response at the earliest opportunity.

Using IO

This section describes how to use the IO Utility in further detail. It contains these subsections:

IO Modules

Beginning with PR2, IO's core and supplementary features are split into a base module and sub-modules, to allow greater flexibility in selecting the desired features.

Module Description
io-base This is the IO base class, containing the basic functionality needed for making HTTP requests.
io-xdr This sub-module extends io-base, to add cross-domain request capabilities, using Flash as the transport.
io-form This sub-module extends io-base, to add HTML form serialization, as transaction data.
io-upload-iframe This sub-module extends io-base, to allow file uploads with an HTML form, using an iframe as the transport.
io-queue This sub-module extends io-base, to provide a basic queue interface for IO.

The Configuration Object

This object is the second argument of io(). Its properties define transaction parameters and transaction response handling. The configuration object and all configuration properties are optional. The following table describes all configuration properties used by IO.

Property Description
method (string) Defines the HTTP method for the transaction. If this property is undefined or omitted, the default value is GET.
data (string) Data to be sent with HTTP POST transactions. Data are sent as a string of key-value pairs (e.g., "foo=bar&baz=boo"). Note: Use JSON, instead of a key/value string with cross-domain(Flash transport) or file upload transactions.
headers (object) Specific HTTP headers and values to be sent with the transaction (e.g., { 'Content-Type': 'application/xml; charset=utf-8' } ).
on (object) This object defines the events and event handlers to be used for the transaction. These events fire in addition to the global IO events. Define as many events as desired for the transaction; all events handlers are optional.
  • start: event handler
  • complete: event handler
  • success: event handler
  • failure: event handler
  • end: event handler
NOTE: These events are accessible only to the transaction's subscribers, whereas global IO events are accessible by all subscribers.
context Defines the execution context of the event handler functions for the transaction. If undefined, a default value of window is used.
form (object) This object instructs IO to use the labels and values of the specified HTML form as data.
  • id: This property can be defined as the id(String) of an HTML form or an object reference of the HTML form.
  • useDisabled: When set to true, disabled field values are included as data. The default value is false.
xdr (object) Defines the transport to be used for cross-domain requests (e.g., { use:'flash' } ). The transaction will use the specified transport instead of XMLHttpRequest, when specified in the transaction's configuration object. Currently, the only alternate transport supported is Flash, requiring Flash Player 9 (player 9.0.124 is recommended).
arguments (object)

Object, array, string, or number passed to all registered, transaction event handlers. This value is available as the second argument in the "start" and "end" event handlers; and, it is the third argument in the "complete", "success", and "failure" event handlers.

timeout This value, defined as milliseconds, is a time threshold for the transaction (e.g., { timeout: 2000 } ). When this limit is reached, and the transaction's Complete event has not yet fired, the transaction will be aborted.

This is an example of a configuration object, with a set of properties defined.

The Response Object

When a transaction -- using the XHR object as a transport -- is complete, the response data are passed as an object to the event handler.

Field Description
status The HTTP status code of the transaction.
statusText The HTTP status message.
getResponseHeader(headername) Returns the string value of the specified header label.
getAllResponseHeaders All response HTTP headers are available as a string. Each label-value pair is delimited by "\n".
responseText The response data as a unicode string.
responseXML The response data as an XML document object.

NOTE: Transactions involving file upload or cross-domain requests, using alternate transports, only populate the responseText field. The HTTP status and response headers are either inaccessible or unavailable to these alternate transports.

Events

IO events provide access to data during a transaction's lifecycle. There are two aspects to IO events: global and transaction. Global events are fired by IO for all transactions, and these events are accessible to all event subscribers. Transaction events are created and fired only if their event handlers are defined in the configuration object. Global events are identified by the io:eventname pattern. The following example describes the event subscription syntax for global events:

The following table describes the available IO events:

Event Description
io:start

Fires when a request is made to a resource. The event handler's arguments signature is:

io:complete

Fires after "io:start", when the transaction is complete and response data are available. This is the earliest opportunity to access any response data. The event handler's arguments signature is:

io:success

Fires after the "complete" event, when the response HTTP status resolves to 2xx. The event handler's arguments signature is:

io:failure

Fires after the "complete" event, when the response HTTP status resolves to 4xx. 5xx, or any undefined HTTP status. This event also includes abort and timeout conditions. The event handler's arguments signature is:

io:end

Fires at the conclusion of a transaction, after "success" or "failure" has been determined.. The event handler's arguments signature is:

io:xdrReady Fires when the XDR transport is ready for use. This event only fires once, when the transport initialization is complete.

The following example demonstrates an IO transaction with an event handler subscribed to "io:complete".

Cross-Domain Transactions

By default, IO uses the XMLHttpRequest object as the transport for HTTP transactions. IO can also be instructed to use an alternate transport to make cross-domain, HTTP transactions. Currently, IO can make use of Flash as an alternate transport for such requests. To prepare IO for cross-domain transactions, the transport must be initialized and the file "io.swf" is deployed and accessible. For each transaction, the configuration object's xdr property must be defined with { use: 'flash' } so IO will use the designated transport, instead of using the default transport of XMLHttpRequest.

As io.swf is written in ActionScript 3, Flash Player 9 or better is required (version 9.0.124 or better is recommended). Additionally, a cross-domain policy file must be deployed at the resource to grant the client access to the remote domain. A cross-domain request will not be successful without this policy file hosted at the resource. The following example file grants permissive access to the host from all requests, but the host will only accept custom HTTP headers originating from yahoo.com.

For more information on cross-domain policy file specifications, see the following articles at Adobe Developer Connection.

The following example demonstrates a cross-domain transaction, starting with the initialization of the XDR transport, and subscribing to three global IO events.

Serializing HTML Form as Data

IO can serialize HTML form fields into a string of encoded name-value pairs. If the transaction is HTTP GET, the data are appended to the URI as a querystring. If the transaction if HTTP POST, the data will be the POST message.

Uploading Files in an HTML Form

The default XHR transport, used in IO, cannot upload HTML form data that includes elements of type="file". In this situation, IO will create an alternate transport, to facilitate the transaction. The following example shows how to configure a transaction involving file upload:

When using the io-upload-iframe sub-module, to perform file upload transactions, only some events -- global and transaction -- will be processed and fired. Specifically, these are:

  • Start
  • Complete

Success and Failure events are not processed and fired because the iframe transport does not provide access to the HTTP status and response headers, to discern those states.

Setting HTTP Headers

IO can be configured to send default HTTP Headers for all transactions, in addition to any HTTP headers defined in the configuration object. Headers can be set or removed as needed. The following example shows how to set and how to delete default headers in IO:

Queue

YUI io's queue implements YUI Queue to provide sychronous, transaction response. Specifically, transactions are handled -- by global or transaction event handlers -- in the order they are sent, regardless of actual server response order. Transactions can be promoted to the front of the queue, or they can be purged from the queue, as well.

Field Description
queue(uri, configuration) Method signature is identical to IO, but returns the id of the transaction.
queue.start() Activates the queue, and begins processing transactions in the queue. This is the default state of the queue.
queue.stop() Deactivates the queue. Transactions sent to queue() will be stored until the queue is re-started.
queue.promote(id) Moves the specified transaction stored in the queue to the head of the queue.
queue.purge(id) Deletes the specified transaction stored in the queue.

Known Issues

  • HTTP POST transactions are set by Firefox 3.x, to use a "Content-Type" of "application/x-www-form-urlencoded; charset=UTF-8". This cannot be overwritten by defining a different value in the configuration object.
  • Cross-domain requests
    • Custom HTTP headers are only sent with HTTP POST. This is a Flash Player limitation.
    • Only responseText is populated in the response object. HTTP status and HTTP response headers are not available. These data are not accessible by Flash Player, except in IE.
    • XML response data are not supported.
    • IE 6 and 7 will fail to fire event io:xdrReady if the page is reloaded. A timestamp querystring is added to io.swf, in the XDR example, to correct this condition.
  • Multiple HTML Submit buttons, in an HTML form, are not supported, at this time.
  • File upload transactions, using io-upload-iframe.js, support string response data. XML is not supported, at this time.

Support & Community

Forum & Blog

There is a dedicated mailing list for YUI 3. Click the link to visit the list, or use the form below to subscribe:

 

You might also be interested in the general YUI list: ydn-javascript.

In addition, please visit the YUIBlog for updates and articles about the YUI Library written by the library's developers.

Filing Bugs & Feature Requests

The YUI Library's public bug tracking and feature request repositories are located on the YUILibrary.com site. Before filing new feature requests or bug reports, please review our reporting guidelines.

Copyright © 2009 Yahoo! Inc. All rights reserved. Copyright | Privacy Policy | Terms of Use | Job Openings