Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: Ajax

  1. #11
    Join Date
    May 2006
    Location
    Sydney, Australia - Near the coast.
    Posts
    1,995
    Thanks
    0
    Thanked 8 Times in 7 Posts

    Default

    Y'know, if you want really good ajax, (and some good DOM as well) you could use the Prototype Framework.
    Peter - alotofstuffhere[dot]com - Email Me - Donate via PayPal - Got spare hardware? Donate 'em to me :) Just send me a PM.
    Currently: enjoying the early holidays :)
    Read before posting: FAQ | What you CAN'T do with JavaScript | Form Rules | Thread Title Naming Guide

  2. #12
    Join Date
    Mar 2005
    Location
    SE PA USA
    Posts
    29,074
    Thanks
    44
    Thanked 3,216 Times in 3,178 Posts
    Blog Entries
    12

    Default

    Quote Originally Posted by tech_support View Post
    Y'know, if you want really good ajax, (and some good DOM as well) you could use the Prototype Framework.
    Don't you mean, if you want bloated code and a slew of unprotected global variables with short names, use Prototype Framework?

    I already stated that I was not using external libraries, and Prototype Framework will not help beginners understand the basics anyway.
    - John
    ________________________

    Show Additional Thanks: International Rescue Committee - Donate or: The Ocean Conservancy - Donate or: PayPal - Donate

  3. #13
    Join Date
    May 2006
    Location
    Sydney, Australia - Near the coast.
    Posts
    1,995
    Thanks
    0
    Thanked 8 Times in 7 Posts

    Default

    Is The Prototype Framework really that bad?
    Some companies do use it...
    Peter - alotofstuffhere[dot]com - Email Me - Donate via PayPal - Got spare hardware? Donate 'em to me :) Just send me a PM.
    Currently: enjoying the early holidays :)
    Read before posting: FAQ | What you CAN'T do with JavaScript | Form Rules | Thread Title Naming Guide

  4. #14
    Join Date
    Mar 2005
    Location
    SE PA USA
    Posts
    29,074
    Thanks
    44
    Thanked 3,216 Times in 3,178 Posts
    Blog Entries
    12

    Default

    For a DD type script, yes I think so. It's OK, and in some cases even beneficial, if it is used as part of a coordinated site design and all scripts on the site either use it, don't conflict with it, or act in their own scripting space.

    Ideally, for a lib like that to be really worth the bother, all pages on a site that use scripts would have it linked as an external script from a single location on the server to their heads and rely upon it both extensively and wherever and whenever possible.

    The reasons for this are the overhead, load time, and bandwidth involved in the lib, its complexity, and vulnerability to conflicts. If it is used in this way, as the primary script that powers all other scripts on a site, this minimizes its drawbacks and maximizes its advantages.

    But, for the casual script user, it is overkill at best.

    Also, from what I can gather, mootools is a superior lib. This (the choice of libs, if you are using one) is not as critical though, as is making sure to use it as efficiently and thoroughly as possible.
    - John
    ________________________

    Show Additional Thanks: International Rescue Committee - Donate or: The Ocean Conservancy - Donate or: PayPal - Donate

  5. #15
    Join Date
    Dec 2004
    Location
    UK
    Posts
    2,358
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by jscheuer1 View Post
    From what you (mwinter) write, it appears (and testing seemed to bear this out), I would need to create a separate request object and send it just in order to see if the mime type is as expected and that it would then be too late to change the mime type for that request.
    This wasn't what I was trying to get at: I was describing the test as something to do during development to determine server behaviour. Based on the results, the developer can either attempt to reconfigure the server or try to fiddle the response with the overrideMimeType method (which I wouldn't recommend).

    At production time, the developer should know exactly what the server will do, so no testing is required.

    I would also point out that changing the media type of the response is only necessary to have the client properly process an XML response, enabling the responseXML property.
    Mike

  6. #16
    Join Date
    Mar 2005
    Location
    SE PA USA
    Posts
    29,074
    Thanks
    44
    Thanked 3,216 Times in 3,178 Posts
    Blog Entries
    12

    Default

    Revisiting this thread after much time because I've learned a few things. Here is a good somewhat advanced routine, that can handle more than one request at a time. It's fairly well commented:

    Code:
    function loadXmlHttp(url, id) {
    var f = this;
    f.xmlHttp = null;
    /*@cc_on @*/ // used here and below, limits try/catch to those IE browsers that both benefit from and support it
    /*@if(@_jscript_version >= 5) // prevents errors in old browsers that barf on try/catch & problems in IE if Active X disabled
    try {f.ie = window.ActiveXObject}catch(e){f.ie = false;}
    @end @*/
    if (window.XMLHttpRequest&&!f.ie||/^http/.test(window.location.href))
    f.xmlHttp = new XMLHttpRequest(); // Firefox, Opera 8.0+, Safari, others, IE 7+ when live - this is the standard method
    else if (/(object)|(function)/.test(typeof createRequest))
    f.xmlHttp = createRequest(); // ICEBrowser, perhaps others
    else {
    f.xmlHttp = null;
     // Internet Explorer 5 to 6, includes IE 7+ when local //
    /*@cc_on @*/
    /*@if(@_jscript_version >= 5)
    try{f.xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");}
    catch (e){try{f.xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");}catch(e){f.xmlHttp=null;}}
    @end @*/
    }
    if(f.xmlHttp != null){
    f.el = document.getElementById(id);
    f.xmlHttp.open("GET",url,true);
    f.xmlHttp.onreadystatechange = function(){f.stateChanged();};
    f.xmlHttp.send(null);
    }
    else alert('Your browser does not support AJAX!'); // substitute your desired request object unsupported code here
    }
    
    
    loadXmlHttp.prototype.stateChanged=function () {
    if (this.xmlHttp.readyState == 4 && (this.xmlHttp.status == 200 || !/^http/.test(window.location.href)))
    	this.el.innerHTML = this.xmlHttp.responseText;
    }
    Usage:

    Code:
    new loadXmlHttp('requested_url', 'target_element_id')
    Last edited by jscheuer1; 05-18-2008 at 12:05 AM. Reason: fix minor typo
    - John
    ________________________

    Show Additional Thanks: International Rescue Committee - Donate or: The Ocean Conservancy - Donate or: PayPal - Donate

  7. The Following User Says Thank You to jscheuer1 For This Useful Post:

    CiaNZ (05-17-2008)

  8. #17
    Join Date
    Jun 2005
    Location
    英国
    Posts
    11,878
    Thanks
    1
    Thanked 180 Times in 172 Posts
    Blog Entries
    2

    Default

    Commented it may be, but the formatting, I'm afraid, is severely lacking. I think I gave myself a headache trying to read it.

    Code:
    try {f.ie = window.ActiveXObject}catch(e){f.ie = false;}
    The statement in the try block is missing a semicolon.

    Code:
    catch (e){try{f.xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");}catch(e){f.xmlHttp=null;}}
    This line looks like it lost a fight with Packer — although, strangely, it's one of only a few places where the space-after-control-flow-keyword convention has been observed. Well... once.

    Code:
     // Internet Explorer 5 to 6, includes IE 7+ when local //
    Why is only this comment on a separate line?

    Code:
    if (this.xmlHttp.readyState == 4 && (this.xmlHttp.status == 200 || !/^http/.test(window.location.href)))
    	this.el.innerHTML = this.xmlHttp.responseText;
    I have to ask: why is this line the only one you've indented in the entire script?

    The code itself could do with some work, too. Things like:

    Code:
    var f = this;
    Why? And why 'f'?

    Code:
    if (/(object)|(function)/.test(typeof createRequest))
    Regular expressions are very expensive. They should be avoided for all but the most complex tasks. Certainly something this simple should not use them. There's also no need to capture — another performance hit.

    Code:
    /*@cc_on @*/
    CC has already been turned on earlier in the code — it doesn't magically turn itself off again. Proper formatting* would make it clear that the 'end' applies to the 'if', not to the 'cc_on'.

    Code:
    loadXmlHttp.prototype.stateChanged=function () {
    if (this.xmlHttp.readyState == 4 && (this.xmlHttp.status == 200 || !/^http/.test(window.location.href)))
    	this.el.innerHTML = this.xmlHttp.responseText;
    }
    innerHTML is, of course, entirely non-standard, and should be avoided wherever possible. It certainly shouldn't be used without a fallback. HTML is not a good format for data transfer anyway — it's semantic rather than structural, and the chances are that if one is transferring code like this, a lot of semantic or presentational code is being transferred that could more easily be stored in a template on the client-side. The required format for proper client-side rendering is rarely the optimal format for data passing and handling. You're also missing a semicolon after this statement. By making this function so specific, you're making code reŘse much harder. If I only want to get an XHR for some other purpose, I can see no way to do it but to copy-and-paste big chunks of the code.

    Additionally, why do we check every time a new instance is created? Surely Firefox isn't going to morph into ICEBrowser while we're not looking? I'll admit that I wouldn't put it past IE, but I hardly think we can cater to that possibility.

    *
    Code:
        // used here and below, limits try/catch to those IE browsers that both benefit from and support it
        /*@cc_on @*/
    
        // prevents errors in old browsers that barf on try/catch & problems in IE if Active X disabled
        /*@if (@_jscript_version >= 5)
            try {
                f.ie = window.ActiveXObject;
            } catch (e) {
                f.ie = false;
            }
        @end @*/
    Twey | I understand English | 日本語が分かります | mi jimpe fi le jbobau | mi esperanton komprenas | je comprends franšais | entiendo espa˝ol | t˘i Ýt hiểu tiếng Việt | ich verstehe ein bisschen Deutsch | beware XHTML | common coding mistakes | tutorials | various stuff | argh PHP!

  9. #18
    Join Date
    Mar 2005
    Location
    SE PA USA
    Posts
    29,074
    Thanks
    44
    Thanked 3,216 Times in 3,178 Posts
    Blog Entries
    12

    Default

    Mostly all good points, Twey. And I suppose I asked for this by referring back to older work of mine (which I still feel is very useful and more complete insofar as it actually goes than most comparable routines of its type in various script libraries).

    I especially like what you said about browsers not changing what method that they may use to secure the script's xmlHttp object, not even IE will do this as far as I can imagine, so it would be a performance improvement to only determine this once.

    Two of your comments though I would like to explain why I think they're not or may not be correct -

    About:

    Code:
    /*@cc_on @*/ // used here and below, limits try/catch to those IE browsers that both benefit from and support it
    /*@if(@_jscript_version >= 5) // prevents errors in old browsers that barf on try/catch & problems in IE if Active X disabled
    I used that syntax on mwinter's recommendation. It was his view at that time that not all IE browsers that respect @cc will automatically turn it on without the /*@cc_on @*/ coming first. At least that's how I understood his explanation as regards that.

    The other thing is innerHTML. Here I have two primary thoughts:

    1. For a basic point and shoot AJAX for content into an existing element, it's still very efficient and workable in most cases, and I'm not certain how it could be improved upon without a lot of added code, though the thought just occurred to me that there may be a way to clone the nodes - However, I seem to remember that requiring further testing and branching depending upon browser and being quite a bit more complex than one might first imagine.
    2. Since this is just the outline of a routine, what you do with the xmlHttp.responseText or other objects/properties of the xmlHttp object is really up to you or whoever uses the code. In other words, just because I used innerHTML in the exemplar is no reason why it must be used.


    In fact, I have already modified this routine numerous times for specific applications, some of these modifications make an entirely different use of the result.
    - John
    ________________________

    Show Additional Thanks: International Rescue Committee - Donate or: The Ocean Conservancy - Donate or: PayPal - Donate

  10. #19
    Join Date
    Jun 2005
    Location
    英国
    Posts
    11,878
    Thanks
    1
    Thanked 180 Times in 172 Posts
    Blog Entries
    2

    Default

    I used that syntax on mwinter's recommendation. It was his view at that time that not all IE browsers that respect @cc will automatically turn it on without the /*@cc_on @*/ coming first. At least that's how I understood his explanation as regards that.
    That's true — the browser requires this directive to know to process conditional compilation instructions. However, it's a directive completely separate from the @if you're using. Once it's on, it's on, and it doesn't change for the rest of the script. You can put it just once at the beginning of your script, and you'll be fine.

    I'm not certain how it could be improved upon without a lot of added code
    Don't be afraid of extra code. Javascript comes with notoriously few primitives, but it's a powerful enough language that just about all generic code can be created and stored safely in standalone libraries. As every high-level developer knows, if it's in a library, then it doesn't really exist Some tasks do intrinsically depend on other, separate tasks — for example, it's trivial, given a working parser for each desired image format, to write a procedure to find the colour of a specific pixel, but it would be horribly ugly and really quite difficult to build a semi-complete parser for each format into that procedure, and even worse to build in full, generic versions that nobody else can use.

    Since this is just the outline of a routine, what you do with the xmlHttp.responseText or other objects/properties of the xmlHttp object is really up to you or whoever uses the code.
    That's all very well for advanced users, and I myself may well use this code or something based on it in place of the minimalist XHR-creating code currently in my libraries, since it seems to support a good deal more old browsers than I usually bother with. Newbies, though, are likely to copy-and-paste verbatim, possibly without even understanding the code. If they do take note of what it's actually doing, then they'll probably look to it as a paradigm of good code, since it's written by an expert like yourself.
    Twey | I understand English | 日本語が分かります | mi jimpe fi le jbobau | mi esperanton komprenas | je comprends franšais | entiendo espa˝ol | t˘i Ýt hiểu tiếng Việt | ich verstehe ein bisschen Deutsch | beware XHTML | common coding mistakes | tutorials | various stuff | argh PHP!

  11. #20
    Join Date
    Mar 2005
    Location
    SE PA USA
    Posts
    29,074
    Thanks
    44
    Thanked 3,216 Times in 3,178 Posts
    Blog Entries
    12

    Default

    So, as far as replacing innerHTML in the exemplar, (keeping beginners in mind) what would you recommend?
    - John
    ________________________

    Show Additional Thanks: International Rescue Committee - Donate or: The Ocean Conservancy - Donate or: PayPal - Donate

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •