Wrapped implementations of XHR in script

I have a question on the nature of implementations possible for XHR. In
particular, would the following be a valid scenario?

A client API (e.g in JavaScript) provides a factory for creating XHR
instances.

  foo.bar.XMLhttpRequestFactory.newInstance();

which would return one of the following:

- A natively implemented XHR object (e.g. one implemented by browser)
- An XHR implementation wrapping the native XHR object

The factory would determine this based on some conditions (e.g. the context
in which the factory is being used).

Such a factory/wrapped model would let us provide coordination between
different UI components rendered in a page without strongly coupling those
UI components.

Here is an example - one of the UI components submits a request through XHR,
which in some cases, may cause changes to the other UI components rendered
on the same page. The UI component that initiated the request isn't aware of
other UI components on the page, and so cannot directly update those
components.

In this case, a wrapped object would be able to update the changed UI
components without the knowledge of the source UI component. As far as the
source component is concerned, the wrapped object is no different from the
native XHR object.

This style of wrapped objects makes sense for portlets, and such
component-style applications aggregated in portals, and we are considering
this approach in JSR286 EG and the WSRP TC.

One issue that stands in the way of this approach is the MUST requirement to
throw INVALID_STATE_ERR when the response fields (status, statusText,
responseXML, and responseText) are not available. When implemented in
JavaScript, I'm not aware of any way to throw an exception on field access,
and so this makes the wrapped implementation non-conformant.

Any comments on whether this is considered as a valid approach? If so,
relaxation of this MUST statement would help make wrapped objects
conformant.

Regards,
Subbu

------------------------------
http://www.subbu.org

Received on Thursday, 12 October 2006 14:01:02 UTC