[OT] Ajax: A New Approach to Web Applications

ruby-talk
21

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?

If they do, I'm not aware of it.

As far as I know they support continuation-based control flow so that your
server side app can be written with more of a sequential control flow. But
the client side browser still refreshes its display with a sequence of
discreet web pages.

What we are talking about with Ajax support is a component on a web page can
talk to the server to get new data and then redisplay itself *without* the
rest of the displayed web page being affected or touched in any way.

Curt

22

It seems as if several of us have written this at some point. I wrote
mine completely in Javascript and called it Mediate. But will this
ever have anything to do with Ruby? It seems to be all Javascript and
XML (mine was Javascript and XHTML)

I'm not knocking it with Ruby, I'm just not seeing a connection. Any
enlightenment?

Drew

···

On Mon, 21 Mar 2005 03:19:23 +0900, vruz <horacio.lopez@gmail.com> wrote:

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

23

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

24

Jamis Buck wrote:

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.

That's also were the problems come in, too. In the case of design patterns, many people have the habit of using the short-hand name as a stand-in for real understanding. Different people may have different takes on the Foo pattern, but they don't realize they are talking past each other because they both assume the other people use the term the same way as they do.

"Ajax" carries an important assumption: XML. But, despite the name, XMLHttpRequest can send any text you like. It is often more appropriate to use, say JSON, or unformatted text. While some might argue that the term is meant to encompass more than just the use of XML, the very name tends to to encourage people to make what could be suboptimal choices, choices that that would be better served by thinking about each of the technologies involved.

It's like LAMP; a cute moniker for a type of Web development that favors, by its name, some less-than-the-best tools. Makes it easy to sum up a general idea, but doesn't always serve the best interests of developers.

Given that XMLHttpRequest can send any text, I've wondered if there would be any advantage to sending YAML.

It lends itself to the acronym AJYL, which is reasonably clever, but I'm not sure there are any advantages over using JSON. JSON is nice because client code is sent serialized JavaScript objects; the deserialization by the client is trivial. It would be be harder with YAML, but the YAML data types (I think) are more robust than what is offered in JSON. The server code would have a better time handling YAML than JSON. It would be AJYLR.

Anyway, hanging a name on something is useful to be sure, but abstractions by definition mean loss of detail, and the details here may be critical.

James

25

Jamis Buck wrote:

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.

Yes, that is precisely why I made the original post that started this
thread -- I was thrilled to find a name for this.

Curt

26

I know of a project for PHP working on this called JPSpan.

http://jpspan.sourceforge.net/wiki/doku.php

It would be nice to have a JRSpan :wink: Will have to take a closer look at Ajax.

Douglas

···

On Sun, 27 Feb 2005 09:33:13 +0900, Curt Hibbs <curt@hibbs.com> wrote:

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?

If they do, I'm not aware of it.

As far as I know they support continuation-based control flow so that your
server side app can be written with more of a sequential control flow. But
the client side browser still refreshes its display with a sequence of
discreet web pages.

What we are talking about with Ajax support is a component on a web page can
talk to the server to get new data and then redisplay itself *without* the
rest of the displayed web page being affected or touched in any way.

Curt

27

It seems as if several of us have written this at some point. I wrote
mine completely in Javascript and called it Mediate. But will this
ever have anything to do with Ruby? It seems to be all Javascript and
XML (mine was Javascript and XHTML)

I'm not knocking it with Ruby, I'm just not seeing a connection. Any
enlightenment?

Maybe someone wants to develop Ajax-like apps for Ruby ?

If so, James Britt has recently published a pretty neat library that's
related to this concept.

It seems some other people call this technique "JSON", it's not XML
based but it basically serves for the purpose of transparently
transferring data structures between a language sitting on the httpd
and client side javascript.

http://rubyforge.org/projects/orbjson/

28

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

29

AJYL would be pronounced like Agile, and that word is already taken in the programming namespace.

Francis Hwang

···

On Feb 26, 2005, at 10:20 AM, James Britt wrote:

