W3C home > Mailing lists > Public > public-webapi@w3.org > April 2007

Re: Wrapped implementations of XHR in script

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 23 Apr 2007 11:17:04 -0700
Message-ID: <462CF820.1060501@sicking.cc>
To: Subbu Allamaraju <subbu.allamaraju@gmail.com>, Web APIs WG <public-webapi@w3.org>

You can define getters and setters in javascript that throw. Please 
refer to javascript tutorials for how to do this.

Best Regards,
Jonas Sicking

Subbu Allamaraju wrote:
> 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 Monday, 23 April 2007 18:19:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC