AJAX

[Daniel Simpson]

Not all users have browsers that support AJAX. Is it better to leave those users out, stick with non-ajax, or somehow give them the option? Also, doesn't ajax introduce a lot of overhead processing that may slow down a server?

[Christophe Verré]

Moreover, it's been a real pain in the past to support many browsers, especially when using Javascript. I'm wondering if this wound will open up again when using Ajax.

"if (IE 6.0) ... else if (IE 5.5) ... else and so on"

[Christian Gross]

For the browsers that do not support Ajax you implement the Permutations pattern. The Permutations pattern is an implementation of the separation of concerns (Resource and Representation) as defined by REST. The idea behind the Permutations pattern is to offer the content that a client is interested in and can process.

The problem with most server side frameworks is that it is difficult to implement the Permutations pattern because we are used to coding to a URL. For example, let's say we are referencing the HTML page

http://mydomain.com/content/page.jsp

The reference to page.jsp locks you into using page.jsp only and the JSP technologies. To generate the right content page.jsp has to contain the appropriate logic.

In a Permutations pattern approach the client would reference the URL

http://mydomain.com/content/page

Then based on the type of the client one of the following contents would be returned

http://mydomain.com/content/pageajax.jsp
http://mydomain.com/content/pagenonajax.jsp

Which specific URL is called depends on the logic of the Permutations pattern. Some of you will say, "Hey this is URL rewriting". Absolutely, it is URL rewriting, but with the twist of a more sophisticated logic than what most URL rewriting implementations are capable of. The only URL rewriting module that is getting close to this is the new Apache 2.2 URL rewriter.

Ajax is not slow and does not introduce overhead. It seems like that because most Ajax applications are intended to be used in broadband situations. Will Ajax slow down a server? Depends on the server. For example the new Apache 2.2.x and Jetty 6.x servers are Ajax ready. They have introduced threading and resource logic that is Ajax "compliant". Other servers? Well there you might be out of luck.

[Christophe Verré]

That still means implementing differently the same thing
It sounds like developping time and cost is going to get bigger.
I think that many people will probably feel reluctant to use such technology.
(I've never used it, so I may be wrong)

By the way, what is REST ?
I like to have one, but that is not the one I think, is it ?

[Christian Gross]

Regarding implementing differently the same thing is true and not true.

Currently most web applications are huge monolithic things that download everything in one chunk. Then to make that one chunk available in multiple formats you are stuck because everything needs to chunked into smaller pieces.

However, that is not what I am saying. What I am saying is that you need to convert your content into chunks and then work on those chunks. Here is an example.

I load the URL http://mydomain.com/content/first which redirects to http://mydomain.com/content/first.html. Included in main.html are some server side includes (/content/menu, /content/first) to chunks of content that will vary from device to device. The chunks are in fact where your content may or may not vary. What you would do is implement the permutations pattern on those chunks.

The difference with this approach is that your chunking your content into smaller pieces that you assemble. Each of the smaller pieces is a separate URL. The advantage of this approach is that chunks can be reused in different contexts without having to figure out how to integrate it into your HTML page.

Is this more work? No, because the server side JSP's, etc are a huge monolithic chunk of content. This goes back to my assertion that what you are in fact doing is creating Web components.

What is REST? http://www.xfront.com/REST-Web-Services.html

As I said to another poster, this question is a good one and if you would like I can implement it as part of my upcoming book. You would not have to wait for the implementation until the book came out, but if you are interested send me an email and we can talk.

[Christophe Verré]

Thank you for your comprehensive reply.

I had a brief look at the REST article, and it sounded like some kind of URL mapping technology. That must be more than that. I'll give a deeper look after.

[Christian Gross]

It is that simple...

You need to do 2 things

1) Restructure your application to be more granular
2) Create a URL remapper, and that is the difficult part. Most URL rewriters are relatively simplistic in logic in that they remap based on a single HTTP header, or URL. A REST URL rewriter has logic as it has to look at all Accept HTTP headers and decide which content is the most appropriate. I do advise to take a look at my Permutations implementation as the Accept header can be tricky.
[ February 22, 2006: Message edited by: Christian Gross ]

[Christophe Verré]

I wish there were some kind of framework taking care of that

[Christian Gross]

It's a problem that I am providing a solution for. Right now my Permutations pattern is at version 0.65, and if anybody wants to start using it get the sources. If you have requests send me an email or private message and we will start talking.

[Christophe Verré]

Spring started back in the days where Rod Johnson was talking about the problems of J2EE development in his book. It started all with some samples, to become bigger and bigger. And we all know how big it has become now.

Do you intend to go on bulding around your patterns, to provide some day some kind of reliable solution for Ajax development ? (I don't mean that the state of your samples now are not reliable now )

[Christian Gross]

Yes I have already started. The framework is very similar to the pattern implementations except that the framework implementation is complete. The patterns are used to illustrate that the patterns work, less flexible (eg the patterns do not read most of their information from a configuration file for explanation purposes).