XHR Level 2 responseType of arrayBuffer and Blob

[leegee]

This pull request in response to the below mails on the MT users' list.

The change is that a new option has been added to Requestjs, 'responseType.' Valid values are not checked, but passed directly to the xhr object just after it has been open()ed.

A callback could not be used to do this, as the xhr object is never exposed in an existing callback, and exposing it seemed contrary to the spirit of the code. Furthermore, this is base functionality of XHR, at level two, and is required for requests of HTML5 audio data via the Web Audio API (at least), so without this support, MooTools cannot be used with HTML5 Web Audio.

Please let me know what you think.

On 08/10/2012 05:09, Barry van Oudtshoorn wrote:

This sounds like it'd be something that could reasonably be exposed as an option on the Request class, so my recommendation would be to alter that class and send a pull request. No guarantee that it'll be accepted, of course, but this is certainly the way that I'd want to interact with this in MooTools. It's a pretty fundamental operation on XHR, to be honest, so I think it's worthwhile.

On 07/10/12 17:22, Lee Goddard wrote:

I'm making XHR requets with reponseType set to 'arraybuffer', so that I can receive binary data to pass to a Web Audio API audio context's decodeAudioData() method.

As far as I know, this cannot be done with MooTools as it stands, because although I could sub-class Request and adjust the onStateChange() and success(), access is required to the private XHR so that the responseType can be set after the requested is open()ed.

Over-riding the send() method seems like a bad idea, as I'd have to keep it updated with any change made to the core.

The only solution I can see is to expose the currently-private xhr object, but I guess it is private for a reason.

Does anyone have any suggestions, please?

TIA
Lee

[arian]

👍 would be good to bring more XHR 2 features in.

[DimitarChristoff]

seems cool. i like it. 👍 still, you can easily create your own Request subclass with this func in. it seems like too much of an edgecase

[leegee]

Dimitar,

Thing is that MT is falling behind in the world of XHR, and if I start creating my own custom Request sub-classes, I lose the benefit of using a globally-distributed library. I already have four projects with my own custom Request sub-class, and I'm not happy explaining to people why that is necessary.

This patch may not be good enough, but XHR Level 2 must be supported in MooTools if the library is survive in the world of HTML5, and unless Request is to be rewritten, I thought the approach I took did the least harm.

[cpojer]

I like this a lot. @leegee would you mind amending your commit with proper MooTools coding standards? (There are too many spaces in the documentation code example and an else block belongs on the same line with the closing parenthesis of the previous block and the opening parenthesis of the else block).

Also, it seems to my like you could shorten the code block around defining the response. If you don't know what to do feel free to join #mootools on IRC and ping me :)

[leegee]

Will do, thank you.

[arian]

Just put it on one line. Also there is an erroneous space at ) ){

[arian]

I added some comments, sorry for the nitpicking, but if you fix that we can pull it 😄

[leegee]

Fair points, thanks for making them.

On 18/01/2013 12:53, Arian Stolwijk wrote:

I added some comments, sorry for the nitpicking, but if you fix that
we can pull it 😄

—
Reply to this email directly or view it on GitHub
#2433 (comment).