[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

[OT] Ajax: A New Approach to Web Applications

Curt Hibbs

2/25/2005 9:46:00 PM

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/...

Curt
36 Answers

Petite Abeille

2/25/2005 10:18:00 PM

0


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?

> You can read about it here:

And here too:

http://www.amconline.org/CPC...

There is a picture as well:

http://www.bettymills.com/store/images/product/CP...

Which raises an obvious question: does it cleans any better under its
new moniker?

Cheers

--
PA, Onnay Equitursay
http://alt.text...

Douglas Livingstone

2/25/2005 10:21:00 PM

0

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?
>

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&...

Douglas

ruby talk

2/25/2005 10:23:00 PM

0

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.
>
> 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

Curt Hibbs

2/25/2005 10:55:00 PM

0

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

Dion Almaer

2/25/2005 11:21:00 PM

0

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

Michael Neumann

2/25/2005 11:22:00 PM

0

Curt Hibbs wrote:
> 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).

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

Curt Hibbs

2/26/2005 12:03:00 AM

0

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 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.

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 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
>

David Heinemeier Hansson

2/26/2005 12:15:00 AM

0

> 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.basec... -- Web-based Project Management
http://www.rubyon... -- Web-application framework for Ruby
http://www.loudthi... -- Broadcasting Brain

James Britt

2/26/2005 12:42:00 AM

0

Curt Hibbs wrote:
>>
>>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.

I'd rather not see anything tied to Rails, but an framework-independent
lib that Nitrons and Wee'ers and Railers and whomever can adapt for
their needs.

What I have right now (and mind you, most of this is mostly hooking
together the good work of other people) lets you include a module in a
WEBrick server and register services/classes. These services are then
callable using JSON-RPC from a JavaScript client using a nice JavaScript
lib designed for some Java stuff I came across.

The client code you write yourself never messes with JSON or
XmlHttpRequest. It calls server-side objects using their method names
as i they were local objects, and gets back JavaScript objects courtesy
of JSON serialization.

The server-side code need not know anything about JSON or JavaScript.
The objects returned to the client from server code are serialized using
Florian's code.

Anyway, with any luck I'll have enough cleaned up such that I can start
a RubyForge project this weekend.

I've only been using it via WEBrick, so I need to see what one has to do
to get it to work with CGI, etc. See that it isn't coupled to any
particular server tech.


James

Curt Hibbs

2/26/2005 12:56:00 AM

0

James Britt wrote:
>
> Curt Hibbs wrote:
> >>
> >>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.
>
> I'd rather not see anything tied to Rails, but an framework-independent
> lib that Nitrons and Wee'ers and Railers and whomever can adapt for
> their needs.

That would be even better!

> What I have right now (and mind you, most of this is mostly hooking
> together the good work of other people) lets you include a module in a
> WEBrick server and register services/classes. These services are then
> callable using JSON-RPC from a JavaScript client using a nice JavaScript
> lib designed for some Java stuff I came across.
>
> The client code you write yourself never messes with JSON or
> XmlHttpRequest. It calls server-side objects using their method names
> as i they were local objects, and gets back JavaScript objects courtesy
> of JSON serialization.
>
> The server-side code need not know anything about JSON or JavaScript.
> The objects returned to the client from server code are serialized using
> Florian's code.
>
> Anyway, with any luck I'll have enough cleaned up such that I can start
> a RubyForge project this weekend.

I'm so thrilled... really! And it looks like David has an interest (and some
existing code) as well. Once you get it up on RubyForge then, as David said,
we can "huddle around this".

Curt

> I've only been using it via WEBrick, so I need to see what one has to do
> to get it to work with CGI, etc. See that it isn't coupled to any
> particular server tech.
>
>
> James
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 266.4.0 - Release Date: 2/22/2005
>