indiWiz.com

We can make Ajax requests using Prototype.js (version 1.6.0.3) thus:

var url = ...;
new Ajax.Request(
            url,
            {
               method:'DELETE',
               onComplete:function doMessage(response){
                   alert(response.status);
               }
            });

While working on this code, we found out that the method parameter accepted only GET or POST requests. When we give any other request type like DELETE or PUT, the Prototype.js library converted the request to POST.

Arun Jeganath found this post where the same issue is discussed. The problem was solved when we commented these lines from the Prototype.js code:

      if (!['get', 'post'].include(this.method)) {
        //simulate other verbs over post
        params['_method'] = this.method;
        this.method = 'post';
      }

Yesterday we (Krithika and myself) spent some time finding a perfect Ajax auto-complete solution for one of our internal projects. We wanted to have a tag search box with auto-complete functionality. We had created a front-end layer for our Java tagging API (developed by Arun) using RESTful interface. This exposed searched result in JSON. So our need was for a Ajax library which provided auto-complete feature which satisfied following parameters:

1. The code we need to incorporate for enabling auto-complete should be minimal.
2. Should not be flashy.
3. Should consume JSON content.

This seemed to be a trivial task, but it took quite some time to find and finalize on AutoComplete 1.2 by Beau Scott. This script was simple to integrate, and did not require us to configure any sophisticated CSS. It allowed us to consume our RESTful service without any modification.

During our search, we were surprised to find how badly certain popular Ajax libraries implemented this oft-used functionality. The famous Scriptaculous library’s implementation has the implementation detailed here: http://github.com/madrobby/scriptaculous/wikis/ajax-autocompleter. If you go through this document, you will see that the script requires the server to return data in this format:

<ul>
    <li>your mom</li>
    <li>yodel</li>
</ul>

This is bad design. A server code returning data as HTML. This cannot be consumed effectively by other clients. The next one which we picked up was YUI Autocomplete. The amount of configuration effort needed from our side scared us. We didn’t plunge deeper!

Another one which we tried was DevBridge’s Auto Complete. This looked simple to implement, and the look and feel was simplistic. But it had an issue: the call to the server-side code was passed as a query string (query=). We were using RESTful URL and we cannot modify our backend-code to comply to the requirements of the UI layer. But I did a little hack and made this script compliant to our requirement. But finally, we decided against using this patched-script because it had additional dependencies like images and CSS styles to be specified.

As said earlier, the script which matched all our requirements was AutoComplete 1.2 by Beau Scott.

The only worry for me from this exercise was the divide between the front-end developers and backend developers. Such a common functionality was not being addressed by popular frameworks without sacrificing functionality and addressing usability–and, more importantly, complying to established enterprise patterns like consuming data (like JSON and XML instead of HTML snippet) and support for RESTful URLs.

Hope 2009 annihilates this divide