Showing posts with label ajax. Show all posts
Showing posts with label ajax. Show all posts

Thursday, July 30, 2009

Detect an AJAX request

Many web applications use AJAX nowadays. In a typical scenario, one fills out a form, which is then submitted to the server. If you don't use AJAX or JavaScript is disabled, your form should still submit with no problems. And you receive a new page. If you use unobtrusive enhancement via JavaScript, the form is submitted to the server and the page is updated with the result without a full page reload.

While developing with Grails writing Java and Groovy code, I noticed that a typical pattern is to create two actions in a controller. One to handle normal HTTP POST (e.g. save action) and one to handle HTTP POST coming from an AJAX request (e.g. saveAjax action). The two actions are almost identical. They perform the same business logic. The only difference is what is returned from each action. A normal action renders a new page. An AJAX one returns whatever your flavor is: XML, JSON, HTML, plain text.

So is there a way to tell the requests (ordinary and AJAX) apart?

You guessed it, there is. AJAX request comes with a special header - X-Requested-With. I usually have my controllers to extend my BaseController, which has a couple of useful methods that I use. isAjax(request) is one of them. And this is what it looks like.


public static boolean isAjax(request) {
return "XMLHttpRequest".equals(request.getHeader("X-Requested-With"));
}

I hope you'll find it useful. The all you need to do in your action is this:


def save = {

// business logic
// ...

if (isAjax(request)) {
render([ /* data */ ] as JSON)
}
else {
// render or redirect here
render(view: 'save', model: [ /* model data */ ])
}
}

Saturday, June 02, 2007

Google Developer Day 2007 in Sydney

Google Developer Day 2007I attended Google Developer Day in Sydney this week. The main page describes the content of the sessions in Sydney. It also links to related video records that can be viewed at YouTube.

The event was well organized. Originally, this was meant to be a 100 people event. However due to its popularity, the event was fully booked within 20 minutes after the registration opened. Later Google decided to change the venue to Australia Technology Park and were able to accommodate all people from the waiting list.

Google Developer Day 2007Google Developer Day 2007

One of the biggest announcements was Google Gears (BETA). It is available for Windows, Mac and Linux. Google Gears is an open source technology for creating offline web applications. As published in Sydney Morning Herald:

The Gears technology promises to give Google a better platform from which to go after Microsoft's very lucrative Office franchise.

Here is a blog post that will get you started with Gears.

Another announcement of the day was Google's purchase of Panoramio, a website that links millions of photos with the exact location where they were taken.

Google Web Toolkit (GWT) got an upgrade as well. GTW 1.4 Release Candidate is a major upgrade to the Google’s open-source framework for writing AJAX web applications in the Java programming language. Read more about its features at ZDNet blog post by Ed Burnette: Google Web Toolkit 1.4: "Have to see it to believe it".

Google Web Toolkit had brought Google's AJAX development out of the dark ages and into the 21st century.

said Lars Rasmussen in his AJAX is painful, painful, painful talk.

Also announced was Google Mashup Editor - experimental product, online application to create mashups. It is currently in beta and access is limited to small number of developers during this testing period.

A great combination of Google's APIs are Google Mapplets. They are mini-applications that you can embed within the Google Maps site. Then they can manipulate the map using Javascript calls that are derived from the Google Maps API. The preview maps site also has Street View, which is very cool and was enabled just few days before Google Dev Day.

When we arrived we received a "speedgeeking" card, which listed six URLs of Google mashups. These six sites were presented live on big screens in the lunch area where everybody had a chance to see the products, talk to the authors and cast one's vote. At the end of the day, Property Guru took the prize home.

Google Developer Day 2007

And if it was not Google, there would be no search. I was strongly reminded that Google is the company behind the most popular search engine when I saw this card on the tables.

Google Developer Day 2007 tag

So there you go Google! I blogged and published my photos with GDD07 tag. Go and find me!

Monday, October 02, 2006

Hijax

How can we make feature-rich web site and also offer the way so people with disabilities can access it?

The old way it to produce two version of the website, e. g. Flesh version and HTML only versions. The big drawback of this approach is that the user is presented with the choices first and only then the user enters the website with content. Or some sort of client-side script is run in order to determine the capabilities of the browser. There is no way easy way check the user this way (e. g. the user is blind). Therefore we have a behavior that can be switched ON or OFF.

A better way is progressive enhancement. Initially we have content that we want to publish or present. Then we have the markup – (X)HTML. We add the presentation layer – CSS. At last we add the behavior on top – DOM Scripting.

We still have to answer whether we have some of the functionality in-line or external (*.css and *.js files).

The HIJAX way is :

  • Begin by creating a website using traditional page refreshes,
  • Data is sent to the server via links and form submissions: the server returns updated pages,
  • Intercept (hijack) those links and forms using (unobtrusive) JavaScript,
  • Send that data to XMLHttpRequest instead of the server,
  • The server returns just the information that's required instead of an entire page,

We have a choice of data format:

  • XML + DOM methods
  • JSON + eval()
  • HTML + innerHTML

Another important thing is that the browser is an unpredictable environment. The user can be running on any OS with any type of web browser. The only thing that we know is what is on our server. Therefore all business logic should be kept on the server side. For example a table sorting can be done on the client-side by JavaScript. This would off-load the server, but we would have to face the challenges with the differences between JavaScript support on various browsers. On top of that we would have no feedback about the usage of table sorting. If this logic was on the server, we could collect the data about table sorting and improve the website accordingly.

The main benefits of using Hijax approach are that we do not need to spend time building a non-Ajax version. Our web application will be still accessible in the usual way. We do not duplicate the logic (client-side and server-side validation) and the links are spiderable and potentially bookmarkable.

HIJAX is a term coined by. I learnt about Hijax at the Web Directions conference. Jeremy Keith presented Proressive Enhancement with Hijax. He is an author of DOM Scripting: Web Design with JavaScript and the Document Object Model and currently working on his next book Bulletproof Ajax.

Sunday, August 13, 2006

Server Polling - Reverse AJAX

I am starting to feel a bit old or old-school. I know the concepts of AJAX but never had enough time (or project) to get my hands dirty doing AJAX. So I decided to make time and learn AJAX by doing.

I joined the 10-Week Free AJAX Programming (with Passion!) online course organized by Sang Shin from Sun Microsystems. This course is in its second week now and the homework was:

"... to write one or two paragraphs describing an "interesting" AJAX related technology/feature you find while you are playing with the online demos or while reading AJAX articles on the net"

I though that it would be good to share my point of view with you. So, here I go.

Title: Server Polling - Reverse Ajax)
URL: http://ajaxian.com/archives/reverse-ajax-with-dwr

Keeping the displayed information up-to-date was always difficult in web world. Before AJAX, one had to use JavaScript or META Refresh tag to get the page refreshed. This was quite annoying from the user experience point of view. However it was not as annoying as something that I experienced few days ago on one of the banks website (a bank in Australia). I was filling out the form and there were couple of select boxes on the page. I selected an option in the select box and moved onto next field just to realize that as I was typing, the page has been reloaded and all data entered past that select-box was gone and had to be re-typed again. Very, very annoying - and it's AJAX age already!

Server polling, in my humble opinion, is a great feature of AJAX. There is no need to refresh the whole page to obtain the required information. With AJAX, it is possible to:

  • update the forms with information as the user moves through the form (e.g. country - state - city)
  • get the feedback about a long server-side or transport process (e.g. progress bar showing the percentage of the uploading file)
  • fake the push of the updated data from the server (think stock prices, weather, traffic info)

I am sure that I will come across more coolness when I start writing more and more Ajax code!


Creative Commons License This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.