Inline. "James Bennett" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > >Many so-called "AJAX libraries" are as heavy on the "visual DHTML
"So-called" by whom? >For example, Rails includes an "AJAX library" called Prototype; this >library provides "AJAX" functionality in that it delivers a facility >for making asynchronous server calls from the client via JavaScript, >but it also provides a number of easily-used visual DHTML effects. What "easily-used visual DHTML effects" are provided by Prototype? It is good to learn from knowledgeable people. Discussions with them are priceless! >Is this a conceptual confusion on the part of those who refer to these >as "AJAX libraries"? Possibly. Is it nonetheless extremely convenient >to have tight integration between the code which talks to the server >and the code which displays the retrieved resources? Absolutely. Does Care to give some examples? I always thought that it is not necessary but I am frequently wrong. >this mean that "AJAX libraries" will probably continue to include >visual DHTML effects for the foreseeable future? Yes. I see now --- just like so-called Prototype does. >And XMLHttpRequest is not a visual effect; a visual effect causes a >visible change in the page. But an XMLHttpRequest, by itself, does no Now you are straying from your previous definition. Don't give up! Stay the course! >such thing; it simply retrieves a resource from a server. Only when >combined with DHTML techniques to present the returned resource does a >"visual effect" take place. I see my mistake now. It should be combined. If it is not combined, it is just "AJAX effect". I guess the big picture is: 1) So-called "AJAX library" produces so-called "AJAX effect". 2) Server produces "Python effect" in response (it has to have "AJAX in the core" for that). 3) It causes number of "visual effects" in a browser of unsuspected user, if "AJAX effect" was combined. I hope now I got it right. Thanks, Eugene
