Rochak Chauhan::Unpredictably Exciting » Ajax

AJAX browser vote exceeds ‘wild’ expectations

rochakchauhan — Thu, 10 Jul 2008 09:09:14 +0000

There’s been a late surge of interest in voting for a wishlist of features users want added to web browsers, after being ignored for months.

With less than a day left before the OpenAjax Alliance closes its poll for most-wanted browser features 116 people have now voted, according to the project’s summary. That’s up from a miserable 13 by early June, two months after OpenAjax called for votes, and following last month’s Reg article.

IBMer Jon Ferraiolo, a member of the Alliance’s Runtime Task Force, said he’s pleased with the level of participation.

“From my perspective, the initiative has exceeded even the wildest expectations, both in terms of the quantity and quality of the feature requests and the level of community participation,” Ferraiolo said.

OpenAjax boasts a membership of more than 100 companies, organizations and projects with a mission to standardize AJAX implementations. The poll’s results will be presented to vendors as a call for features that they’d like to see in browsers. The initiative was launched in April and is scheduled to be completed by the end of this month.

So far, there have been 37 feature requests. At time of going to press on the eve of the poll closing, 2D drawing and vector graphics topped the list, followed by native JSON parsing and better security for cross-site scripts. Other features attracting significant levels of support include improved HTML DOM performance and better APIs for positioning and styling

Streamline your search with Yahoo! Web Services and AJAX

rochakchauhan — Tue, 05 Feb 2008 16:57:10 +0000

Despite what you might read and hear about Google’s web dominance, this is not Google-owned world. Yahoo! may be playing second fiddle to the internet’s favorite search and ads service, but it still plays one hell of a tune in terms of numbers of users and the services it offers.

If you use Yahoo! for your web search, then Yahoo! provides web services that may be included in web applications to generate dynamic content for an input.

In this article, we follow up Asynchronous JavaScript and XML (AJAX) to your Google search, by looking at adding AJAX to web search using Yahoo! Web Services in Oracle JDeveloper 11g. Why JDeveloper 11g? Because this provides a new feature for web and AJAX development – an integrated JavaScript editor.

Limits of AJAX

AJAX is a web technique to transfer XML data between a browser and a server without reloading the web page. Ajax is implemented using the XMLHttpRequest object.

A limitation of XMLHttpRequest is that AJAX requests may be made only to the same web server that serves the web page from where the AJAX request is sent. If the web application is running on one server and the web service is on another server a XMLHttpRequest request does not get sent. Various methods are available to send an AJAX request to a remote server some of which are digitally signing your scripts and using an alternative XMLHttpRequest API. One of the methods, which we shall discuss in this article, is to use a proxy web server that routes AJAX requests from the web application to the web service.

Yahoo! Web Services provide various web search services and content that may be included to develop dynamic web applications. Yahoo! Web Search AJAX Web Services have an advantage over the Google web search AJAX web services. Yahoo! Web Services have the provision to search within a context; contextual web search. For example, search for the term “Eclipse” in the context of “Java IDE”. The various Web Search Web Services provided by Yahoo! are discussed in following Table.

Web service	Description
Context search	The contextual web search service returns web pages that match a query within a specified context
Related suggestion	Provides suggestions for related queries based on the submitted query
Spelling suggestion	Provides suggested spellings for a specified term
Web search	Provides a web search service using REST (Representational State Transfer)

