Easier IE binary response parsing about jdataview HOT 12 CLOSED

feel free to update it with whatever works. I honestly have no idea ;)

from jdataview.

Hm. I thought you added that script block and had some reasons for that?

from jdataview.

@scintill added it
91c22b1

from jdataview.

I see. As far as I understood, you already have special patched version of jQuery for those who would like to use it. Do we really need to maintain jQuery-related code in primary library file?

from jdataview.

The jQuery patch makes sure that XHR doesn't touch the input. If you don't give a special option, it's going to treat the input as a UTF-8 string and will transform all the non-valid UTF-8 characters. It means that we lose information.

from jdataview.

Yeah, I know why it's needed, just wondering if we do really need to keep jQuery-related code inside primary library code or it could be removed from there so those who need it, can download it as separate patch?

from jdataview.

I don't really care either way. If you think it should be in a separate file, feel free to update it :) I just put it there because it was easier for my own use.

from jdataview.

This Stackoverflow comment, on a discussion I remember reading when I wrote the code, says new VBArray(responseBody).toArray() doesn't work in IE8. IIRC, I confirmed this myself. Ironically the VBScript hack is faster than the VBArray conversion, too, so if you have it for back-compatibility you may as well always use it.

I guess it is up to @vjeux to decide what IE versions to support. Personally, with the code already written, I think keeping some ugly code around is a fair price to pay for extra support. I will probably always keep it in my own fork at least, because I use it in an application that I personally may need to use on a WinXP box in a public library.

from jdataview.

Np. In my case I just had not to support such old stuff like IE8, so didn't like to use such an ugly thing like VBScript inception (even if it's a bit slower) :) But if somebody still does really need that - I'm fine with that.
@scintill and what's your opinion about separation of jQuery-related part? It seems to be significant piece of code that is not really needed for everyone who uses this library.

from jdataview.

The lib is trying to be a polyfill for DataView. So might as well be as compatible as we can get. And the code is already written and working :)

from jdataview.

If you mean moving the jQuery event listeners out of jdataview.js, I agree that would probably be cleaner, but don't really care enough to submit a patch. :P At least it looks like there will be no errors if jQuery is not loaded, so not much harm done to people not using it.

from jdataview.

Sure, it's not about errors, it's just about a bit cleaner code.

from jdataview.