It lends itself to the acronym AJYL, which is reasonably clever, but I'm not sure there are any advantages over using JSON.

30

Jamis Buck wrote:
>
>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.

That's also were the problems come in, too. In the case of design
patterns, many people have the habit of using the short-hand name as a
stand-in for real understanding. Different people may have different
takes on the Foo pattern, but they don't realize they are talking past
each other because they both assume the other people use the term the
same way as they do.

I agree. The name is not a replacement for real understanding, but no
matter *what* you call it, people can (and will) misunderstand you.
It's just the ambiguous nature of natural language.

"Ajax" carries an important assumption: XML. But, despite the name,
XMLHttpRequest can send any text you like. It is often more appropriate
to use, say JSON, or unformatted text. While some might argue that the
term is meant to encompass more than just the use of XML, the very name
tends to to encourage people to make what could be suboptimal choices,
choices that that would be better served by thinking about each of the
technologies involved.

I disgree that the term "Ajax" assumes XML. True, the acronym that it
was formed from includes XML, but the name itself is less XML-specific
than XMLHTTPRequest--the other term people use to describe this
technology.

True, Mr. Garrett's particular definition ties Ajax to XML. In that,
I take issue with his article. But the fact that he's given the
technique a simple, easy-to-remember (and easy to pronounce!) name is
a huge step forward, IMO.

I frankly don't care what term people use, as long as they define it
and it becomes widely used. Without a good definition, people will (as
you said) talk past each other. Without wide use, no one will know
what you are talking about.

"Ajax" is nice because it is well-defined, and it is gaining wider
usage. It is unfortunate--but not insurmountable--that Mr. Garrett's
definition includes XML. If enough people write about it and use it in
non-XML contexts, the term can eventually come to mean even non-XML
usages of the technology.

- Jamis

···

On 00:20 Sun 27 Feb , James Britt wrote:

--
Jamis Buck
jamis_buck@byu.edu
http://jamis.jamisbuck.org
------------------------------
"I am Victor of Borge. You will be assimil-nine-ed."

31

Or you could use JAYL and JAYLR. Not that I'm locked into those...

···

On Sun, 27 Feb 2005 00:20:59 +0900, James Britt <jamesUNDERBARb@neurogami.com> wrote:

Jamis Buck wrote:
>
It lends itself to the acronym AJYL, which is reasonably clever, but I'm
not sure there are any advantages over using JSON. JSON is nice because
client code is sent serialized JavaScript objects; the deserialization
by the client is trivial. It would be be harder with YAML, but the YAML
data types (I think) are more robust than what is offered in JSON. The
server code would have a better time handling YAML than JSON. It would
be AJYLR.

--
Bill Guindon (aka aGorilla)

32

vruz wrote:

It seems as if several of us have written this at some point. I wrote
mine completely in Javascript and called it Mediate. But will this
ever have anything to do with Ruby? It seems to be all Javascript and
XML (mine was Javascript and XHTML)

I'm not knocking it with Ruby, I'm just not seeing a connection. Any
enlightenment?

Maybe someone wants to develop Ajax-like apps for Ruby ?

If so, James Britt has recently published a pretty neat library that's
related to this concept.

It seems some other people call this technique "JSON", it's not XML
based but it basically serves for the purpose of transparently
transferring data structures between a language sitting on the httpd
and client side javascript.

http://rubyforge.org/projects/orbjson/

There are some distinctions between using JSON-RPC (as with Orbjson) and AJAX. JSON-RPC certainly lets you pass XML around, but one important detail is that, like XML-RPC, you can also transfer complex objects, serialized as text. Client and server need not be concerned with the wire protocol, and can (sort of) behave as if all object method invocations are local.

Another distinction is that some people using the XMLHttpRequest object specifically for XML are also loading and applying XSLT to transform the XML. This is not explicitly provided for in Orbjson, though it can readily be used to acquire the XML and XSLT from the server in a reasonably transparent fashion; after that, it's up to the client to use the data as it sees fit.

BTW, I just posted to the Rails mailing list a walk-though of how to use Orbjson in Rails. It's quite simple; Orbjson makes it very easy to expose JSON-RPC services from Rails applications.