Before Yahoo! Web Service may be used, register with Yahoo Web Services (https://login.yahoo.com/config/login_verify2?.src=devnet&.done=https%3A%2F%2Fdeveloper.yahoo.com%2Fwsregapp%2Findex.php) to obtain an application identity with which Yahoo! Web Services may be accessed.

Create a web application

First, create a JDeveloper application, WebSearchApp, and project, WebSearchWebService. Create a JSP file, input.jsp, in the project. The web application URL, which is used to register with Yahoo! Web Services, is http://127.0.0.1:8988/WebSearchApp-WebSearchWebService-context-root/input.jsp. In the web application we shall use the Contextual Web Search service to submit a context-base web search query.

The request URL for the contextual web search web service is http://search.yahooapis.com/WebSearchService/V1/contextSearch. The required request parameters to a contextual web search query are appid and context. The value of the appid parameter is the application ID provided by Yahoo! Web Services and the context parameter specifies the context string in which the web search query is sent.

The XML response returned by the Contextual Web Search service conforms to the XML Schema http://search.yahooapis.com/WebSearchService/V1/WebSearchResponse.xsd. In the input.jsp add a form containing fields for application ID, query, results, and context. The form may be submitted using GET or POST, but to use a context with many search terms use the POST method.

Send an AJAX request

To send an AJAX request we shall use a proxy servlet that routes the XMLHttpRequest from the browser to the Yahoo! Web Service. If an XMLHttpRequest is sent without a proxy servlet the XMLHttpRequest does not get sent and an error, such as the one below, is generated.

Error: uncaught exception: Permission denied to call method XMLHttpRequest.open

A proxy servlet may be developed or the HTTP proxy servlet (http://www.servletsuite.com/servlets/httpproxy.htm) may be used. Download httpProxyPackage.jar. Add the proxy servlet JAR file to the Libraries of the WebSearchWebService project. To the web.xml file add and elements for the proxy servlet.

         HttpProxy         com.jsos.httpproxy.HttpProxyServlet                      host             http://search.yahooapis.com/WebSearchService/V1/contextSearch                            HttpProxy         /servlet/yahoo

The procedure to send an AJAX request is as follows:

Initiate an AJAX request from an HTML event such as a button click
Create a XMLHttpRequest object
Open a connection with the web service URL using the open() method of the XMLHttpRequest object
Register a callback function to be invoked when the Ajax request is complete
Send the AJAX request with the send() method
Update the web page with the web service response

In the input.jsp, to the input element of type button add a onclick event handler to invoke a JavaScript function displaySearchResults(). In the displaySearchResults function create an XMLHttpRequest object. XMLHttpRequest is supported as a native object in some browsers such as Netscape 6 or later and Internet Explorer 7 and as an ActiveXObject in other browsers such as IE 6.

Specify the proxy servlet URL to which an AJAX request is to be sent. Obtain the values for query, results and context request parameters from the input form. Open an XMLHttpRequest request using the open() method. Register a callback function that is to be invoked when the request state changes using the onreadystatechange property of the XMLHttpRequest object. Send the XMLHttpRequest request using the send() method. In the callback function check if the request is complete and invoke the JavaScript function processResponse() to update the web page with the Web Service response. The complete input.jsp is available in this (http://regmedia.co.uk/2008/01/29/yahooajax_resources.zip) zipped folder.

Integrated JavaScript editor

JDeveloper 11g includes an integrated JavaScript editor for creating JavaScript. In the previous section we added the JavaScript directly to the JSP, but the JavaScript may also be created in a separate .js file and the .js file added to the JSP using the

The following base HTML is used to deliver the Rich Text Box, but you’ll still need to add scripting to fully implement the control.


This text will be displayed in the text area.

Now the cols and rows attributes of the HTML texarea element will be overridden by settings specified in the Rich Text Editor’s script. The name assigned to the HTML textarea element is important, since it will be used in the JavaScript code when establishing the relationship between a textarea element and a Rich Text Editor.

Also, the class assigned to the HTML body element (yui-skin-sam) is used to visually format the Rich Text Editor control. This CSS skin is defined in the CSS file imported into the application (see previous list). The skin should be applied to the parent HTML element of the textarea element. In this case, the HTML body element is used, but it could be any element that contains the textarea.

Once the textarea has been defined along with the proper YUI Library files included in the page, the Rich Text Editor control must be rendered. The rendering is accomplished via JavaScript placed within the page. The script can be used to define various Rich Text Editor options such as the toolbar. As an example, I may use the following JavaScript to format our Rich Text Editor:

var rtf = new YAHOO.widget.Editor('texteditor', {
height: '300px',
width: '522px'});
rtf.render();

This snippet establishes the height and width of the editor while declaring an instance of the Rich Text Editor. Also, it assigns the textarea called texteditor to the Rich Text Editor. The final line in the script actually causes the Rich Text Editor to display when it calls its render method.

When you use the Rich Text Editor control without any specifics about the toolbar, it results in the default behaviour of including all toolbar features like text alignment, font face, font size, colour, and so forth. You may choose to limit the toolbar options available to users.

The final example uses a Rich Text Editor, but the toolbar options are defined in the JavaScript code to render it. The following options are used:

The toolbar options are defined in its own variable. This is later used to instantiate the editor.
A title is assigned to the editor via the toolbar’s titlebar property.
The collapse property signals whether the user may collapse/hide the toolbar.
The buttons property allows you to define the buttons displayed in the toolbar. In this example, buttons are displayed for text formatting as well as selecting colours.

Once the toolbar options are defined, a Rich Text Editor object is instantiated with the toolbar variable passed to it along with the HTML textarea element. The final step is to render the control. A complete list of options is available in the YUI Library API documentation.


Working with YUI Library Rich Text Editor
















 


First Name:

Last Name:

Test within TextArea.

It is worth noting that the text is formatted using standard HTML to format the text within the Rich Text Editor, so bold text uses the HTML strong element; the font element is used for font styling, and so forth.

An improved interface

I have been a big fan of the YUI Library since I first discovered it more than a year ago. It allows developers to build powerful Web interfaces using code that has been fully tested for proper functionality. The Rich Text Editor is just one example of the power controls available in the YUI Library.

7 Deadly Sins of AJAX application development

rochakchauhan — Wed, 09 Jan 2008 09:12:39 +0000

At first blush, those pitfalls may seem avoidable through sheer common sense, and to a degree, that’s true. But AJAX apps bristle with architectural differences from its DHTML forebears. No matter how much common sense you bring to the application development task, it is still good to learn from the mistakes of those who have preceded you. We’ll call these mistakes our Seven Deadly Sins, but they are by no means the whole story.

In fact, before you commit any of the deadly sins, you’re much more likely to commit a few lesser sins. So we’ll start with those. These are the ones that make everybody’s list. These mistakes are so common that you can find most of them in a simple Google search.

The Seven Lesser Sins

1.Misuse of the Back Button – This is the one mistake everyone’s going to have on their list. The Back Button has become a user expectation in many kinds of Web apps. Many new AJAX developers drop a Back Button into their AJAX app and promptly break it, for several reasons. First, JavaScript isn’t the friendliest language for it; and second, AJAX design requires a new way of thinking.
It’s not always readily apparent to a new AJAX developer that “Back” isn’t best. “Back” is a feature you’ll need at a page-update point or more often, when you want an event-specific “Undo” feature. Think this through before you code, or you’ll end up doing it twice.
2.Not telling the user what’s happening – Part of how AJAX works is that it doesn’t use conventional Web UI page loading. So you need to explicitly design some visual cue to let the user know what’s happening.
3.Neglecting Links — Here’s another AJAX standard blunder: neglecting URLs that can be cut-and-pasted for uses outside the app. How many times have we grabbed a URL and e-mailed it to someone? When you’re using AJAX, the only way to provide your user with useful cut-and-pasteable URLs is to manually provide them. Why? Because in an AJAX app, the server is not providing the page: JavaScript is dynamically generating it! Don’t neglect your users’ potential interest in this all-too-common feature of Web apps. Take pains to provide URLs, since the server won’t.
4.Trading content control for page control — Breaking with the traditional client-server interaction is a wonderful gift, if you’re seeking dynamic content control. But it’s also a curse: rewriting highly-specific areas of a page to fine-tune a user’s interactive experience does indeed give you fine control, but this pulls you away from the big picture.
All too often, we focus on processing some sector of the page and forget that the page isn’t going to be refreshed by the server. This can lead to a fragmented page, a confusing user experience, wherein the screen they’re looking at can be out-of-date with itself! Take care to keep your attention on the entire page; make sure that any dynamic content event evokes changes everywhere the user will need to see them.
5.Killing spiders – The upside of AJAX is the truckloads of text you can feed a page without a reload. And the downside of AJAX is the truckloads of text you can feed a page without a reload. If the app is intended to be search-engine-friendly — well, you can imagine. Whatever is happening in the guts of the page, be sure to plant plenty of stable text up top, for the spiders to play with.
6.Producing unspeakable text — AJAX doesn’t support many character sets. This isn’t a life-or-death limitation, but forgetting it can create real problems. Your basic character set is UTF-8. Don’t forget to properly encode whatever JavaScript is sending, and remember to set the server-side character set for content.
7.Not letting the JavaScript-challenged user know what’s going on. There are browsers out there that don’t have JavaScript enabled, and users out there who don’t understand immediately what that means. Be sure to clue them in.

Truth to tell, most of those are common-sense issues. The real killers are less obvious.

The Seven Deadly AJAX Sins

1.Letting memory leak – Anyone who has worked in development for very long understands cyclic references and the danger they pose to memory management. JavaScript, the workhorse of AJAX, is a memory-managed language. What that means is that JavaScript has built-in garbage collection, so that it sniffs out variables no longer accessible by any reference path and de-allocates the memory they’re using.
That’s fine as a general principle; but you can’t count on it to keep your memory usage optimised, because of those cyclic references, when a Model-layer object is referencing a View element and vice versa. Nulling the object nulls the element, in principle, but if there’s a backward reference from element to object, then the garbage collector won’t touch the object.
Now, here’s where it gets tricky: in the Document Object Model, any DOM node that’s part of the document tree may be referenced by virtue of its presence in the tree, whether it’s explicitly referenced by another object or not! So any object you tag for garbage collection that is back-referenced by a DOM node must be explicitly nulled in that direction, or its memory remains allocated!
2.Not knowing what “asynchronous” means – Asynchrony can be really unsettling to a user unaccustomed to it, and this can be ironic, since the Web apps you’ll design and build for those users wouldn’t find them at all unsettling if they were desktop apps. This is a crucial design point! Most Web apps are functionally very similar to their desktop counterparts. But in a Web app, there’s a looming characteristic that sets it apart: user expectations.
Users carry a very different set of biases and anticipations into a session with a Web browser that they don’t tote into a desktop app exchange. So while it may be incredibly cool and efficient to have myriad responses trotting back to the page from the server, and the page revising itself in the meantime, it can be deeply disorienting to the user to see this constant barrage of change. For this reason, you need to apply two rules, and consider them with every change that comes into the user’s field-of-vision: If the update is not immediately essential to the user, make the update unobtrusive, so that it does not distract; and if the update is vital to the user’s interaction with the app, make its presence on the page clear and prominent.
3.Keeping the server in the dark – The decoupling of client and server has a huge downside that seldom occurs to us up-front. Server-side apps know all and see all: every exception, every reload, every event can be watched and recorded, and of course the server knows exactly what the client looks like, because the server basically wrote whatever’s on the screen.
In an AJAX app, this isn’t the case. Stuff happens, and it happens independently of the server, and this means that there can be problems on the client side that the server won’t immediately be privy to. Capture and log events and exceptions on the client side, in a place and manner that enables the server to home in on problems that require its intervention as soon as possible.
4.Getting lazy with GET – GET is for retrieving data; POST is for setting it. Don’t use GET when you know you shouldn’t, even if you think it will do no harm. GET operations change state, and links that change state are confusing to users; most are accustomed to links as guides to navigation, not function.
5.Not accounting for data type –JavaScript, isn’t part of the .NET Framework. While this may draw tears of sorrow, it presents us with an example of a problem you’ll eventually run into: making certain that JavaScript understands the data types of the platform it’s running on, and vice versa, be it .NET or otherwise. There are various converters available to you, and you should seek them out. The Ajax.NET Pro library, for instance, offers converters that can convert objects between .NET and JavaScript Object Notation.
6.Some apps just don’t know when to shut up – Dynamic generation of content, with no dependency on page-reload, can be disastrous if left open-ended. How many Web pages have you seen that were longer than the Congressional Record? If Web pages that go on forever are a confusing nightmare for users, just imagine how they’ll feel about an application that goes on and on and on. Make your Web app pages dynamic, but build in some practical limits.
7.Keep your JavaScript out of your DOM — Remember that AJAX is built on the Model-View-Controller structure. Take this seriously. JavaScript belongs in the Model layer, DOM in the View layer, and the Controller is their marriage counselor. Make sure your Web document has the same content independent of JavaScript (this helps with the JavaScript-disabled user) — except when the content itself is only meaningful or practical if the user can use JavaScript. In that instance, create that content with JavaScript.