James Bennett wrote:
> 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.
To be specific Rails includes script.aculo.us which itself uses
Prototype.
its script.aculou.us that is making candy out of simple sugar.
and then what rails offers is a some form building functions that
simply glue together some common paradigms of ajax usage.
<div id="time_div">
I don't have the time, but
<%= link_to_remote( "click here",
:update => "time_div",
:url =>{ :action => :say_when }) %>
and I will look it up.
</div>
so what django could offer is a library of template filters /
functions that does some of these common paradigms and makes them
simpler to use.
so its possible to support multiple javascript libraries, each with a
different set of server side glue functions.
> 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
> this mean that "AJAX libraries" will probably continue to include
> visual DHTML effects for the foreseeable future? Yes.
yep, agreed.
and as has been pointed out, the asynch part of these libraries is only
a small part of what they offer. they are client side "getting things
done" frameworks, just as django is server side "getting things done".
what "ajax support" means then is glue to hook the two up.
