Using XMLHttpRequest run locally for local data reading

Discussion in 'Javascript' started by VK, Apr 24, 2010.

  1. VK

    VK Guest

    In continuation of http://groups.google.com/group/comp.lang.javascript/msg/787389d10afcaf77

    Test (unzip and run AJAX/test/index.html):
    http://sites.google.com/site/schoolsring/javascript
    LocalDataReadingTest.zip


    In each test:
    1) attempt to read xml file in the same directory
    2) attempt to read xml file in subdirectory
    3) attempt to read xml file in top directory
    4) attempt to read xml file in sibling directory

    Each reading made twice: one time with without overriding MIME type,
    next time with implied "text/xml" type.


    1) IE
    Internet Explorer 8.0 / Windows Vista SP2 - newest
    Internet Explorer 6.0.2900 / Windows XP SP2 - legacy test

    window.XMLHttpRequest in new IE does NOT allow local data reading at
    all.

    window.ActiveXObject(ProgID) doesn't support .overrideMimeType method

    Without implied "text/xml" Content-type the results are:

    OK attempt to read xml file in the same directory
    OK attempt to read xml file in subdirectory
    OK attempt to read xml file in top directory
    OK attempt to read xml file in sibling directory

    success request status = 0

    .requestXML is empty, a manual serialization from responseText is
    needed later.


    2) Fx
    Mozilla Firefox 3.6.3 / Windows Vista SP2 - newest
    Mozilla Firefox 3.5.7 / Windows XP SP2 - legacy test

    OK attempt to read xml file in the same directory
    OK attempt to read xml file in subdirectory
    _ attempt to read xml file in top directory (Error: Access to
    restricted URI denied)
    _ attempt to read xml file in sibling directory (Error: Access to
    restricted URI denied)

    success request status = 0

    .requestXML is filled properly either with or without
    using .overrideMimeType method


    3) Sf
    Apple Safari 4.0.5 / Windows Vista SP2

    OK attempt to read xml file in the same directory
    OK attempt to read xml file in subdirectory
    OK attempt to read xml file in top directory
    OK attempt to read xml file in sibling directory

    success request status = 0

    .requestXML is filled properly either with or without
    using .overrideMimeType method


    4) Ch
    Google Chrome 4.1.249 / Windows Vista SP2

    OK attempt to read xml file in the same directory
    OK attempt to read xml file in subdirectory
    OK attempt to read xml file in top directory
    OK attempt to read xml file in sibling directory

    success request status = 0

    .requestXML is filled properly either with or without
    using .overrideMimeType method


    5) Op
    Opera 10.51 / Windows Vista SP2

    OK attempt to read xml file in the same directory
    OK attempt to read xml file in subdirectory
    OK attempt to read xml file in top directory
    OK attempt to read xml file in sibling directory

    success request status = 0

    .requestXML is filled properly either with or without
    using .overrideMimeType method


    Conclusions:
    1) IE sucks but usable :)
    2) Fx is the most strict
    3) overrideMimeType is useless: it is not needed where supported
    and it is not supported where needed

    4) The quality of XMLHttpRequest instantiation blocks in all
    prominent libraries is *awful*... No, sorry: it is AWFUL. No... It is
    a BLOODY AWFUL NIGHTMARE. The guys didn't read MSDN for years. If they
    don't care about IE users whatsoever is fine, but they should
    explicitly mark it then. I am posting the XHR init part from the test
    file here - not as a sample of an outstanding coding, but at least to
    show some descent approach with the crucial points commented:


    function getAjaxObject(forLocalData) {

    var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;

    var xhr = null;

    if (typeof window == 'object') {

    /* Common branch for modern browsers */
    if (
    (typeof window.XMLHttpRequest != 'undefined') &&
    // window.XMLHttpRequest instances in IE do not
    // have local file access even from local pages,
    // unlike ActiveX instances: so if forLocalData
    // flag set, we are trying to use the underlaying
    // ActiveX constructor.
    !(isIE && forLocalData)
    ) {
    try {
    return new window.XMLHttpRequest();
    }
    catch(e) {
    return new Error(e.message);
    }
    }

    /* ActiveX branch for old IE versions and for local data access
    capable instances, see:
    * http://blogs.msdn.com/xmlteam/archi...ht-version-of-msxml-in-internet-explorer.aspx
    * http://groups.google.com/group/micr..._frm/thread/7772ac2ad016e2bf/5bd173be4950e107
    * http://blogs.msdn.com/ie/archive/2006/01/23/516393.aspx
    * for proper ProgID and proper ProgID trying sequence.
    */
    else if (
    (isIE) &&
    (typeof window.ActiveXObject != 'undefined') // IE 5.x for MacOS
    without ActiveX
    ) {
    try {
    return new window.ActiveXObject('Msxml2.XMLHTTP.6.0');
    }
    catch(e) {
    try {
    xhr = new window.ActiveXObject('Msxml2.XMLHTTP.3.0');
    /* Msxml2.XMLHTTP.3.0 and older have XSL Patterns as the
    * defailt XML language, not XPath, so fixing it:
    */
    xhr.setProperty('SelectionLanguage', 'XPath');
    return xhr;
    }
    catch(e) {
    try {
    xhr = new window.ActiveXObject('Msxml2.XMLHTTP');
    /* Msxml2.XMLHTTP (IE6 / Win XP SP2 in default installation)
    * have XSL Patterns as the defailt XML language, not XPath,
    * but it doesn't support .setProperty switch.
    * Setting the warning flag at the very least:
    */
    arguments.callee.isXSLPatterns = true;
    return xhr;
    }
    catch(e) {
    /* Microsoft.XMLHTTP ProgID as the last ressort is not used
    * as the security consideration should prevail over the
    * maximum backward compatibility. Unlock for special cases only.
    */
    //try {
    // return new window.ActiveXObject('Microsoft.XMLHTTP');
    //}
    //catch(e) {
    // return new Error(e.message);
    //}
    return new Error(e.message);
    }
    }
    }
    }

    /* If nothing then nothing... */
    else {
    return new Error('ActiveX is missing or blocked');
    }
    }
    else {
    return new Error('window host object is missing');
    }
    }
    VK, Apr 24, 2010
    #1
    1. Advertising

  2. VK

    VK Guest

    On Apr 24, 8:40 pm, VK <> wrote:
    > Conclusions:
    >  1) IE sucks but usable :)
    >  2) Fx is the most strict


    ....

    5) async request checked for "200 OK" status only means either of two
    things:
    a) the coder has no clue about Ajax he/she dared to program
    b) the coder deliberately decided to make his Ajax not usable for
    local data
    reading but failed to inform his/her users.

    All good boys and girls (the one who reading c.l.j. :) always do like
    this:

    if ((myRequest.status == 200) || (myRequest.status == 0)) {
    // success
    }


    6) XHR instantiation w/o explicit IE check and w/o possibility to flag
    for ActiveX instead of XMLHttpRequest is a strong sign of i) a
    clueless coding or ii) 5-b above
    VK, Apr 24, 2010
    #2
    1. Advertising

  3. VK wrote:

    > [...] I am posting the XHR init part from the test file here - not as a
    > sample of an outstanding coding,


    What else is new?

    > but at least to show some descent approach with the crucial points
    > commented:


    In your fantasy world, perhaps.

    > function getAjaxObject(forLocalData) {
    >
    > var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;


    OMG.

    > var xhr = null;
    >
    > if (typeof window == 'object') {
    >
    > /* Common branch for modern browsers */
    > if (
    > (typeof window.XMLHttpRequest != 'undefined') &&
    > [...]
    > !(isIE && forLocalData)
    > ) {
    > [...]
    > }
    > [...]
    > else if (
    > (isIE) &&
    > (typeof window.ActiveXObject != 'undefined') // IE 5.x for MacOS
    > without ActiveX
    > ) {


    Apparently you are not paying attention.

    > try {
    > return new window.ActiveXObject('Msxml2.XMLHTTP.6.0');
    > }
    > catch(e) {
    > try {
    > xhr = new window.ActiveXObject('Msxml2.XMLHTTP.3.0');
    > [aso.]


    Obviously you are not paying attention at all, or your puny mind is unable
    to process or store the discussion results.


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
    Thomas 'PointedEars' Lahn, Apr 24, 2010
    #3
  4. VK

    VK Guest

    On Apr 24, 11:08 pm, Thomas 'PointedEars' Lahn <>
    wrote:

    > >  var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;


    Thomas, it is from a real production code, not usual c.l.j. child
    games. It takes more efforts to comprehend, but the results are
    fruitful. It is a JScript conditional compilation statement:
    http://msdn.microsoft.com/en-us/library/7kx09ct1(VS.80).aspx
    Any browser but IE will see false, IE will see true.

    Why not the regular baby check
    if (window.ActiveXObject) { ...
    ?

    Because baby checks need baby efforts to spoof, like
    if !!(window.ActiveXObject) {
    window.ActiveXObject = new OurAjaxLoophole();
    }


    > >  var xhr = null;

    >
    > >  if (typeof window == 'object') {

    >
    > > /* Common branch for modern browsers */
    > >   if (
    > >     (typeof window.XMLHttpRequest != 'undefined') &&
    > > [...]
    > >     !(isIE && forLocalData)
    > >    ) {
    > > [...]
    > >   }
    > > [...]
    > >   else if (
    > >     (isIE) &&
    > >     (typeof window.ActiveXObject != 'undefined') // IE 5.x for MacOS
    > > without ActiveX
    > >    ) {

    >
    > Apparently you are not paying attention.
    > >    try {
    > >     return new window.ActiveXObject('Msxml2.XMLHTTP.6.0');
    > >    }
    > >    catch(e) {
    > >     try {
    > >      xhr = new window.ActiveXObject('Msxml2.XMLHTTP.3.0');
    > > [aso.]

    >
    > Obviously you are not paying attention at all, or your puny mind is unable
    > to process or store the discussion results.


    No, it is just might be hard to realize how little one (you) know
    about the real compatibility. The link to resources are provided right
    and the code, read and learn. A separate hint as it is the most
    popular urban legend about XHR on IE:
    No, ActiveXObject('Msxml2.XMLHTTP') does NOT mean "take the latest/
    current version". It means: "take the oldest one from all available".
    For the rest keep study linked resources. Do not hesitate to ask for
    explanations or for extra test cases for particular points.
    VK, Apr 24, 2010
    #4
  5. VK wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> > var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;

    >
    > Thomas, it is from a real production code,


    I pity your users already.

    > not usual c.l.j. child games.


    It's your usual nonsense. JScript support has *nothing* to do with the
    underlying DOM that provides the `XMLHttpRequest' and `ActiveXObject'
    objects.

    > [...] It takes more efforts to comprehend,


    One must be smoking what you are smoking to "comprehend" that.

    > but the results are fruitful.


    Hardly.

    > It is a JScript conditional compilation statement:
    > http://msdn.microsoft.com/en-us/library/7kx09ct1(VS.80).aspx


    I *know* what it is, stupid.

    > Any browser but IE will see false, [...]


    Definitely no.

    > Why not the regular baby check
    > if (window.ActiveXObject) { ...
    > ?


    Nobody but you here recommends that, stupid.

    > Because baby checks need baby efforts to spoof, like
    > if !!(window.ActiveXObject) {
    > window.ActiveXObject = new OurAjaxLoophole();
    > }


    That's not even syntactically valid.

    >> > var xhr = null;

    >>
    >> > if (typeof window == 'object') {

    >>
    >> > /* Common branch for modern browsers */
    >> > if (
    >> > (typeof window.XMLHttpRequest != 'undefined') &&
    >> > [...]
    >> > !(isIE && forLocalData)
    >> > ) {
    >> > [...]
    >> > }
    >> > [...]
    >> > else if (
    >> > (isIE) &&
    >> > (typeof window.ActiveXObject != 'undefined') // IE 5.x for MacOS
    >> > without ActiveX
    >> > ) {

    >>
    >> Apparently you are not paying attention.
    >> > try {
    >> > return new window.ActiveXObject('Msxml2.XMLHTTP.6.0');
    >> > }
    >> > catch(e) {
    >> > try {
    >> > xhr = new window.ActiveXObject('Msxml2.XMLHTTP.3.0');
    >> > [aso.]

    >>
    >> Obviously you are not paying attention at all, or your puny mind is
    >> unable to process or store the discussion results.

    >
    > No, it is just might be hard to realize how little one (you) know
    > about the real compatibility. [...]


    Often Wrong, your code will _not_ work in MSHTML with local files to begin
    with.


    PointedEarws
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
    Thomas 'PointedEars' Lahn, Apr 24, 2010
    #5
  6. VK

    VK Guest

    On Apr 24, 11:33 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > JScript support has *nothing* to do with the
    > underlying DOM that provides the `XMLHttpRequest' and `ActiveXObject'
    > objects.


    Real production has *nothing* to do with theoretical masturbations.
    ActiveXObject = IE. IE = ActiveXObject. For the rest - write poems on
    c.l.j. Someone may read them.

    > > It is a JScript conditional compilation statement:
    > >  http://msdn.microsoft.com/en-us/library/7kx09ct1(VS.80).aspx

    >
    > I *know* what it is, stupid.


    That's good for a starter.

    > > Any browser but IE will see false, [...]

    >
    > Definitely no.


    Definitely yes, silly boy. You just claimed you knew the matter.


    > Often Wrong, your code will _not_ work in MSHTML with local files to begin
    > with.


    OK, PointedEars, I am ready to have a harsh or not so harsh
    *discussion* but I will not respond to a pure blind trolling. The test
    results were received using this code, the code is posted as one zip
    file to download. Get it and check it. If you want to call me a liar
    who fabricates *results* (leaving out their interpretations for now) -
    then you better do not do it.
    VK, Apr 24, 2010
    #6
  7. VK wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> JScript support has *nothing* to do with the
    >> underlying DOM that provides the `XMLHttpRequest' and `ActiveXObject'
    >> objects.

    >
    > Real production has *nothing* to do with theoretical masturbations.
    > ActiveXObject = IE. IE = ActiveXObject. For the rest - write poems on
    > c.l.j. Someone may read them.


    You're such an idiot:

    <http://en.wikipedia.org/wiki/MSHTML#Trident-based_applications>


    PointedEars
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
    Thomas 'PointedEars' Lahn, Apr 24, 2010
    #7
  8. VK

    VK Guest

    On Apr 24, 11:52 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > VK wrote:
    > > Thomas 'PointedEars' Lahn wrote:
    > >> JScript support has *nothing* to do with the
    > >> underlying DOM that provides the `XMLHttpRequest' and `ActiveXObject'
    > >> objects.

    >
    > > Real production has *nothing* to do with theoretical masturbations.
    > > ActiveXObject = IE. IE = ActiveXObject. For the rest - write poems on
    > > c.l.j. Someone may read them.

    >
    > You're such an idiot:
    >
    > <http://en.wikipedia.org/wiki/MSHTML#Trident-based_applications>


    You are so silly. What connection in your mind is between a rendering
    engine .dll and COM / ActiveX? A hint: none, except the substrings
    "MS" and "HTML" one can find both in .dll name and in some ProgIDs :)

    Learn, learn, learn - that's the only salvation. At the spare time try
    to use new ActiveXObject(whatever) in Winamp, it does use Trident as
    well ;-)
    VK, Apr 24, 2010
    #8
  9. VK wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> VK wrote:
    >> > Thomas 'PointedEars' Lahn wrote:
    >> >> JScript support has *nothing* to do with the
    >> >> underlying DOM that provides the `XMLHttpRequest' and `ActiveXObject'
    >> >> objects.

    >>
    >> > Real production has *nothing* to do with theoretical masturbations.
    >> > ActiveXObject = IE. IE = ActiveXObject. For the rest - write poems on
    >> > c.l.j. Someone may read them.

    >>
    >> You're such an idiot:
    >>
    >> <http://en.wikipedia.org/wiki/MSHTML#Trident-based_applications>

    >
    > You are so silly. What connection in your mind is between a rendering
    > engine .dll and COM / ActiveX? A hint: none, [rubbish recycled]


    The layout engine usually provides the host environment for DOM objects. It
    is true that MSHTML does not need to mean ActiveX is also supported.
    However, more important is that there is not a necessary connection between
    _layout_ engine and the DOM binding it provides and the supported scripting
    language. That is why your approach is junk.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Apr 24, 2010
    #9
  10. VK

    VK Guest

    On Apr 25, 12:24 am, Thomas 'PointedEars' Lahn <>
    wrote:
    > The layout engine usually provides the host environment for DOM objects.


    Uhmm... It is a very simplistic way to put it, but OK.

    > It is true that MSHTML does not need to mean ActiveX is also supported.
    > However, more important is that there is not a necessary connection between
    > _layout_ engine and the DOM binding it provides and the supported scripting
    > language.


    For IE of any version COM interfaces, accessible over
    window.ActiveXObject, are not part of a rendering engine nor even part
    of IE itself. They are programmed into JScript engine. And JScript
    engine in IE of any version is one separate DLL library located at
    %SystemRoot%System32/jscript.dll
    It is made so because jscript.dll is not a part of IE, it is a system
    dll needed for Windows Script Host functionality in its JScript part.
    The other system dll %SystemRoot%System32/vbscript.dll provides WSH
    VBScript part of functionality. So either one has IE installed or not,
    these dll are there, unless the system is badly broken. But IE
    installations may upgrade these dll to newer ones if instructed to do
    so. So IE is just yet another user of jscript.dll. Moreover until IE7
    it was possible to replace jscript.dll so making IE6 running with
    JScript for IE5 or IE5 running with JScript for IE6. Funny, but
    crashes quickly.

    Any way, to make the long story shorter:
    var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;
    effectively checks if the environment uses jscript.dll so running
    Microsoft JScript of some (easy to check) version. If false, than it
    is not Microsoft JScript, that is not jscript.dll and no way in the
    world - atop of all other consequences - it may implement Microsoft
    ActiveXObject. I am obviously talking about officially released
    commercial software.

    > That is why your approach is junk.


    This is why my approach is bulletproof and ActiveXObject feature
    testing is junk.

    P.S. As a side note I am a bit suspicious about IE-compatibility
    experts claiming that they never had and/or not having any Microsoft
    products and being happy with *nux or MacOS. This one not directly to
    you, just an observation. Where do they get all their M$-related
    wisdom? From their "mis-fortunate" M$'ed friends? As a sample of the
    prevailing illiteracy on Msxml2.XMLHTTP topic this W3Schools "valuable
    advise" at
    http://www.w3schools.com/xpath/xpath_examples.asp
    "To solve the [0] and [1] problem in IE5+, you can set the
    SelectionLanguage to XPath."
    Splendid! "This property or method is not supported" runtime error for
    all IE users up to IE7, unless they manually updated their XMLHTTP
    libraries.
    About their XHR instantiation approach I have nothing to say at all:
    http://www.w3schools.com/ajax/ajax_xmlhttprequest_create.asp
    Whoever read comments in the code I posted will easily understand that
    W3Schools is NOT a place to learn, at least about Ajax.
    But hell with W3Schools - lousy were, lousy stay, lousy will remain.
    The whole Web info like that on the topic, and respectively all libs
    like that. "X said to Y that Z heard from... that..." And that's past
    over 5 years after the "Ajax" explosion! http://www.adaptivepath.com/ideas/essays/archives/000385.php
    What is wrong with the world?..
    VK, Apr 24, 2010
    #10
  11. VK

    VK Guest

    On Apr 24, 10:26 pm, VK <> wrote:
    > All good boys and girls (the one who reading c.l.j. :) always do like
    > this:
    >
    >  if ((myRequest.status == 200) || (myRequest.status == 0)) {
    >   // success
    >  }


    Just got a bit down from my colleague for this advice. Just didn't
    look into libraries for a long time, sorry.

    Either for sync or async requests it has to accounted that for failed
    attempt to read a local file (say file doesn't exists):

    IE throws error on xhr.open(...) stage
    Fx throws error on xhr.send('') stage
    Sf returns .status -1100

    Ch and Op return status 0 either for success or for error. That last
    one implies that for local data reading .status is useless. One needs
    to check responseText to see if anything in there. Actually it the
    best way anyway. One needs responseText/responseXML data in the first
    place, not .status data.
    ..status is useful if nothing found in responseText and you are trying
    to figure out why.

    And yes, open/send should be always placed into try-catch block.
    VK, Apr 24, 2010
    #11
  12. VK

    Eric Bednarz Guest

    VK <> writes:

    > Test (unzip and run AJAX/test/index.html):
    > http://sites.google.com/site/schoolsring/javascript
    > LocalDataReadingTest.zip


    I see two problems here. The good news is that one of them can be
    solved. Use a newsreader.

    > […] The guys didn't read MSDN for years.


    I’m reminded of a dialog in A fish called Wanda, featuring apes, reading
    and Nietzsche. :)

    > var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;


    This is a ridiculously verbose way of writing

    var isIE = /*@cc_on true || @*/ false;

    instead of

    var isIE /*@cc_on = true @*/;
    Eric Bednarz, Apr 25, 2010
    #12
  13. VK

    VK Guest

    On Apr 25, 3:19 am, Eric Bednarz <> wrote:
    > >  var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;

    >
    > This is a ridiculously verbose way of writing
    >
    >   var isIE = /*@cc_on true || @*/ false;
    >
    > instead of
    >
    >   var isIE /*@cc_on = true @*/;


    Do we have have a world keystroke shortage? :) Also it is a
    conditional compilation, so I prefer to see conditionally compiled
    blocks of *statements*, not pieces of them - despite IE will take it.
    More important though that once @cc_on, it is on until @end or to the
    end of source. Not important for a few liner, but making the engine
    additionally check for pragma statements across 10-100Kb of text is
    not efficient, so I @end cc right after it not needed anymore.
    Question of taste and habits anyway. I just don't agree that full
    syntax of anything can be "ridiculous". "Not necessary" is the max
    IMHO. :)
    VK, Apr 25, 2010
    #13
  14. VK

    Eric Bednarz Guest

    VK <> writes:

    > On Apr 25, 3:19 am, Eric Bednarz <> wrote:


    >> > var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;


    >> var isIE /*@cc_on = true @*/;

    >
    > Do we have have a world keystroke shortage? :)


    The problem is that confused syntax supports confused minds.

    > Also it is a
    > conditional compilation, so I prefer to see conditionally compiled
    > blocks of *statements*, not pieces of them - despite IE will take it.


    Your gut feeling might be that an if statement assigned to a variable
    makes more sense. That might explain it. :)

    > More important though that once @cc_on, it is on until @end or to the
    > end of source.


    ‘@end’ in CC pretty much does what programmers would intuitively expect
    it to do in the context of a syntax that has blocks without braces.

    I could say now that your problem is that you make things up while you
    type, but that has been explained to you in this group… how often?


    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
    <html>
    <head>
    <title></title>
    </head>
    <body>
    <script type='text/javascript'>
    var isIE = /*@cc_on/*@if(@_jscript)true@else@*/false/*@end@*/;
    isIE && alert(@_jscript_version);
    </script>
    </body>
    </html>
    Eric Bednarz, Apr 25, 2010
    #14
  15. VK

    VK Guest

    On Apr 25, 2:46 am, VK <> wrote:

    After more consultations posting the corrected stay-alone XHR
    instantiation function with local data reading support. All comments
    are inside the code. TinyURL service is used to accomodate long links
    to Usenet posting.



    function getAjaxObject(forLocalData) {

    var f = arguments.callee;

    var isIE = /*@cc_on true || @*/ false;;

    var xhr = null;

    if (typeof window == 'object') {

    /* Common branch for modern browsers */
    if (
    (typeof window.XMLHttpRequest != 'undefined') &&
    /* window.XMLHttpRequest instances in IE do not
    * have local file access even from local pages,
    * unlike ActiveX instances: so if forLocalData
    * flag set, we are trying to use the underlaying
    * ActiveX constructor.
    */
    ( !(isIE && forLocalData) )
    ) {
    try {
    return new window.XMLHttpRequest();
    }
    catch(e) {
    return new Error(e.message);
    }
    }

    /* ActiveX branch for old IE versions and
    * for local data access capable instances. See:
    * 1) http://tinyurl.com/MSDNBlog1
    * 2) http://tinyurl.com/MSNewsGroup1
    * 3) http://tinyurl.com/MSDNBlog2
    * for proper ProgID and proper ProgID trying sequence.
    */
    else if (
    (isIE) &&
    /* if IE 5.x for MacOS without ActiveX: */
    (typeof window.ActiveXObject != 'undefined')
    ) {
    try {
    xhr = new window.ActiveXObject('Msxml2.XMLHTTP.6.0');
    f.isActiveX = true;
    f.ActiveXVersion = 6;
    return xhr;
    }
    catch(e) {
    try {
    xhr = new window.ActiveXObject('Msxml2.XMLHTTP.3.0');
    /* Contrary to numerous MS claims like here:
    * http://tinyurl.com/SelectionLanguage
    * Msxml2.XMLHTTP.3.0 (IE6 / Win XP SP2 by default)
    * does not have XSL Patterns as the default language
    * neither it supports setProperty method so trying
    * to apply setProperty("SelectionLanguage", "XPath")
    * leads to "not supported" runtime error on IE6.
    * In the reality the last COM with XSL Patterns were
    * in XMLHTTP.2.x versions. Looks pretty much as a MS
    * internal urban legend.
    */
    f.isActiveX = true;
    f.ActiveXVersion = 3;
    return xhr;
    }
    catch(e) {
    /* As per MS Security Bulletin http://tinyurl.com/MS06-061
    * Msxml2.XMLHTTP.2.x and older like Microsoft.XMLHTTP can
    * be blocked and overall the security considerations
    * should prevail over the maximum backward compatibility.
    * Add these branches only if you really need to support
    * IE 5.x in a non-commercial home use solution.
    */
    return new Error(e.message);
    }
    }
    }
    /* If nothing then nothing... */
    else {
    return new Error('ActiveX is missing or blocked');
    }
    }
    else {
    return new Error('window host object is missing');
    }
    }
    VK, Apr 25, 2010
    #15
  16. VK

    VK Guest

    On Apr 25, 5:07 am, Eric Bednarz <> wrote:
    > I could say now that your problem is that you make things up while you
    > type


    No, I am just following what is written on the producer page. The
    current CC docs
    http://msdn.microsoft.com/en-us/library/7kx09ct1(v=VS.80).aspx
    http://msdn.microsoft.com/en-us/library/ct27x3xa(v=VS.80).aspx
    is a complete rewrite with JScript 8.0 as a target at the top of the
    page. At the time I was reading it a few years ago the target was
    JScript 5.6 and
    1) @cc_on - @end was given as "pragma parser on/off" paired statements
    2) @elif was not documented nor mentioned anywhere at all. I saw it a
    code snippet in MSDN this is how I "discovered" it.

    In relation to @end I tested it on IE6 / Win XP and your statement
    about it being just closing part of @if-@elif-@else-@end block is
    right. And @cc_on once used keeps pragma parser on till the end of
    source. So either it was a change from IE5 to IE6 or - most probably -
    bad documentation from the very beginning.
    VK, Apr 25, 2010
    #16
  17. VK wrote:

    > Eric Bednarz wrote:
    >> I could say now that your problem is that you make things up while you
    >> type

    >
    > No, I am just following what is written on the producer page. The
    > current CC docs
    > http://msdn.microsoft.com/en-us/library/7kx09ct1(v=VS.80).aspx
    > http://msdn.microsoft.com/en-us/library/ct27x3xa(v=VS.80).aspx
    > is a complete rewrite with JScript 8.0 as a target at the top of the
    > page. At the time I was reading it a few years ago the target was
    > JScript 5.6 and
    > 1) @cc_on - @end was given as "pragma parser on/off" paired statements
    > 2) @elif was not documented nor mentioned anywhere at all.


    You are even a lousier liar than you are a programmer:

    <http://msdn.microsoft.com/en-us/library/8ka90k2e%28VS.71%29.aspx>
    <http://msdn.microsoft.com/en-us/library/8ka90k2e%28VS.80%29.aspx>
    <http://msdn.microsoft.com/en-us/library/8ka90k2e%28VS.85%29.aspx>

    <http://msdn.microsoft.com/en-us/library/58dz2w55%28VS.71%29.aspx>
    <http://msdn.microsoft.com/en-us/library/58dz2w55%28VS.80%29.aspx>
    <http://msdn.microsoft.com/en-us/library/58dz2w55%28VS.85%29.aspx>


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
    Thomas 'PointedEars' Lahn, Apr 25, 2010
    #17
  18. VK

    VK Guest

    > VK wrote:
    > > No, I am just following what is written on the producer page. The
    > > current CC docs
    > >  http://msdn.microsoft.com/en-us/library/7kx09ct1(v=VS.80).aspx
    > >  http://msdn.microsoft.com/en-us/library/ct27x3xa(v=VS.80).aspx
    > > is a complete rewrite with JScript 8.0 as a target at the top of the
    > > page. At the time I was reading it a few years ago the target was
    > > JScript 5.6 and
    > > 1) @cc_on - @end was given as "pragma parser on/off" paired statements
    > > 2) @elif was not documented nor mentioned anywhere at all.

    >
    >
    > On Apr 25, 6:52 pm, Thomas 'PointedEars' Lahn <> wrote:
    > You are even a lousier liar than you are a programmer:


    Hardly, as long a you are here. :)

    > <http://msdn.microsoft.com/en-us/library/8ka90k2e%28VS.71%29.aspx>
    > <http://msdn.microsoft.com/en-us/library/8ka90k2e%28VS.80%29.aspx>
    > <http://msdn.microsoft.com/en-us/library/8ka90k2e%28VS.85%29.aspx>
    >
    > <http://msdn.microsoft.com/en-us/library/58dz2w55%28VS.71%29.aspx>
    > <http://msdn.microsoft.com/en-us/library/58dz2w55%28VS.80%29.aspx>
    > <http://msdn.microsoft.com/en-us/library/58dz2w55%28VS.85%29.aspx>


    So? In the way MSDN organizes its dynamic URLs the Wayback Machine is
    useless. Again: in the way it is written now is day and night by its
    completeness and clearness in comparison with 2004-2005. That time it
    was more a set of obscure hints one needed to get together and to
    decrypt.

    Any way, the check is updated for a shorter form proposed by Eric
    Bednarz. Any *constructive* comments on the new getAjaxObject code?
    VK, Apr 25, 2010
    #18
  19. VK wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> VK wrote:
    >> > No, I am just following what is written on the producer page. The
    >> > current CC docs
    >> > http://msdn.microsoft.com/en-us/library/7kx09ct1(v=VS.80).aspx
    >> > http://msdn.microsoft.com/en-us/library/ct27x3xa(v=VS.80).aspx
    >> > is a complete rewrite with JScript 8.0 as a target at the top of the
    >> > page. At the time I was reading it a few years ago the target was
    >> > JScript 5.6 and
    >> > 1) @cc_on - @end was given as "pragma parser on/off" paired statements
    >> > 2) @elif was not documented nor mentioned anywhere at all.

    >>
    >> You are even a lousier liar than you are a programmer:

    > [...]
    >> <http://msdn.microsoft.com/en-us/library/8ka90k2e%28VS.71%29.aspx>
    >> <http://msdn.microsoft.com/en-us/library/8ka90k2e%28VS.80%29.aspx>
    >> <http://msdn.microsoft.com/en-us/library/8ka90k2e%28VS.85%29.aspx>
    >>
    >> <http://msdn.microsoft.com/en-us/library/58dz2w55%28VS.71%29.aspx>
    >> <http://msdn.microsoft.com/en-us/library/58dz2w55%28VS.80%29.aspx>
    >> <http://msdn.microsoft.com/en-us/library/58dz2w55%28VS.85%29.aspx>

    >
    > So? In the way MSDN organizes its dynamic URLs the Wayback Machine is
    > useless.


    The URLs may have changed, but the content has been the same *for years*.

    > Again: in the way it is written now is day and night by its completeness
    > and clearness in comparison with 2004-2005. That time it was more a set of
    > obscure hints one needed to get together and to decrypt.


    No, it evidentially (sic!) was/is not. Your problem is that you are either
    incapable to understand what you read, or to remember what you have read; so
    you are making things up while you are typing, as Eric correctly observed.
    Or you are an awful liar. Take your pick.

    And learn to quote, if you can learn nothing else.


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
    Thomas 'PointedEars' Lahn, Apr 25, 2010
    #19
  20. VK

    VK Guest

    Uhmm... I guess I forgot to mention how to eventually get XML from
    responseText for IE. IE's serialization ways are numerous, version-
    dependent and boring. See for instance:
    http://groups.google.com/group/microsoft.public.xml/browse_frm/thread/822f8a6df3214c1d

    Because for other browsers this problem doesn't arise, we can be IE
    specific and use quick, dirty and amusingly effective way using IE-
    specific XML Data Islands tools and IE's <XML> tag.

    So assuming we've got responseText filled, responseXML empty and we
    know that it should be a well-formed XML file, we simply do that:

    var tmp = document.createElement('DIV');
    tmp.innerHTML = '<XML>' + xhr.responseText + '</XML>';
    return tmp.firstChild.XMLDocument.documentElement;

    Respectively for a HTML fragment we can do:

    var tmp = document.createElement('DIV');
    tmp.innerHTML = xhr.responseText;
    return tmp.firstChild;

    Enjoy! :)
    VK, Apr 25, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Raterus
    Replies:
    2
    Views:
    820
    Joe Fallon
    Apr 28, 2004
  2. Mickey Segal
    Replies:
    9
    Views:
    6,621
    Andrew Thompson
    Jan 8, 2005
  3. Replies:
    3
    Views:
    256
    =?iso-8859-1?B?c+liYXN0aWVu?=
    Jan 6, 2006
  4. fool
    Replies:
    0
    Views:
    105
  5. Replies:
    0
    Views:
    90
Loading...

Share This Page