I always have trouble remembering whether its HttpXmlRequest, or
XmlHttpRequest. In either case, its a poor moniker for such a promising web
app technique.
Well, it turns out someone *has* given it a name: Ajax (for Asynchronous
JavaScript + XML). You can read about it here:
http://www.adaptivepath.com/publications/essays/archives/000385.php
Curt
Well, it turns out someone *has* given it a name: Ajax (for Asynchronous
JavaScript + XML).
Hmmm... is not Ajax a brand of detergent or such?
You can read about it here:
And here too:
http://www.amconline.org/CPC_04969.htm
There is a picture as well:
http://www.bettymills.com/store/images/product/CPAG2504.JPG
Which raises an obvious question: does it cleans any better under its new moniker?
Cheers
I always have trouble remembering whether its HttpXmlRequest, or
XmlHttpRequest. In either case, its a poor moniker for such a promising web
app technique.
It's not a technique per se, it's a the name of a JavaScript object
for doing sync/async calls from the browser to to server. Been around
since the last century, first as part of Internet Explorer, then
Mozilla.
Well, it turns out someone *has* given it a name: Ajax (for Asynchronous
JavaScript + XML). You can read about it here:
What struck me about this article was a) it's sort of pretentious,
unless there is some reasonably robust dev lib to go with it, since
people have been doing this for some time now, and b) you can't tell,
as there appears to be no code released, except what you can decipher
from your browser when poking around "Google suggest".
BTW, I've done some work on a JSON-RPC ORB thing (called Roy, after
Roy Orbison) that builds off of the Ruby JSON-parsing code from
Florain Frank. It makes this sort of JavaScript Xml request stuff
with Ruby server-code quite trivial. You register services using
Needle and call them from the browser.
I need to gem it up for a nice release so people can find bugs and stuff.
James Britt
James
On Sat, 26 Feb 2005 06:45:34 +0900, Curt Hibbs <curt@hibbs.com> wrote:
HA!
In 2000 the company I worked for had this sort of thing at its core. WebHelp used to compete with Ask Jeeves, and be one of the top 10 search engines. At the core of the technology was asynchronous Javascript. At one point a team I lead built an app using this technology that allowed two users on the internet to fill out a form together. We had to do some evil things to get around the Javascript security model to get this working, but the end result was pretty neat. Doing this showed me how incredibly powerful Javascript was as a language. Unfortunately, it also showed me how incredibly ugly it is as a syntax.
4.5 years later, it's about time someone took this and ran with it!
Ben
Unless they have also trademarked there name for software, I dout it
would be a problem. Ajax (pronounced Ayax) is also the name of a Dutch
footbal team: http://images.google.com/images?q=ajax%20nl&hl=en&lr=&c2coff=1&safe=off&sa=N&tab=wi
Douglas
On Sat, 26 Feb 2005 07:18:01 +0900, PA <petite.abeille@gmail.com> wrote:
Hmmm... is not Ajax a brand of detergent or such?
James G. Britt wrote:
> I always have trouble remembering whether its HttpXmlRequest, or
> XmlHttpRequest. In either case, its a poor moniker for such a
promising web
> app technique.It's not a technique per se, it's a the name of a JavaScript object
for doing sync/async calls from the browser to to server. Been around
since the last century, first as part of Internet Explorer, then
Mozilla.
I know, but it hasn't gotten much attention until Google wowed us with
Gmail, Google Maps, and Google Suggest. Ta-Da Lists uses this too, but its a
one-off solution specific to that web app.
> Well, it turns out someone *has* given it a name: Ajax (for Asynchronous
> JavaScript + XML). You can read about it here:What struck me about this article was a) it's sort of pretentious,
unless there is some reasonably robust dev lib to go with it, since
people have been doing this for some time now, and b) you can't tell,
as there appears to be no code released, except what you can decipher
from your browser when poking around "Google suggest".BTW, I've done some work on a JSON-RPC ORB thing (called Roy, after
Roy Orbison) that builds off of the Ruby JSON-parsing code from
Florain Frank. It makes this sort of JavaScript Xml request stuff
with Ruby server-code quite trivial. You register services using
Needle and call them from the browser.I need to gem it up for a nice release so people can find bugs and stuff.
Nice!
What I think we'll see someday, a new set of smart components integrated
into web app frameworks that render GUI components in the browser that
automatically know how to talk to their corresponding server-side objects
for behind-the-scenes data transfer. This would make it much easier to build
web apps whose GUI is as responsive as a desktop app (well... at least
closer).
I'd love to see someone do this with Rails.
Curt
On Sat, 26 Feb 2005 06:45:34 +0900, Curt Hibbs <curt@hibbs.com> wrote:
> Well, it turns out someone *has* given it a name: Ajax (for
> Asynchronous
> JavaScript + XML).
Hmmm... is not Ajax a brand of detergent or such?
Is not Linux a brand of detergent?
http://oriol.joor.net/blog-dev/?itemid=1564
(note: this website is written in Català)
And it's been popularly known for over five years. (I've seen a different
photo of it five years ago)
Which raises an obvious question: does it cleans any better under its
new moniker?
I have a question for you. Do you also know all the other Ajaxes, and why
not phone Colgate-Palmolive and tell them to change the name of their
product? I mean, here's a list for you:
On Sat, 26 Feb 2005, PA wrote:
On Feb 25, 2005, at 22:45, Curt Hibbs wrote:
_____________________________________________________________________
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
PA ha scritto:
Well, it turns out someone *has* given it a name: Ajax (for Asynchronous
JavaScript + XML).Hmmm... is not Ajax a brand of detergent or such?
well, in the last hours I read this news in various forms on many sites and I thought, in turn:
- detergent
- amsterdam's football club
- greek hero
I hate when people try to name existing things with new cooly names.
On Feb 25, 2005, at 22:45, Curt Hibbs wrote:
Old discussion, but regarding whether Ajax is a concept that deserves a new name or not:
http://ln.hixie.ch/?start=1111339822&count=1
"And now everyone is talking about Ajax as if it's some sort of new technology, despite the fact that people have been using it for years."
f.
I have been doing a lot of work w/ Ajax, and the server side action piece.
I think that Rails is perfectly suited for this task, and am really looking
forward to taking some of our work and building our Rails based components.
A web developer shouldn't have to know much to switch their app from
traditional Big Request -> Big Response Rendering to Ajax.
This is exciting stuff, but, of course, we need to be wary about going hog
wild and making everything Ajax and freaking out our users, who have learned
over many years on the web that the SUBMIT button is king 
Dion
Ps. Maybe there should be a sub-project of Rails for components like this.
There is a core framework piece, where you can specify standard XML
responses which the client side grabs as a DOM and does certain things (runs
Javascript functions, twiddles content in the DOM, adds into the DOM, etc
etc). I would love to work on this with people.
-----Original Message-----
From: Curt Hibbs [mailto:curt@hibbs.com]
Sent: Friday, February 25, 2005 4:55 PM
To: ruby-talk ML
Subject: Re: [OT] Ajax: A New Approach to Web Applications
James G. Britt wrote:
On Sat, 26 Feb 2005 06:45:34 +0900, Curt Hibbs <curt@hibbs.com> wrote:
> I always have trouble remembering whether its HttpXmlRequest, or
> XmlHttpRequest. In either case, its a poor moniker for such a
promising web
> app technique.It's not a technique per se, it's a the name of a JavaScript object
for doing sync/async calls from the browser to to server. Been around
since the last century, first as part of Internet Explorer, then
Mozilla.
I know, but it hasn't gotten much attention until Google wowed us with
Gmail, Google Maps, and Google Suggest. Ta-Da Lists uses this too, but its a
one-off solution specific to that web app.
> Well, it turns out someone *has* given it a name: Ajax (for
> Asynchronous JavaScript + XML). You can read about it here:What struck me about this article was a) it's sort of pretentious,
unless there is some reasonably robust dev lib to go with it, since
people have been doing this for some time now, and b) you can't tell,
as there appears to be no code released, except what you can decipher
from your browser when poking around "Google suggest".BTW, I've done some work on a JSON-RPC ORB thing (called Roy, after
Roy Orbison) that builds off of the Ruby JSON-parsing code from
Florain Frank. It makes this sort of JavaScript Xml request stuff
with Ruby server-code quite trivial. You register services using
Needle and call them from the browser.I need to gem it up for a nice release so people can find bugs and stuff.
Nice!
What I think we'll see someday, a new set of smart components integrated
into web app frameworks that render GUI components in the browser that
automatically know how to talk to their corresponding server-side objects
for behind-the-scenes data transfer. This would make it much easier to build
web apps whose GUI is as responsive as a desktop app (well... at least
closer).
I'd love to see someone do this with Rails.
Curt
Curt Hibbs wrote:
James G. Britt wrote:
I always have trouble remembering whether its HttpXmlRequest, or
XmlHttpRequest. In either case, its a poor moniker for such apromising web
app technique.
It's not a technique per se, it's a the name of a JavaScript object
for doing sync/async calls from the browser to to server. Been around
since the last century, first as part of Internet Explorer, then
Mozilla.I know, but it hasn't gotten much attention until Google wowed us with
Gmail, Google Maps, and Google Suggest. Ta-Da Lists uses this too, but its a
one-off solution specific to that web app.Well, it turns out someone *has* given it a name: Ajax (for Asynchronous
JavaScript + XML). You can read about it here:What struck me about this article was a) it's sort of pretentious,
unless there is some reasonably robust dev lib to go with it, since
people have been doing this for some time now, and b) you can't tell,
as there appears to be no code released, except what you can decipher
from your browser when poking around "Google suggest".BTW, I've done some work on a JSON-RPC ORB thing (called Roy, after
Roy Orbison) that builds off of the Ruby JSON-parsing code from
Florain Frank. It makes this sort of JavaScript Xml request stuff
with Ruby server-code quite trivial. You register services using
Needle and call them from the browser.I need to gem it up for a nice release so people can find bugs and stuff.
Nice!
What I think we'll see someday, a new set of smart components integrated
into web app frameworks that render GUI components in the browser that
automatically know how to talk to their corresponding server-side objects
for behind-the-scenes data transfer. This would make it much easier to build
web apps whose GUI is as responsive as a desktop app (well... at least
closer).
Hm, in Wee, this should be pretty easy (if someone can point me to an easy to use XxlHttpRequest client library, I'll try this out):
# kind of pseudo-code... these things are not yet implemented
class LiveUpdateCounter < Wee::Component
def initialize(initial_count = 0)
super()
@count = initial_count
end
def render
render_counter
r.anchor.liveupdate_callback(:inc).with('++')
end
def inc
@count += 1
render_counter
end
def render_counter
r.div.id('counter').with(@count)
end
end
Another interesting thing would be to observe the @count value and trigger render_counter automatically... So that you can write:
def initialize
@count = Observable.new(0).on_change { render_counter }
end
def render
render_counter # or @count.update
r.anchor.liveupdate_callback(:inc).with('++')
end
def inc
@count.value += 1
end
Regards,
Michael
On Sat, 26 Feb 2005 06:45:34 +0900, Curt Hibbs <curt@hibbs.com> wrote:
Mathieu Bouchard ha scritto:
Which raises an obvious question: does it cleans any better under its new moniker?
I have a question for you. Do you also know all the other Ajaxes, and why
not phone Colgate-Palmolive and tell them to change the name of their
product? I mean, here's a list for you:
well, the point is that people have been using XmlHTTPRequest for more than 5 years, IIRC, so this kind of "I'll name my discovering" sounds somewhat inappropriate.
Hi,
Am Samstag, 26. Feb 2005, 16:20:01 +0900 schrieb gabriele renzi:
PA ha scritto:
>On Feb 25, 2005, at 22:45, Curt Hibbs wrote:
>>Well, it turns out someone *has* given it a name: Ajax (for Asynchronous
>>JavaScript + XML).
>
>Hmmm... is not Ajax a brand of detergent or such?- detergent
- amsterdam's football club
- greek hero
I further know of dogs named Ajax.
Bertram
--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de
* Curt Hibbs <curt@hibbs.com> [0255 22:55]:
What I think we'll see someday, a new set of smart components integrated
into web app frameworks that render GUI components in the browser that
automatically know how to talk to their corresponding server-side objects
for behind-the-scenes data transfer. This would make it much easier to build
web apps whose GUI is as responsive as a desktop app (well... at least
closer).
Isn't this what Borges and Seaside do?
Wee sortof does too, from a brief look at the videos someone posted the other
day.
--
'Everybody's a jerk. You, me, this jerk.'
-- Bender
Rasputin :: Jack of All Trades - Master of Nuns
Hixie's Natural Log: Call an apple an apple
"And now everyone is talking about Ajax as if it's some sort of new
technology, despite the fact that people have been using it for years."
Having implemented similar stuff myself at work 5 years ago I have to
say I agree.
Sometimes good ideas aren't perceived as such if there's not a big name behind.
(even by open source supporters)
Dion Almaer wrote:
I have been doing a lot of work w/ Ajax, and the server side action piece.
I think that Rails is perfectly suited for this task, and am
really looking
forward to taking some of our work and building our Rails based
components.A web developer shouldn't have to know much to switch their app from
traditional Big Request -> Big Response Rendering to Ajax.This is exciting stuff, but, of course, we need to be wary about going hog
wild and making everything Ajax and freaking out our users, who
have learned
over many years on the web that the SUBMIT button is kingDion
Ps. Maybe there should be a sub-project of Rails for components like this.
There is a core framework piece, where you can specify standard XML
responses which the client side grabs as a DOM and does certain
things (runs
Javascript functions, twiddles content in the DOM, adds into the DOM, etc
etc). I would love to work on this with people.
I don't know of anyone who is working on this in Rails (if I'm wrong, maybe
this statement will bring them out into the light!).
You should go ahead and create a RubyForge project for this and then invite
other interested developers to join you. I would do so myself if I weren't
already juggling too many Ruby "balls" along with my day job.
Curt
-----Original Message-----
From: Curt Hibbs [mailto:curt@hibbs.com]
Sent: Friday, February 25, 2005 4:55 PM
To: ruby-talk ML
Subject: Re: [OT] Ajax: A New Approach to Web ApplicationsJames G. Britt wrote:
>
> On Sat, 26 Feb 2005 06:45:34 +0900, Curt Hibbs <curt@hibbs.com> wrote:
> > I always have trouble remembering whether its HttpXmlRequest, or
> > XmlHttpRequest. In either case, its a poor moniker for such a
> promising web
> > app technique.
>
>
> It's not a technique per se, it's a the name of a JavaScript object
> for doing sync/async calls from the browser to to server. Been around
> since the last century, first as part of Internet Explorer, then
> Mozilla.I know, but it hasn't gotten much attention until Google wowed us with
Gmail, Google Maps, and Google Suggest. Ta-Da Lists uses this
too, but its a
one-off solution specific to that web app.> > Well, it turns out someone *has* given it a name: Ajax (for
> > Asynchronous JavaScript + XML). You can read about it here:
>
> What struck me about this article was a) it's sort of pretentious,
> unless there is some reasonably robust dev lib to go with it, since
> people have been doing this for some time now, and b) you can't tell,
> as there appears to be no code released, except what you can decipher
> from your browser when poking around "Google suggest".
>
> BTW, I've done some work on a JSON-RPC ORB thing (called Roy, after
> Roy Orbison) that builds off of the Ruby JSON-parsing code from
> Florain Frank. It makes this sort of JavaScript Xml request stuff
> with Ruby server-code quite trivial. You register services using
> Needle and call them from the browser.
>
> I need to gem it up for a nice release so people can find bugs
and stuff.Nice!
What I think we'll see someday, a new set of smart components integrated
into web app frameworks that render GUI components in the browser that
automatically know how to talk to their corresponding server-side objects
for behind-the-scenes data transfer. This would make it much
easier to build
web apps whose GUI is as responsive as a desktop app (well... at least
closer).I'd love to see someone do this with Rails.
Curt
Maybe there should be a sub-project of Rails for components like this.
There is a core framework piece, where you can specify standard XML
responses which the client side grabs as a DOM and does certain things (runs
Javascript functions, twiddles content in the DOM, adds into the DOM, etc
etc). I would love to work on this with people.
I've started this in the small with my current Rails project (code named Honey). At first, it's just about bundling a nice xmlhr javascript library and then providing cool integration through helpers. But I'm very interested in additional help here. So let's huddle around this.
--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain
Innapropriate or not, it's certainly easier to talk about "Ajax" than
"that technique that uses XMLHttpRequest to send asynchronous requests
to the server via Javascript without having to reload the page."
That's the point, I think--not that something new has been discovered,
but that a label has been given to that thing to make it easier to
discuss. I'd even go so far as to posit that the reason Ajax has taken
so long to really start gaining attention is because there's not been
an easy way to talk about it.
Think about design patterns. Most people agree that these are good
things. However, most of these patterns are not new--it's just that
they've recently been given names to facilitate discussion about them.
When you give something a name, you can define and then hide an entire
host of assumptions behind it. That's where the value comes from.
- Jamis
On 16:25 Sat 26 Feb , gabriele renzi wrote:
Mathieu Bouchard ha scritto:
>>Which raises an obvious question: does it cleans any better under its
>>new moniker?
>
>
>I have a question for you. Do you also know all the other Ajaxes, and why
>not phone Colgate-Palmolive and tell them to change the name of their
>product? I mean, here's a list for you:
>
> Ajax - Wikipediawell, the point is that people have been using XmlHTTPRequest for more
than 5 years, IIRC, so this kind of "I'll name my discovering" sounds
somewhat inappropriate.
--
Jamis Buck
jamis_buck@byu.edu
http://jamis.jamisbuck.org
------------------------------
"I am Victor of Borge. You will be assimil-nine-ed."
Dick Davies wrote:
* Curt Hibbs <curt@hibbs.com> [0255 22:55]:
What I think we'll see someday, a new set of smart components integrated
into web app frameworks that render GUI components in the browser that
automatically know how to talk to their corresponding server-side objects
for behind-the-scenes data transfer. This would make it much easier to build
web apps whose GUI is as responsive as a desktop app (well... at least
closer).Isn't this what Borges and Seaside do?
Wee sortof does too, from a brief look at the videos someone posted the other
day.
Yeah, Wee can do that in the same way as Seaside or Borges. It supports continuation based web-applications, but it's not turned on by default, due to possible non-reliable memory behaviour. Nevertheless, you don't need continuations for the kind of application you're talking about. GUIs are event-driven as well and do not have a sequential flow (they are not "modal").
Regards,
Michael
la, 2005-02-26 kello 01:22, Michael Neumann kirjoitti:
> Nice!
>
> What I think we'll see someday, a new set of smart components integrated
> into web app frameworks that render GUI components in the browser that
> automatically know how to talk to their corresponding server-side objects
> for behind-the-scenes data transfer. This would make it much easier to build
> web apps whose GUI is as responsive as a desktop app (well... at least
> closer).Hm, in Wee, this should be pretty easy (if someone can point me to an
easy to use XxlHttpRequest client library, I'll try this out):
Hi, if you're interested, I wrote some XmlHttpRequest stuff
(live-updating search + content divs + editing) for a website project.
Refactoring it into something more usable now. Of course, if there's a
good ready-made lib, that should preferably be used instead 
http://dark.fhtr.org/js_xml/ -- works in Firefox/Mozilla, Konqueror
fails, haven't tested in others
Anyhow, it demonstrates the concepts involved. Basically, override
link/form default eventhandler, define a callback function to be called
when the request is ready and make it update the dom using the retrieved
data.
Ilmari Heikkinen