James

···

--

http://catapult.rubyforge.com
http://orbjson.rubyforge.com
http://ooo4r.rubyforge.com
http://www.jamesbritt.com

33

It doesn't have to be Rails specific, of course. However, I think it would
be nice to get all the ideas out there for both client side, and server side
handling.

It feels like a lot of people are running around with their own set of .js,
and "rules". I think we have a chance to take all of the good ideas, come up
with a great set, and work together to allow us to make developers lives
easier in the world of Ajax too (which other communities try to get
organizations together to specify it :wink:

Cheers,

Dion

···

-----Original Message-----
From: Curt Hibbs [mailto:curt@hibbs.com]
Sent: Friday, February 25, 2005 6:56 PM
To: ruby-talk ML
Subject: Re: [OT] Ajax: A New Approach to Web Applications

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

34

Francis Hwang wrote:

It lends itself to the acronym AJYL, which is reasonably clever, but I'm not sure there are any advantages over using JSON.

AJYL would be pronounced like Agile, and that word is already taken in the programming namespace.

That's the point. Different spelling, same principle.

James

···

On Feb 26, 2005, at 10:20 AM, James Britt wrote:

35

Jamis Buck wrote:

"Ajax" carries an important assumption: XML. But, despite the name, XMLHttpRequest can send any text you like. It is often more appropriate to use, say JSON, or unformatted text. While some might argue that the term is meant to encompass more than just the use of XML, the very name tends to to encourage people to make what could be suboptimal choices, choices that that would be better served by thinking about each of the technologies involved.

I disgree that the term "Ajax" assumes XML. True, the acronym that it
was formed from includes XML, but the name itself is less XML-specific
than XMLHTTPRequest--the other term people use to describe this
technology.

I think this just proves my point. My understanding of 'Ajax' is the use of a JavaScript client-request object to pass around XML, with the client using XSLT to transform it to more useful data.

If it isn't XML, it isn't Ajax.

I'm unfamiliar with people using "XMLHTTPRequest" to refer to a technique or technology per se , but as simply the main object involved.

Of course, *that* name is a misnomer as well, but 'Ajax' just compounds the problem.

James

···

On 00:20 Sun 27 Feb , James Britt wrote:

36

There are some distinctions between using JSON-RPC (as with Orbjson) and
AJAX. JSON-RPC certainly lets you pass XML around, but one important
detail is that, like XML-RPC, you can also transfer complex objects,
serialized as text. Client and server need not be concerned with the
wire protocol, and can (sort of) behave as if all object method
invocations are local.

Thanks for the clarification, James.

cheers,
                         vruz

37

Hear Hear (or is it Here Here ?)!!

Either way, I've been playing around with Orb-JSON and I've been making some pretty
cool things (to me at least). After reading the XMLHttpRequest book for Rails, I think
that with some relatively minor tweaking one could create an entire mini-framework
for this kind of 'Ajax' (AJYL | JYLA | ... )/Rails design.

Also, as was suggested, why don't we just start a Rubyforge project for useful JavaScript
stuff that can be integrated/useful for users of the popular Ruby web frameworks.

......

Ok, I just submitted a rubyforge project for this. It should be up soon.
May the J-A-X-A rain supreme!

-Shalev

···

On Feb 25, 2005, at 11:44 PM, Dion Almaer wrote:

It doesn't have to be Rails specific, of course. However, I think it would
be nice to get all the ideas out there for both client side, and server side
handling.

It feels like a lot of people are running around with their own set of .js,
and "rules". I think we have a chance to take all of the good ideas, come up
with a great set, and work together to allow us to make developers lives
easier in the world of Ajax too (which other communities try to get
organizations together to specify it :wink:

Cheers,

Dion

-----Original Message-----
From: Curt Hibbs [mailto:curt@hibbs.com]
Sent: Friday, February 25, 2005 6:56 PM
To: ruby-talk ML
Subject: Re: [OT] Ajax: A New Approach to Web Applications

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