Software Solutions Developed With
High Perfection & High Quality

Rich Clients GUI ( Graphical User Interface )

Prototype JavaScript Framework

The Prototype JavaScript Framework is a JavaScript framework created by Sam Stephenson in February 2005 as part of the foundation for Ajax support in Ruby on Rails. It is implemented as a single file of JavaScript code, usually named prototype.js. Prototype is distributed standalone, but also as part of larger projects, such as Ruby on Rails, and Rico. Prototype is used by 2.9% of all websites, which makes it one of the most popular JavaScript libraries.


Prototype provides various functions for developing JavaScript applications. The features range from programming shortcuts to major functions for dealing with XMLHttpRequest. Prototype also provides library functions to support classes and class-based objects, something the JavaScript language lacks. In JavaScript, object creation is prototype-based instead: an object creating function can have a prototype property, and any object assigned to that property will be used as a prototype for the objects created with that function. The Prototype framework is not to be confused with this language feature.

The Ajax object

In an effort to reduce the amount of code needed to run a cross-browser XMLHttpRequest function, Prototype provides the Ajax object to abstract the different browsers. It has two main methods: Ajax.Request() and Ajax.Updater(). There are two forms of the Ajax object. Ajax.Request returns the raw XML output from an AJAX call, while the Ajax.Updater will inject the return inside a specified DOM object. The Ajax.Request below finds the current values of two HTML form input elements, issues an HTTP POST request to the server with those element name/value pairs, and runs a custom function

Object-oriented programming

Prototype also adds support for more traditional object-oriented programming.

The framework function Object.extend(dest, src) takes two objects as parameters and copies the properties of the second object to the first one simulating inheritance. The combined object is also returned as a result from the function. As in the example above, the first parameter usually creates the base object, while the second is an anonymous object used solely for defining additional properties. The entire sub-class declaration happens within the parentheses of the function call.


Unlike other JavaScript libraries like jQuery, Prototype extends the DOM, but there are plans to change this in the next major version of the library.

In April 2010, blogger Juriy 'kangax' Zaytsev (of Prototype Core) described at length the problems that can follow from adding new methods and properties to the objects defined by the W3C DOM.These ideas echo thoughts published in March 2010 by Yahoo! developer Nicholas C. Zakas They have been summarised as follows

Cross browser issues: host objects have no rules, IE DOM is a mess, etc.

Performance overheads

By 2008, specific issues with using DOM-extension methods in older versions of Prototype, combined with newer versions of current browsers, were already being documented. Rather than adding new methods and properties to pre-existing 'host' DOM objects such as Element, like element.hide(), the solution to these issues is to provide wrapper objects around these host objects and implement the new methods on these. jQuery is such a wrapper object in the library of that name.

It is now widely expected that the majority of these ideas and issues will be addressed in the release of Prototype 2.0, but Prototype developers will have to learn to work with an altered syntax, and much existing Prototype code will become outdated.

Moo Tools :

MooTools (My Object-Oriented Tools) is a lightweight, object-oriented, JavaScript framework. It is released under the free, open-source MIT License. It is used on more than 5% of all websites, and is one of the most popular JavaScript libraries.


Valerio Proietti first authored the framework and released it in September 2006 taking as his inspiration Prototype and Dean Edward's base2. MooTools originated from Moo.fx, a popular plug-in Proietti produced for Prototype in October 2005, which is still maintained and used. Whereas Prototype extended - prototyped - many of JavaScript's native String, Array, and Function objects with additional methods, Proietti desired a framework that (at the time) further extended the native Element object as well to offer greater control of the Document Object Model (DOM).


MooTools includes a number of components, but not all need to be loaded for each application. Some of the component categories are :

    • Core: A collection of utility functions that all the other components require.
    • More: An official collection of add-ons that extend the Core and provide enhanced functionality.
    • Class: The base library for Class object instantiation.
    • Natives: A collection of JavaScript Native Object enhancements. The Natives add functionality, compatibility, and new methods that simplify coding.
    • Element: Contains a large number of enhancements and compatibility standardization to the HTML Element object.
    • Fx: An advanced effects-API to animate page elements.
    • Request: Includes XHR interface, Cookie, JSON, and HTML retrieval-specific tools for developers to exploit.
    • Window: Provides a cross-browser interface to client-specific information, such as the dimensions of the window.

  • .

    Browser compatibility

    MooTools is compatible and tested with :

    • Safari 3+
    • Internet Explorer 6+
    • Mozilla Firefox 2+
    • Opera 9+
    • Chrome 4+

  • .


    MooTools provides the user with a number of advantages over native JavaScript. These include:

    • An extensible and modular framework allowing developers to choose their own customized combination of components.
    • MooTools follows object-oriented practices and the DRY principle.
    • An advanced effects component, with optimized transitions such as easing equations used by many Flash developers.
    • Enhancements to the DOM, enabling developers to easily add, modify, select, and delete DOM elements. Storing and retrieving information with Element storage is also supported.

  • .

    The framework includes built-in functions for manipulation of CSS, DOM elements, native JavaScript objects, Ajax requests, DOM effects, and more. MooTools also provides a detailed, coherent application programming interface (API) as well as a custom downloads module allowing developers to download only the modules and dependencies they need for a particular app.

    Emphasis on modularity and reusability

    Every JavaScript framework has its philosophy, and MooTools is interested in taking full advantage of the flexibility and power of JavaScript in a way that emphasizes greater modularity and code reuse. MooTools accomplishes these goals in a way that is intuitive to a developer coming from a class-based inheritance language like Java with the MooTools Class object.

    Class is an object of key/value pairs that can contain either properties or methods (functions). Class is effortlessly mixed and extended with other Class instantiations allowing for the greatest focus of MooTools: Code reuse achieved through maximizing the power of JavaScript's prototypical inheritance, but in a Class object syntax more familiar to classical inheritance models.

    jQuery :

    jQuery is a multi-browser JavaScript library designed to simplify the client-side scripting of HTML. It was released in January 2006 at BarCamp NYC by John Resig. It is currently developed by a team of developers led by Dave Methvin. Used by over 65% of the 10,000 most visited websites, jQuery is the most popular JavaScript library in use today.

    jQuery is free, open source software, licensed under the MIT License. jQuery's syntax is designed to make it easier to navigate a document, select DOM elements, create animations, handle events, and develop Ajax applications. jQuery also provides capabilities for developers to create plug-ins on top of the JavaScript library. This enables developers to create abstractions for low-level interaction and animation, advanced effects and high-level, theme-able widgets. The modular approach to the jQuery library allows the creation of powerful dynamic web pages and web applications.

    The set of jQuery core features - DOM element selections, traversal and manipulation -, enabled by its selector engine (named "Sizzle" from v1.3), created a new "programming style", fusing algorithms and DOM-data-structures; and influenced the architecture of other Javascript frameworks like YUI v3 and Dojo.

    Microsoft and Nokia have announced plans to bundle jQuery on their platforms. Microsoft is adopting it initially within Visual Studio for use within Microsoft's ASP.NET AJAX framework and ASP.NET MVC Framework while Nokia has integrated it into their Web Run-Time widget development platform. jQuery has also been used in MediaWiki since version 1.16


    jQuery includes the following features :

    • DOM element selections using the multi-browser open source selector engine Sizzle, a spin-off of the jQuery project
    • DOM traversal and modification (including support for CSS 1-3)
    • DOM manipulation based on CSS selectors that uses node elements name and node elements attributes (id and class) as criteria to build selectors
    • Events
    • Effects and animations
    • AJAX
    • Extensibility through plug-ins
    • Utilities - such as user agent information, feature detection
    • Compatibility methods that are natively available in modern browsers but need fall backs for older ones - For example the inArray() and each() functions.
    • Multi-browser (not to be confused with cross-browser) support.

  • .

    Including the library

    The jQuery library is a single JavaScript file, containing all of its common DOM, event, effects, and Ajax functions. It can be included within a web page by linking to a local copy, or to one of the many copies available from public servers. jQuery has a CDN sponsored by Media Temple (previously at Amazon). Google and Microsoft host it as well.

    jQuery plug-ins

    jQuery's architecture allows developers to create plug-in code to extend its functionality. Currently there are thousands of jQuery plug-ins available on the web that cover a wide range of functionality such as Ajax helpers, web services, datagrids, dynamic lists, XML and XSLT tools, drag and drop, events, cookie handling, modal windows, and even a jQuery-based Commodore 64 emulator.

    An important source of jQuery plug-ins is the plugins subdomain of the jQuery Project website. However, in an effort to rid the site of spam, the plugins in this subdomain were accidentally deleted in December 2011.The new site will include a GitHub-hosted repository, which will require developers to resubmit their plugins and to conform to new submission requirements. There are alternative plug-in search engines like that take more specialized approaches, such as listing only plug-ins that meet certain criteria (e.g. those that have a public code repository). The tutorials page on the jQuery site has a list of links to jQuery plug-in tutorials under the "Plugin development" section.

    Ajax :
    Ajax :

    Ajax (also AJAX an acronym for Asynchronous JavaScript and XML) is a group of interrelated web development techniques used on the client-side to create asynchronous web applications. With Ajax, web applications can send data to, and retrieve data from, a server asynchronously (in the background) without interfering with the display and behavior of the existing page. Data can be retrieved using the XMLHttpRequest object. Despite the name, the use of XML is not required (JSON is often used instead), and the requests do not need to be asynchronous.

    Ajax is not a single technology, but a group of technologies. HTML and CSS can be used in combination to mark up and style information. The DOM is accessed with JavaScript to dynamically display, and allow the user to interact with, the information presented. JavaScript and the XMLHttpRequest object provide a method for exchanging data asynchronously between browser and server to avoid full page reloads.


    In the 1990s, most web sites were based on complete HTML pages. Each user action required that the page be reloaded from the server (or a new page loaded). This process was inefficient, as reflected by the user experience: all page content disappeared then reappeared. Each time a page was reloaded due to a partial change, all of the content had to be re-sent, even though only some of the information had changed. This placed additional load on the server and used excessive bandwidth. In 1996, the iframe tag was introduced by Internet Explorer to load content asynchronously.

    In 1998, Microsoft Outlook Web Access team implemented the first component XMLHTTP by client script.

    In 1999, Microsoft utilized its iframe technology to dynamically update the news stories and stock quotes on the default page for Internet Explorer, and created the XMLHTTP ActiveX control in Internet Explorer 5, which was later adopted by Mozilla, Safari, Opera and other browsers as the XMLHttpRequest JavaScript object. Microsoft has adopted the native XMLHttpRequest model as of Internet Explorer 7, though the ActiveX version is still supported. The utility of background HTTP requests to the server and asynchronous web technologies remained fairly obscure until it started appearing in full scale online applications such as Outlook Web Access (2000) and Oddpost (2002).

    Google made a wide deployment of standards-compliant, cross browser Ajax with Gmail (2004) and Google Maps (2005).

    The term Ajax was coined on 18 February 2005 by Jesse James Garrett in an article entitled "Ajax: A New Approach to Web Applications", based on techniques used on Google pages.

    On 5 April 2006, the World Wide Web Consortium (W3C) released the first draft specification for the XMLHttpRequest object in an attempt to create an official web standard.


    The term Ajax has come to represent a broad group of web technologies that can be used to implement a web application that communicates with a server in the background, without interfering with the current state of the page. In the article that coined the term Ajax, Jesse James Garrett explained that the following technologies are incorporated:

    • HTML (or XHTML) and CSS for presentation
    • The Document Object Model (DOM) for dynamic display of and interaction with data
    • XML for the interchange of data, and XSLT for its manipulation
    • The XMLHttpRequest object for asynchronous communication
    • JavaScript to bring these technologies together

  • .

    Since then however there have been a number of developments in the technologies used in an Ajax application, and the definition of the term Ajax. XML is not required for data interchange and therefore XSLT is not required for the manipulation of data. JavaScript Object Notation (JSON) is often used as an alternative format for data interchange, although other formats such as preformatted HTML or plain text can also be used.

    Asynchronous HTML and HTTP (AHAH) involves using XMLHTTPRequest to retrieve (X)HTML fragments which are then inserted directly into the web page.

    JSON :

    JSON or JavaScript Object Notation, is a text-based open standard designed for human-readable data interchange. It is derived from the JavaScript scripting language for representing simple data structures and associative arrays, called objects. Despite its relationship to JavaScript, it is language-independent, with parsers available for many languages.

    The JSON format was originally specified by Douglas Crockford, and is described in RFC 4627. The official Internet media type for JSON is application/json. The JSON filename extension is .json.

    The JSON format is often used for serializing and transmitting structured data over a network connection. It is used primarily to transmit data between a server and web application, serving as an alternative to XML.


    Douglas Crockford was the first to specify and popularize the JSON format.

    JSON was used at State Software Inc., a company co-founded by Crockford, starting in April 2001, and funded by Tesla Ventures. When State was founded in early 2001 by six former employees of, they agreed to build a system that used standard browser capabilities and provided an abstraction layer for Web developers to create stateful Web applications that had a persistent duplex connection to a Web server by holding the two http connections open and recycling them before standard browser time-outs if no further data were exchanged. The idea for the State Application Framework was developed by Chip Morningstar at State Software. It was used in a project at for Cartoon Network, which used a plug-in with a proprietary messaging format to manipulate DHTML elements (this system is also owned by 3DO). Upon discovery of early AJAX capabilities, digiGroups, Noosh, and others used frames to pass information into the user browsers' visual field without refreshing a Web application's visual context, realizing real-time rich Web applications using only the standard HTTP, HTML and JavaScript capabilities of Netscape 4.0.5+ and IE 5+. Douglas Crockford then found that JavaScript could be used as an object-based messaging format for such a system. The system was sold to Sun Microsystems, and EDS. The Web site was launched in 2002. In December 2005, Yahoo! began offering some of its Web services in JSON. Google started offering JSON feeds for its GData web protocol in December 2006.

    Although JSON was originally based on a non-strict subset of the JavaScript scripting language (specifically, Standard ECMA-262 3rd Edition - December 1999) and is commonly used with that language, it is a language-independent data format. Code for parsing and generating JSON data is readily available for a large variety of programming languages. JSON's Web site provides a comprehensive listing of existing JSON libraries, organized by language.

    Ajaj :

    AJAJ stands for Asynchronous JavaScript and JSON. AJAX is used primarily with server communication. Unlike its predecessor AJAX which uses XML, in AJAJ the content sent back and forth between the client and server is strictly JSON. The term AJAJ has been used since at least 2006. As of 2013, this term is rarely in use, and AJAX is used without regard to the format of the data returned by the asynchronous request.

    Similarities with AJAX

    Similar to the more popularly used AJAX, AJAJ is executed asynchronously, meaning that it occurs in the background, and does not interrupt the flow of the JavaScript interpreter as it gets read. The asynchronous aspect of AJAJ allows one to write code which, for example, sends some request to a server and handles a server response without reloading the page in the process. The opposite of this is synchronous, which means "in order". An example of synchronous processes is seen in standard HTML transmission between a client and a server; when a user clicks a hyperlink, there is some time in which the content is requested and retrieved from the server which causes the page to "reload." With any kind of web-based asynchronous request, you can request a resource over HTTP without reloading the page.


    AJAJ has many advantages over its predecessor AJAX like being lightweight and sending data back and forth in JSON which being JavaScript is faster for the browser to process and easier for developers to work with. AJAJ has the added benefit for JavaScript developers of allowing them to work with data retrieved from the server as native JavaScript objects; this alleviates the need to access data that is returned as XML, which increases complexity and can potentially cause expensive calls to the DOM. XML is also a strict markup language, which requires developers to ensure validation on the XML side as well as on the JavaScript side

    XMLHttpRequest :

    XMLHttpRequest (XHR) is an API available in web browser scripting languages such as JavaScript. It is used to send HTTP or HTTPS requests directly to a web server and load the server response data directly back into the script. Development versions of all major browsers support URI schemes beyond http: and https:, in particular, blob: URLs are supported. The data might be received from the server as JSON, XML, HTML, or as plain text. Data from the response can be used directly to alter the DOM of the currently active document in the browser window without loading a new web page document. The response data can also be evaluated by client-side scripting. For example, if it was formatted as JSON by the web server, it can easily be converted into a client-side data object for further use.

    XMLHttpRequest has an important role in the Ajax web development technique. It is currently used by many websites to implement responsive and dynamic web applications. Examples of these web applications include Gmail, Google Maps, Facebook, and many others.

    XMLHttpRequest is subject to the browser's same origin policy in that, for security reasons, requests will only succeed if they are made to the same server that served the original web page. There are alternative ways to circumvent this policy if required.

    History and support

    The concept behind the XMLHttpRequest object was originally created by the developers of Outlook Web Access (by Microsoft) for Microsoft Exchange Server 2000. An interface called IXMLHTTPRequest was developed and implemented into the second version of the MSXML library using this concept. The second version of the MSXML library was shipped with Internet Explorer 5.0 in March 1999, allowing access, via ActiveX, to the IXMLHTTPRequest interface using the XMLHTTP wrapper of the MSXML library.

    The Mozilla project developed and implemented an interface called nsIXMLHttpRequest into the Gecko layout engine. This interface was modeled to work as closely to Microsoft's IXMLHTTPRequest interface as possible. Mozilla created a wrapper to use this interface through a JavaScript object which they called XMLHttpRequest. The XMLHttpRequest object was accessible as early as Gecko version 0.6 released on December 6 of 2000, but it was not completely functional until as late as version 1.0 of Gecko released on June 5, 2002. The XMLHttpRequest object became a de facto standard in other major web clients, implemented in Safari 1.2 released in February 2004, Konqueror, Opera 8.0 released in April 2005, and iCab 3.0b352 released in September 2005.

    The World Wide Web Consortium published a Working Draft specification for the XMLHttpRequest object on April 5, 2006, edited by Anne van Kesteren of Opera Software and Dean Jackson of W3C. Its goal is "to document a minimum set of interoperable features based on existing implementations, allowing Web developers to use these features without platform-specific code." The last revision to the XMLHttpRequest object specification was on November 19 of 2009, being a last call working draft.

    Microsoft added the XMLHttpRequest object identifier to its scripting languages in Internet Explorer 7.0 released in October 2006.

    With the advent of cross-browser JavaScript libraries such as jQuery and the Prototype JavaScript Framework, developers can invoke XMLHttpRequest functionality without coding directly to the API. Prototype provides an asynchronous requester object called Ajax.Request that wraps the browser's underlying implementation and provides access to it. jQuery objects represent or wrap elements from the current client-side DOM. They all have a .load() method that takes a URI parameter and makes an XMLHttpRequest to that URI, then by default places any returned HTML into the HTML element represented by the jQuery object.

    The W3C has since published another Working Draft specification for the XMLHttpRequest object, "XMLHttpRequest Level 2", on February 25 of 2008. Level 2 consists of extended functionality to the XMLHttpRequest object, including, but not currently limited to, progress events, support for cross-site requests, and the handling of byte streams. The latest revision of the XMLHttpRequest Level 2 specification is that of 16 August 2011, which is still a working draft.

    As of 5 December 2011, XMLHttpRequest version 2 has been merged into the main XMLHttpRequest specification, and there is no longer a version 1 and a version 2.

    Cross-domain requests

    In the early development of the World Wide Web, it was found possible to breach users' security by the use of JavaScript to exchange information from one web site with that from another less reputable one. All modern browsers therefore implement a same origin policy that prevents many such attacks, such as cross-site scripting. XMLHttpRequest data is subject to this security policy, but sometimes web developers want intentionally to circumvent its restrictions. This is sometimes due to the legitimate use of subdomains as, for example, making an XMLHttpRequest from a page created by for information from will normally fail.

    Various alternatives exist to circumvent this security feature, including using JSONP, Cross-Origin Resource Sharing or alternatives with plugins such as Flash or Silverlight. XMLHttpRequest Level 2 also includes a feature to communicate with other domains. This is implemented in Firefox 3.5, Google Chrome, and Safari 4. Internet Explorer 8 has the non-standard XDomainRequest, which can do a similar thing.

    Headers added to a server's HTTP response headers can allow cross-domain requests to succeed. For example, Access-Control-Allow-Origin: *, can allow all domains to access a server. Access-Control-Allow-Origin can be used in all browsers that support cross-domain requests, which includes Internet Explorer 8. The W3C's specification is defined in Cross-Origin Resource Sharing. When the request succeeds, a status 200 (OK) is returned; however, errors from cross-domain requests will not be identified and the status will always be zero.

    Comet :
    Comet (programming)

    Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term, encompassing multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins. The Comet approach differs from the original model of the web, in which a browser requests a complete web page at a time.

    The use of Comet techniques in web development predates the use of the word Comet as a neologism for the collective techniques. Comet is known by several other names, including Ajax Push, Reverse Ajax, Two-way-web, HTTP Streaming, and HTTP server push among others.


    Comet applications attempt to eliminate the limitations of the page-by-page web model and traditional polling by offering real-time interaction, using a persistent or long-lasting HTTP connection between the server and the client. Since browsers and proxies are not designed with server events in mind, several techniques to achieve this have been developed, each with different benefits and drawbacks. The biggest hurdle is the HTTP 1.1 specification, which states that a browser should not have more than two simultaneous connections with a web server. Therefore, holding one connection open for real-time events has a negative impact on browser usability: the browser may be blocked from sending a new request while waiting for the results of a previous request, e.g., a series of images. This can be worked around by creating a distinct hostname for real-time information, which is an alias for the same physical server.

    Specific methods of implementing Comet fall into two major categories: streaming and long polling.


    An application using streaming Comet opens a single persistent connection from the client browser to the server for all Comet events. These events are incrementally handled and interpreted on the client side every time the server sends a new event, with neither side closing the connection. Specific techniques for accomplishing streaming Comet include the following:

    Hidden iframe

    A basic technique for dynamic web application is to use a hidden iframe HTML element (an inline frame, which allows a website to embed one HTML document inside another). This invisible iframe is sent as a chunked block, which implicitly declares it as infinitely long (sometimes called "forever frame"). As events occur, the iframe is gradually filled with script tags, containing JavaScript to be executed in the browser. Because browsers render HTML pages incrementally, each script tag is executed as it is received. Some browsers require a specific minimum document size before parsing and execution is started, which can be obtained by initially sending 1-2 kB of padding spaces.

    One benefit of the iframe method is that it works in every common browser. Two downsides of this technique are the lack of a reliable error handling method, and the impossibility of tracking the state of the request calling process.


    The XMLHttpRequest (XHR) object, the main tool used by Ajax applications for browser–server communication, can also be pressed into service for server–browser Comet messaging, in a few different ways.

    In 1995, Netscape Navigator added a feature called - server push -, which allowed servers to send new versions of an image or HTML page to that browser, as part of a multipart HTTP response (see History section, below), using the content type multipart/x-mixed-replace. Since 2004, Gecko-based browsers such as Firefox accept multipart responses to XHR, which can therefore be used as a streaming Comet transport. On the server side, each message is encoded as a separate portion of the multipart response, and on the client, the callback function provided to the XHR onreadystatechange function will be called as each message arrives. This functionality is included in Gecko-based browsers, there is discussion of adding it to WebKit. Internet Explorer 10 also supports this functionality.

    Instead of creating a multipart response, and depending on the browser to transparently parse each event, it is also possible to generate a custom data format for an XHR response, and parse out each event using browser-side JavaScript, relying only on the browser firing the onreadystatechange callback each time it receives new data.

    Ajax with long polling

    None of the above streaming transports work across all modern browsers without negative side-effects. This forces Comet developers to implement several complex streaming transports, switching between them depending on the browser. Consequently many Comet applications use long polling, which is easier to implement on the browser side, and works, at minimum, in every browser that supports XHR. As the name suggests, long polling requires the client to poll the server for an event (or set of events). The browser makes an Ajax-style request to the server, which is kept open until the server has new data to send to the browser, which is sent to the browser in a complete response. The browser initiates a new long polling request in order to obtain subsequent events. Specific technologies for accomplishing long-polling include the following:

    XMLHttpRequest long polling

    For the most part, XMLHttpRequest long polling works like any standard use of XHR. The browser makes an asynchronous request of the server, which may wait for data to be available before responding. The response can contain encoded data (typically XML or JSON) or Javascript to be executed by the client. At the end of the processing of the response, the browser creates and sends another XHR, to await the next event. Thus the browser always keeps a request outstanding with the server, to be answered as each event occurs.

    Script tag long polling

    While any Comet transport can be made to work across subdomains, none of the above transports can be used across different second-level domains (SLDs), due to browser security policies designed to prevent cross-site scripting attacks. That is, if the main web page is served from one SLD, and the Comet server is located at another SLD (which does not have cross origin resource sharing enabled), Comet events cannot be used to modify the HTML and DOM of the main page, using those transports. This problem can be sidestepped by creating a proxy server in front of one or both sources, making them appear to originate from the same domain. However, this is often undesirable for complexity or performance reasons.

    Unlike iframes or XMLHttpRequest objects, script tags can be pointed at any URI, and JavaScript code in the response will be executed in the current HTML document. This creates a potential security risk for both servers involved, though the risk to the data provider (in our case, the Comet server) can be avoided using JSONP.

    A long-polling Comet transport can be created by dynamically creating script elements, and setting their source to the location of the Comet server, which then sends back JavaScript (or JSONP) with some event as its payload. Each time the script request is completed, the browser opens a new one, just as in the XHR long polling case. This method has the advantage of being cross-browser while still allowing cross-domain implementations.

    WebSocket :

    WebSocket is a web technology providing full-duplex communications channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011, and the WebSocket API in Web IDL is being standardized by the W3C.

    WebSocket is designed to be implemented in web browsers and web servers, but it can be used by any client or server application. The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. The WebSocket protocol makes possible more interaction between a browser and a web site, facilitating live content and the creation of real-time games. This is made possible by providing a standardized way for the server to send content to the browser without being solicited by the client, and allowing for messages to be passed back and forth while keeping the connection open. In this way a two-way (bi-directional) ongoing conversation can take place between a browser and the server. A similar effect has been achieved in non-standardized ways using stop-gap technologies such as Comet.

    In addition, the communications are done over TCP port number 80, which is of benefit for those environments which block non-standard Internet connections using a firewall. WebSocket protocol is currently supported in several browsers including Google Chrome, Internet Explorer, Firefox, Safari and Opera. WebSocket also requires web applications on the server to support it.

    Technical overview

    Like TCP, WebSocket provides for full-duplex communication. Websocket differs from TCP in that it enables a stream of messages instead of a stream of bytes. Before WebSocket, port 80 full-duplex communication was attainable using Comet channels; however, comet implementation is nontrivial, and due to the TCP handshake and HTTP header overhead, it is inefficient for small messages. WebSocket protocol aims to solve these problems without compromising security assumptions of the web.

    Browser implementation

    A secure version of the WebSocket protocol is implemented in Firefox 6 (named MozWebSocket), Google Chrome 14, Opera 12.10 and Internet Explorer 10. An older, less secure version of the protocol was implemented in Opera 11 and Safari 5, as well as the mobile version of Safari in iOS 4.2. Also, the BlackBerry Browser in OS7 implements WebSocket. Although there are no known exploits, it was disabled in Firefox 4 and 5, and Opera 11.

    Proxy traversal

    WebSocket protocol client implementations try to detect if the user agent is configured to use a proxy when connecting to destination host and port and, if it is, uses HTTP CONNECT method to set up a persistent tunnel.

    While the WebSocket protocol itself is unaware of proxy servers and firewalls, it features an HTTP-compatible handshake so that HTTP servers can share their default HTTP and HTTPS ports (80 and 443) with a WebSocket gateway or server. The WebSocket protocol defines a ws:// and wss:// prefix to indicate a WebSocket and a WebSocket Secure connection, respectively. Both schemes use an HTTP upgrade mechanism to upgrade to the WebSocket protocol. Some proxy servers are transparent and work fine with WebSocket; others will prevent WebSocket from working correctly, causing the connection to fail. In some cases, additional proxy server configuration may be required, and certain proxy servers may need to be upgraded to support WebSocket.

    If unencrypted WebSocket traffic flows through an explicit or a transparent proxy server on its way to the WebSocket server, then, whether or not the proxy server behaves as it should, the connection is almost certainly bound to fail today (as WebSocket become more mainstream, proxy servers may become WebSocket aware). Therefore, unencrypted WebSocket connections should be used only in the simplest topologies.

    If an encrypted WebSocket connection is used, then the use of Transport Layer Security (TLS) in the WebSocket Secure connection ensures that an HTTP CONNECT command is issued when the browser is configured to use an explicit proxy server. This sets up a tunnel, which provides low-level end-to-end TCP communication through the HTTP proxy, between the WebSocket Secure client and the WebSocket server. In the case of transparent proxy servers, the browser is unaware of the proxy server, so no HTTP CONNECT is sent. However, since the wire traffic is encrypted, intermediate transparent proxy servers may simply allow the encrypted traffic through, so there is a much better chance that the WebSocket connection will succeed if WebSocket Secure is used. Using encryption is not free of resource cost, but often provides the highest success rate.

    A mid-2010 draft (version hixie-76) broke compatibility with reverse-proxies and gateways by including 8 bytes of key data after the headers, but not advertising that data in a Content-Length: 8 header.[10] This data was not forwarded by all intermediates, which could lead to protocol failure. More recent drafts (e.g., hybi-09[11]) put the key data in a Sec-WebSocket-Key header, solving this problem.

    URI scheme

    The WebSocket protocol specification defines two new URI schemes, ws: and wss: for unencrypted and encrypted connections respectively. Apart from the scheme name, the rest of the URI components are defined to use URI generic syntax.

    Adobe Flex Or Apache Flex:
    Adobe Flex Or Apache Flex
    Apache Flex

    Apache Flex, formerly Adobe Flex, is a software development kit (SDK) for the development and deployment of cross-platform rich Internet applications based on the Adobe Flash platform. Initially developed by Macromedia and then acquired by Adobe Systems, Flex was donated by Adobe to the Apache Software Foundation in 2011 and promoted to a top-level project in December 2012.

    The Flex 3 SDK was released under the open source Mozilla Public License in 2008. Consequently, Flex applications can be developed using standard IDEs, for example Eclipse, as well as the proprietary Adobe Flash Builder. The latest version of the SDK is version 4.9. It is released under version 2 of the Apache License.


    Flex uses MXML to define UI layout and other non-visual static aspects, ActionScript to address dynamic aspects and as code-behind, and targets Adobe AIR or Flash Player as runtime of the resultant application.

    Adobe Flash Catalyst

    On October 2, 2007, Adobe announced a new design tool related to Flex codenamed Adobe Thermo. On November 17, 2008 Adobe announced the official name of the product would be Adobe Flash Catalyst.

    On April 23, 2012, Adobe announced to discontinue the production of Flash Catalyst in order to streamline the product line.

    LiveCycle Data Services

    LiveCycle Data Services (previously called Flex Data Services) is a server-side complement to the main Flex SDK and Flash Builder IDE and is part of a family of server-based products available from Adobe. Deployed as a Java EE application, LiveCycle Data Services adds the following capabilities to Flex applications:

    Remoting, which allows Flex client applications to invoke methods on Java server objects directly. Similar to Java remote method invocation (RMI), remoting handles data marshalling automatically and uses a binary data transfer format.

    Messaging, which provides the "publish" end of the "publish/subscribe" design pattern. The Flash client can publish events to a topic defined on the server, subscribe to events broadcast from the message service. One of the common use cases for this is real-time streaming of data, such as financial data or system status information.

    Data management services, which provides a programming model for automatically managing data sets that have been downloaded to the Flex client. Once data is loaded from the server, changes are automatically tracked and can be synchronized with the server at the request of the application. Clients are also notified if changes to the data set are made on the server.

    PDF document generation, providing APIs for generating PDF documents by merging client data or graphics with templates stored on the server.


    Previously available only as part of Adobe LiveCycle Data Services ES, Adobe plans to contribute the BlazeDS technologies to the community under the LGPL v3. BlazeDS gives Adobe developers free access to the remoting and messaging technologies developed by Adobe.

    Concurrent with pre-release of BlazeDS, Adobe is publishing the AMF binary data protocol specification, on which the BlazeDS remoting implementation is based, and is attempting to partner with the community to make this protocol available for major server platforms.

    Granite Data Services

    Granite Data Services (GraniteDS) is the main open source alternative to Adobe JavaEE server solutions (LCDS and BlazeDS). It is released under the LGPL v2.1 and provides:

    AMF remoting.
    • Comet-based real time messaging (Data Push).
    • Integration with major application servers: JBoss, GlassFish, WebLogic, WebSphere, Tomcat, Jetty.
    • Integration with major JavaEE frameworks: EJB3, Spring, Seam.
    • Integration with major JPA engines: Hibernate, EclipseLink, OpenJPA, DataNucleus, all with full lazy-loading support.
    • Code generation tools (called "Gas3") that replicate Java entities and services in ActionScript3.
    • A Flex development frame work with weborb use is very common nowadays.

  • .

    Flex and ColdFusion

    Flex 2 offers special integration with ColdFusion MX 7. The ColdFusion MX 7.0.2 release adds updated Flash Remoting to support ActionScript 3, a Flex Data Services event gateway, and the Flex Data Services assembler. Flex Builder 2 also adds extensions for ColdFusion providing a set of wizards for RAD Flex development. A subset of Flex 1.5 is also embedded into ColdFusion MX 7 middleware platform, for use in the ColdFusion Flash forms feature. It is possible to use this framework to write rich Internet applications, although its intended purpose is for rich forms only.

    Dojo Toolkit :
    Dojo Toolkit

    Dojo Toolkit (stylized as dojo toolkit) is an open source modular JavaScript library (or more specifically JavaScript toolkit) designed to ease the rapid development of cross-platform, JavaScript/Ajax-based applications and web sites. It was started by Alex Russell, Dylan Schiemann, David Schontzler, and others in 2004 and is dual-licensed under the modified BSD license or the Academic Free License (= 2.1). The Dojo Foundation is a non-profit organization created with the goal to promote the adoption of the toolkit.


    Dojo is a JavaScript framework targeting the many needs of large-scale client-side web development. For example, Dojo abstracts the differences among diverse browsers to provide APIs that will work on all of them (it can even run on the server under Node.js); it establishes a framework for defining modules of code and managing their interdependencies; it provides build tools for optimizing JavaScript and CSS, generating documentation, and unit testing; it supports internationalization, localization, and accessibility; and it provides a rich suite of commonly-needed utility classes and user-interface widgets.

    Dojo is completely open-source. The entire toolkit can be downloaded as a ZIP and is also hosted on the Google CDN. The toolkit includes about three thousand JavaScript modules, in addition to images and other resources.

    • The Dojo Toolkit is organized in several parts:
    • dojo contains the core and most non-visual modules.
    • dijit is a library of user-interface modules for widgets and layout.
    • dojox holds assorted modules not yet considered stable enough to include in dojo or dijit.
    • util includes build tools such as optimization, documentation, style-checking, and testing.

  • .


    Dojo widgets are components comprising JavaScript code, HTML markup, and CSS style declarations - that provide multi-browser (not to be confused with cross-browser), interactive features:

    • Menus, tabs, and tooltips
    • Sortable tables
    • Dynamic charts
    • 2D vector drawings
    • Animated effects - fades, wipes and slides - facilities for custom animation effects
    • Tree widgets that support drag-and-drop
    • Various forms and routines for validating form input
    • Calendar-based date selector, time selector, and clock
    • Core widgets
    • Maps (geographical openlayer-based maps & dashboard vector-based maps)
    • Gauges (horizontal, vertical, circular)
    • Also for 3D

  • .


    Skins can be used to change the look and feel of Dojo widgets that are used on a page.

    Asynchronous communication

    One important feature of Ajax applications is asynchronous communication of the browser with the server: information is exchanged and the page's presentation is updated without a need for reloading the whole page. Traditionally, this is done with the JavaScript object XMLHttpRequest. Dojo provides an abstracted wrapper (dojo.xhr) around various web browsers' implementations of XMLHttpRequest, and also supports other transports (such as hidden IFrames) and a variety of data formats. Using this approach, it is easy to have the data a user enters into a form sent to the server "behind the scenes"; the server can then reply with some JavaScript code that updates the presentation of the page.

    Packaging system

    Dojo provides a packaging system to facilitate modular development of functionality in individual packages and sub-packages; the base Dojo "bootstrap" script initializes a set of hierarchical package namespaces -- "io", "event", etc. -- under a root "dojo" namespace. After initialization of the root namespace any Dojo package can be loaded (via XMLHttpRequest or other similar transport) by using utility functions supplied in the bootstrap. It is also possible to initialize additional namespaces within or parallel to the "dojo" namespace, allowing extensions of Dojo or the development of private Dojo-managed namespaces for third-party libraries and applications.

    Dojo packages can consist of multiple files, and can specify which files constitute the entire package. Any package or file can also specify a dependency on other packages or files; when the package is loaded, any dependencies it specifies will also be loaded.

    Workarounds for cross-domain loading of most Dojo packages are provided (though this requires a specialized build of Dojo). Dojo also provides a mechanism for building "profiles"; the build system takes as input a list of packages, and uses Rhino to create a single compressed JavaScript file containing those packages and all their dependencies. This allows all necessary code to be loaded and initialized at once, and permits caching of the code (most web browsers do not cache files loaded via XMLHttpRequest). Pre-built profiles for some common use cases are available for download from the same location as the full toolkit.

    Client-side data storage

    In addition to providing support functions for reading and writing cookies, Dojo also provides a local, client-side storage abstraction named Dojo Storage. Dojo Storage allows web applications to store data on the client-side, persistently and securely and with a user's permission. It works across existing web browsers, including Internet Explorer, Firefox, and Safari. When included in a web page, Dojo Storage determines the best method for persistently storing information. On Firefox 2, it uses native browser persistence; on other browsers it uses a hidden Flash applet. With Flash 6+ being installed on about 95% of computers connected to the web, this makes the storage mechanism accessible for much of the web's installed base. For a web application that is being loaded from the file system (i.e. from a file:// URL), Dojo Storage will transparently use XPCOM on Firefox and ActiveX on Internet Explorer to persist information. The programmer using Dojo Storage is abstracted from the storage mechanism used and is presented with a simple hash table abstraction, with methods such as put() and get(). Dojo Storage is not supported in versions later than the 1.3 release.

    Server-side data storage

    As of January 2007, Dojo includes the following example server-side datastore implementations in the namespace:

    • CsvStore: a read-only store that reads tabular data from comma-separated values files
    • OpmlStore: a read-only store that reads hierarchical data from OPML format files
    • YahooStore: a read-only store that fetches search results from the Yahoo! Search web service
    • DeliciousStore: a read-only store that fetches bookmarks from the web service
    • RdfStore: a read-write store that uses SPARQL to talk to RDF data servers including, for example, the Rhizome RDF application server.

  • .

    Support for Adobe Integrated Runtime (AIR)

    Dojo can be used in JavaScript-based Adobe AIR applications. It has been modified to meet AIR's security requirements. SitePen, a Dojo consulting company, has made an Adobe AIR application called "Dojo Toolbox" using Dojo. It includes an API viewer, and a GUI to Dojo's build system. Normally, the build system is run from within Rhino, but in this AIR application the build system can be run from AIR, without use of java.

    DWR (Java) :
    DWR (Java)

    Direct Web Remoting

    The DWR project was started by Joe Walker in 2004. DWR, or Direct Web Remoting, is a Java open source library that helps developers write web sites that include Ajax technology. It allows code in a web browser to use Java functions running on a web server as if those functions were within the browser.

    It consists of two main parts :

    Code to allow JavaScript to retrieve data from a servlet-based web server using Ajax principles.

    A JavaScript library that makes it easier for the web site developer to dynamically update the web page with the retrieved data.

    DWR takes a novel approach to Ajax by dynamically generating JavaScript code based on Java classes. Thus the web developer can use Java code from JavaScript as if it were local to the web browser; whereas in reality the Java code runs in the web server and has full access to web server resources. For security reasons the web developer must configure exactly which Java classes are safe to export (which is often called web.xml or dwr.xml)

    This method of remoting functions from Java to JavaScript gives DWR users a feel much like conventional RPC mechanisms like RMI or SOAP, with the benefit that it runs over the web without requiring web browser plug-ins.

    DWR does not consider the web browser / web server protocol to be important, and prefers to ensure that the programmer's interface is natural. The greatest challenge to this is to marry the asynchronous nature of Ajax with the synchronous nature of normal Java method calls.

    In the asynchronous model, result data is only available some time after the initial call is made. DWR solves this problem by allowing the web developer to specify a function to be called when the data is returned using an extra method parameter. This extra method is called CallBack Method. The value returned from the java function will be passed to the callback method.

    Yahoo! User Interface Library (YUI) :
    Yahoo! User Interface Library (YUI)

    The Yahoo! User Interface Library (YUI) is an open-source JavaScript library for building richly interactive web applications using techniques such as Ajax, DHTML and DOM scripting. YUI includes several core CSS resources. It is available under a BSD License. Development on YUI began in 2005 and Yahoo! properties such as My Yahoo! and the Yahoo! front page began using YUI in the summer of that year. YUI was released for public use in February 2006. It is actively developed by a core team of Yahoo! engineers.

    In September 2009, Yahoo! released YUI 3, a new version of YUI rebuilt from the ground up to modernize the library and incorporate lessons learned from YUI 2. Among the enhancements are a CSS selector driven engine, like jQuery, for retrieving DOM elements, a greater emphasis on granularity of modules, a smaller seed file that loads other modules when necessary, and a variety of syntactic changes intended to make writing code faster and easier.

    The YUI Library project at Yahoo! was founded by Thomas Sha and sponsored internally by Yahoo! co-founder Jerry Yang; its principal architects have been Sha, Adam Moore, and Matt Sweeney. The library's developers maintain the YUIBlog; the YUI community discusses the library and implementations in its community forum.

    Features :

    The YUI Library is fully documented on its website; detailed API documentation accompanies the library download. It has six types of components: YUI core, utilities, UI controls, CSS components, developer tools, and build tools.

    Core : The YUI Core is a light (31KB minified) set of tools for event management and DOM manipulation.

    YUI Global Object : The YUI Global Object contains language utilities, a script loader, and other baseline infrastructure for YUI.

    Dom Collection : Helps with common DOM scripting tasks, including element positioning and CSS style management.

    Event Utility : Provides developers with easy and safe access to browser events (such as mouse clicks and key presses). It also provides the Custom Event object for publishing and subscribing to custom events.

    Utilities :

    Animation : Helps create "effects" by animating the position, size, opacity or other characteristics of page elements.

    Browser History Manager : Helps web applications use the browser's back button and bookmarking functionality.

    Connection Manager : Helps manage XMLHttpRequest transactions in a cross-browser fashion. It has integrated support for form posts, error handling, callbacks and file uploading.

    Cookie : Allows you to manage browser cookies and subcookies through a simple API.

    DataSource : Provides a common configurable interface for other components to interact with different types of data, from simple JavaScript arrays to online servers over XHR.

    Drag and drop The YUI Drag and Drop Utility makes it easy to make elements "draggable" and to create drop targets that respond to drag events.

    Element : Provides a wrapper for HTML elements in the DOM and makes simpler common tasks such as adding listeners, manipulating the DOM, and setting and getting attributes.

    Get : The Get Utility supports the asynchronous loading of data and scripts through script nodes and the dynamic loading of external CSS files.

    ImageLoader : YUI's ImageLoader allows you to defer the loading of images that are not visible in the viewport at the time the page loads. This can result in big performance boosts.

    JSON : The JSON Utility provides methods for validation of incoming JSON data to verify that it is safe and methods to convert JavaScript data to a JSON-formatted string. These methods are based on Douglas Crockford's work at

    Resize : Allows you to make any block-level HTML element resizable.

    Selector : The YUI Selector Utility allows you to grab references to HTML elements via CSS3 selector syntax.

    YUI Loader : YUI Loader is a client-side loader engine that can dynamically load any YUI component (and dependencies) on the fly.


    AutoComplete : Provides autocomplete feature (suggestion lists and type-ahead functionality) for user interactions involving text-entry. It supports a variety of data-source formats. It also supports server-side data-sources via XMLHttpRequest.

    Button : Enables the creation of rich, graphical buttons that function like traditional HTML form buttons.

    Calendar : A graphical, dynamic control used for date selection.

    Charts : The Charts Control retrieves data via the DataSource Utility and displays the data in a variety of common chart formats (line, bar, pie, etc.)

    Color Picker : The Color Picker Control provides a rich visual interface for color selection.

    Container : Supports a variety of DHTML windowing patterns including Tooltip, Panel, Dialog, SimpleDialog, Module and Overlay.

    DataTable : Simple yet powerful API to display screen-reader accessible tabular data on a web page. Notable features include sortable columns, pagination, scrolling, row selection, resizeable columns, and inline editing.

    ImageCropper : ImageCropper provides the UI and interactive elements for a client-side image cropper.

    Layout Manager : Allows you to create cross-browser, pixel perfect layouts with little effort by providing a fixed layout containing, top, bottom, left, right and center layout units.

    Menu : Provides an easy API for creating fly-out menus, menu bars, and context menus.

    Rich Text Editor : The YUI Rich Text Editor is a sophisticated client-side text-processor that is modular and highly configurable, suitable for any open-ended text-entry situation.

    Slider : Provides a generic slider element that enables the user to choose within a finite range of values on one or two axes.

    TabView : Provides navigable tabbed views of content; supports dynamic loading of tab content via XMLHttpRequest.

    TreeView : Produces a content tree whose nodes can be expanded and contracted.

    Uploader : Allows for multi-file file upload with feedback on upload progress.

    CSS resources

    CSS Base : Use Base after Reset to provide a consistent, cross-browser replacement for the standard browser CSS rules to which web developers are accustomed.
    CSS Grids : Seven basic page wireframes with subsection components to support over 1000 different page layouts.
    CSS Fonts : Standardized cross-browser font families and size rendering.
    CSS Reset : CSS declarations remove margins and standardize cross-browser rendering on common elements.

    Developer tools
    • Logger
    • Provides a quick and easy way to write log messages to an on-screen console, the Firebug extension for Mozilla Firefox, or the Safari JavaScript console.
    • Profiler
    • A cross-browser, non-visual code profiler for JavaScript.
    • ProfilerViewer
    • Used in combination with Profiler to provide rich visualizations of your profiling data — both graphically (using the Charts Control) and in tabular format (using DataTable).
    • YUI Test : YUI Test is a testing framework for browser-based JavaScript solutions. Using YUI Test, you can easily add unit testing to your JavaScript solutions. While not a direct port from any specific xUnit framework, YUI Test does derive some characteristics from nUnit and JUnit.

  • .

    Build Tools

    YUI Compressor : YUI Compressor is a tool that minifies JavaScript and CSS safely.

    YUIDoc : YUIDoc is a tool written in JavaScript that generates searchable API documentation of JavaScript code. It is typically used as part of a build process. YUIDoc is comment-driven and is compatible with a variety of coding styles and programming languages.

    Google Web Toolkit :
    Google Web Toolkit

    Google Web Toolkit (GWT /'gw?t/) is an open source set of tools that allows web developers to create and maintain complex JavaScript front-end applications in Java. Other than a few native libraries, everything is Java source that can be built on any supported platform with the included GWT Ant build files. It is licensed under the Apache License version 2.0

    GWT emphasizes reusable, efficient approaches to common web development tasks, namely asynchronous remote procedure calls, history management, bookmarking, UI abstraction, internationalization, and cross-browser portability.


    GWT version 1.0 RC 1 was released on May 16, 2006. Google announced GWT at the JavaOne conference, 2006

    In August 2010, Google acquired Instantiations, a company known for its focus on Eclipse Java developer tools, including GWT Designer, which is now bundled with Google Plugin for Eclipse.

    With introduction of the Dart programming language, Google has reassured the GWT community that GWT will continue to be supported for the foreseeable future, but also hinted at a possible rapprochement between the two Google solutions for "structured web programming". They've also admitted however that a number of engineers previously working on GWT are now working on Dart.

    Development with GWT

    Using GWT, developers can develop and debug Ajax applications in the Java language using the Java development tools of their choice. When the application is deployed, the GWT cross-compiler translates the Java application to standalone JavaScript files that are optionally obfuscated and deeply optimized. When needed, JavaScript can also be embedded directly into Java code, in the form of comment.

    GWT does not revolve only around user interface programming; it is a general set of tools for building any sort of high-performance client-side JavaScript functionality. In live presentations, the developers of GWT emphasize that "GWT is not its libraries" and that it only includes a library but is not fundamentally yet another Ajax library. This open-ended philosophy sometimes surprises developers new to GWT who expect it to provide an end-to-end "on rails" application framework. Indeed, many key architectural decisions are left completely to the developer. The GWT mission statement clarifies the philosophical breakdown of GWT's role versus the developer's role. History is an example of such: although GWT manages history tokens as users click Back or Forward in the browser, it does not prescribe how to map history tokens to an application state.

    GWT applications can be run in two modes :

    Development mode (formerly Hosted mode): The application is run as Java bytecode within the Java Virtual Machine (JVM). This mode is typically used for development, supporting hot swapping of code and debugging.

    Production mode (formerly Web mode): The application is run as pure JavaScript and HTML, compiled from the Java source. This mode is typically used for deployment.

    Several open-source plugins are available for making GWT development easier with other IDEs. E.g., GWT4NB for NetBeans, Cypal Studio for GWT, Eclipse and JDeveloper etc. The Google Plugin for Eclipse handles most GWT related tasks in the IDE, including creating projects, invoking the GWT compiler, creating GWT launch configurations, validations, syntax highlighting, etc.


    The major GWT components include :

    • GWT Java-to-JavaScript Compiler
    • Translates the Java programming language to the JavaScript programming language.
    • GWT Development Mode
    • Allows the developers to run and execute GWT applications in development mode (the app runs as Java in the JVM without compiling to JavaScript). Prior to 2.0, GWT hosted mode provided a special-purpose "hosted browser" to debug your GWT code. In 2.0, the web page being debugged is viewed within a regular browser. Development mode is supported through the use of a native-code plugin called the Google Web Toolkit Developer Plugin for many popular browsers.
    • JRE emulation library
    • JavaScript implementations of the commonly used classes in the Java standard class library (such as most of the java.lang package classes and a subset of the java.util package classes).
    • GWT Web UI class library
    • A set of custom interfaces and classes for creating widgets.

  • .

    • Dynamic and reusable UI components: programmers can use pre-designed classes to implement otherwise time-consuming dynamic behaviors, such as
    • drag-and-drop or sophisticated visual tree structures.
    • Simple RPC mechanism
    • Browser history management
    • Support for full-featured Java debugging
    • GWT handles some cross-browser issues for the developer.
    • JUnit integration
    • Support for Internationalization and localization
    • HTML Canvas support (subject to API changes)
    • The developers can mix handwritten JavaScript in the Java source code using the JavaScript Native Interface (JSNI).
    • Support for using Google APIs in GWT applications (initially, support for Google Gears)
    • Open-source
    • The developers can design and develop their application in a pure object-oriented fashion, since they're using Java (instead of JavaScript).
    • Common JavaScript errors, such as typos and type mismatches, are caught at compile time.
    • The JavaScript that the GWT compiler generates can be tailored to be either unobfuscated and easy to understand or obfuscated and smaller to download.
    • A number of libraries are available for GWT, by Google and third parties. These extend GWT's features.

  • .

    Available Widgets
    • As of version 2.4 (September 2011), GWT offers several widgets:
    • Button
    • PushButton
    • RadioButton
    • CheckBox
    • DatePicker
    • ToggleButton
    • TextBox
    • PasswordTextBox
    • TextArea
    • Hyperlink
    • ListBox
    • CellList
    • MenuBar
    • Tree
    • CellTree
    • SuggestBox
    • RichTextArea
    • FlexTable
    • Grid
    • CellTable
    • CellBrowser
    • TabBar
    • DialogBox

  • .

    Available Panels :
    • GWT widgets also include several panels:
    • PopupPanel
    • StackPanel
    • StackLayoutPanel
    • HorizontalPanel
    • VerticalPanel
    • FlowPanel
    • VerticalSplitPanel
    • HorizontalSplitPanel
    • SplitLayoutPanel
    • DockPanel
    • DockLayoutPanel
    • TabPanel
    • TabLayoutPanel
    • DisclosurePanel
    • Many common widgets not found in the GWT have been implemented in third-party libraries, such as Ext GWT, GWT Component Library, GWT-Ext, GWT Widget Library, GWTiger, Rocket GWT, Dojo, SmartGWT etc.

  • .

    Enterprise Usage :

    GWT is widely used in the Enterprise space due to its leveraging of common enterprise technologies including Java, Apache Tomcat (or similar web container), Eclipse IDE, Internet Explorer, and Internationalization and Localization. Java-based GWT RIAs are easier to test[according to whom?] using the existing JUnit testing framework and code coverage tools, compared to large applications written in Javascript. Because GWT allows compile time verification of images, CSS, and business logic, many common development defects are automatically discovered without need of the manual testing commonly required by RIAs.

    Mobile :

    As a general framework for making web apps, GWT is also capable of being used as a framework for making mobile and tablet apps, either by making the needed widgets and animations from scratch, or by using one of the mobile frameworks for GWT. An HTML5 app written in GWT can have separate views for Tablets and Mobile phones.

    Some of the most common mobile GWT libraries :
      • GwtMobile
      • gwt-mobile-webkit
      • jqm4gwt
      • m-gwt

    • .

  • RichFaces :

    RichFaces is an open source Ajax-enabled component library for JavaServer Faces, hosted by JBoss. It allows easy integration of Ajax capabilities into enterprise application development.

    RichFaces is more than just a component library for JavaServer Faces. It adds :

    • Skinability (easily change and update application look and feel)
    • Component Development Kit (CDK) to assist in constructing JavaServer Faces components
    • Dynamic Resource Framework
    • Both page wide, and component based Ajax control components.

  • .


    RichFaces originated from Ajax4jsf framework which was created and designed by Alexander Smirnov. In the autumn of 2005 Smirnov joined Exadel and continued to develop the framework. The first version of what would become Ajax4jsf was released in March 2006. Later in the same year, Exadel VCP was split off and the Ajax4jsf framework and Rich Faces was born. While RichFaces provided out-of-the-box components (a "component-centric" Ajax approach, where components do everything you need), Ajax4jsf provided page-wide Ajax support. Developers specify which parts of the page should be processed on server after some client side user actions and which parts should be updated after processing. Ajax4jsf became an open source project hosted on while RichFaces became a commercial JSF component library.

    In March 2007 JBoss (now a division of Red Hat) and Exadel signed a partnership agreement where Ajax4jsf and RichFaces would now be under the JBoss umbrella and be called JBoss Ajax4jsf and JBoss RichFaces. RichFaces would now also be open source and free. In September 2007, JBoss and Exadel decided to merge Ajax4jsf and RichFaces under the RichFaces name. It made sense as both libraries were now free and open source. Having just one product solved many version and compatibility issues that existed before, such as which version of Ajax4jsf works with what version of RichFaces.


    The framework is implemented as a component library which adds Ajax capability into existing pages, so a developer doesn’t need to write any JavaScript code or to replace existing components with new Ajax widgets. RichFaces enables page-wide Ajax support instead of the traditional component-wide support. Hence, a developer can define the event on the page that invokes an Ajax request and the areas of the page that should be synchronized with the JSF Component Tree after the Ajax request changes the data on the server according to the events fired on the client.

    RichFaces allows you to define (by means of JSF tags) different parts of a JSF page you wish to update with an Ajax request, and provides a few options to send Ajax requests to the server. Also the JSF page doesn't change from a "regular" JSF page and you don't need to write any JavaScript code by hand. By controlling everything from the server side, almost no JavaScript is needed and the page state can be maintained easily in the server.

    RichFaces architecture

    The architecture of RichFaces consists of an Ajax filter, Ajax action components, Ajax containers, and a JavaScript engine. Ajax filter - In order get all benefits of RichFaces, a developer should register a filter in the web.xml file of the application. The filter recognizes multiple request types.

    Ajax action components - AjaxCommandButton, AjaxCommandLink, AjaxPoll and AjaxSupport and other action components can be used to send Ajax requests from the client side.

    Ajax containers - AjaxContainer is an interface that describes an area on a JSF page that should be decoded during an Ajax request. AjaxViewRoot and AjaxRegion are implementations of this interface.

    JavaScript engine - the RichFaces JavaScript engine runs on the client-side. It updates different areas on a JSF page based on the information from the Ajax response. The JavaScript engine provides an API so developers do not need to create their own JavaScript functionality.

    Skinnability :

    Skinnability is a special feature of RichFaces that is used for defining common interface styles. The feature is based on XCSS technology which provides flexibility and dynamics. RichFaces provides a set of predefined skins:

    • plain
    • emeraldTown
    • blueSky
    • wine
    • japanCherry
    • ruby
    • classic
    • deepMarine
    • Laguna (new - RichFaces 3.2.1)
    • GlassX (new - RichFaces 3.2.2)
    • DarkX (new - RichFaces 3.2.2)

  • .

    Skin properties, such as, generalBackgroundColor, generalLinkColor, headerFamilyFont etc. are stored in file. Each component has a XCSS (a special file format that combines flexibility of XML and CSS) file that performs mapping of CSS selectors to the skin properties of a particular skin. Additionally, RichFaces provides skinning for standard HTML controls. You can create a custom skin using Plug-n-Skin feature, which is a Maven archetype that builds a skeleton for a new skin.

    Backbase :

    Backbase is a software company, founded in the Netherlands in 2003, which has offices in Amsterdam, the Netherlands, New York, United States, Moscow, Russia and Singapore. The core products of Backbase are Backbase Portal and Backbase Forms.


    Backbase was founded in 2003 in Amsterdam, The Netherlands by Jouk Pleiter and Gerbert Kaandorp to develop an AJAX framework using HTML, Javascript and CSS. Backbase used the term Rich Internet Applications to classify its software. In February 2005, Jesse James Garret coined the term AJAX, after which classification - Ajax-based Rich Internet Applications - was adopted. In May 2005, the Backbase Community Edition (CE) was launched, supported by the Backbase Developer Network. The Backbase CE was a framework for developers and companies to build Rich and Web 2.0 Internet applications.

    In 2008, Backbase decided to develop its own Portal Software. Backbase had made a 180-degree turn in its focus based on a shift it saw in the market with company Marketing Departments beginning to take over responsibility from IT Departments for the customer-facing part of their web sites. Quality Open Source frameworks were also beginning to emerge and in 2009 Backbase released Backbase Portal 4. In May 2011, Backbase released Backbase Portal 5, with a total focus on widgets.

    At the beginning of 2011 Backbase opened an office in North America, in New York City, to better focus on its US customer-base.


    In September 2012, industry analyst Gartner placed Backbase Portal in the Visionary quadrant of its Magic Quadrant for Horizontal Portals:

    Backbase is one of the first portal-less portal vendors, with a focus on user experience and a lean portal architecture. The vendor started out as a small European vendor of client-side JavaScript framework (Ajax library), broadened its focus to include enterprise mashup capability and, in 2008, transitioned to a client-side lean portal. Since then, Backbase has grown and established a presence in the financial services vertical, and in additional geographies (North America). The vendor has fleshed out the lean portal with content, forms, mobile and social capabilities (in 2009 through 2010) and has further matured with UXP-like capabilities in 2012, such as support for targeting, integrated analytics, split A/B testing and online channel optimization. The current offering combines rich customer experience, management, easy personalization, integrated mobile support and an app store (called App Center).

    Forrester names Backbase as a vendor with a firm grasp of emerging customer needs and the potential impact of new technology.

    Vaadin :

    Vaadin is an open source Web application framework for rich Internet applications. In contrast to JavaScript libraries and browser-plugin based solutions, it features a server-side architecture, which means that the majority of the logic runs on the servers. Ajax technology is used at the browser-side to ensure a rich and interactive user experience. On the client-side Vaadin is built on top of and can be extended with Google Web Toolkit.


    Vaadin uses Java as the programming language for creating web content. The framework incorporates event-driven programming and widgets, which enables a programming model that is closer to GUI software development than traditional web development with HTML and JavaScript.

    Vaadin uses Google Web Toolkit for rendering the resulting web page. While the way Vaadin uses Google Web Toolkit, it only operates on client-side (i.e. a web browser's JavaScript engine) - which could lead to trust issues - Vaadin adds server-side data validation to all actions. This means that if the client data is tampered with, the server notices this and doesn't allow it.

    Vaadin's default component set can be extended with custom GWT widgets and themed with CSS.

    Vaadin is distributed as a collection of JAR files (either as direct downloads, or with Maven or Ivy integration), which can be included in any kind of Java web project developed with standard Java tools. In addition, there exists Vaadin plugins for the Eclipse IDE and NetBeans for easing the development of Vaadin applications as well as direct support of (and distribution) through Maven.

    Vaadin applications can be deployed as Java servlets for any Java web server, including Google App Engine. Applications can also be deployed as portlets to any Java portal. Vaadin also has some deeper integration with the Liferay Portal.

    Remote Application Platform :
    Remote Application Platform

    Remote Application Platform (RAP, formerly Rich Ajax Platform) Project is an open-source software project under the Eclipse Technology Project which aims to enable software developers to build Ajax-enabled rich Internet applications by using the Eclipse development model, plugins and a Java-only application programming interface (API). It can be considered a counterpart for web development to the Rich Client Platform (RCP). The API is very similar to RCP so developers who know RCP can reuse extant knowledge. RAP encourages sharing source code between RCP and RAP applications to reduce the development effort for business applications that need both desktop-based and web-based front ends.

    OpenXava :

    OpenXava is a web application framework for developing business applications in an effective way. It not only allows rapid and easy development of CRUD modules and report generation, but also provides flexibility to develop complex real life business applications like accounting packages, customer relationship, invoicing, warehouse management, etc.

    OpenXava allows developers to define applications with POJOs, JPA and Java 5 annotations.

    Currently OpenXava generates Java Web Applications (Java EE) which can be deployed in any Java Portal Server (JSR168) as portlet applications.

    The essence of OpenXava is that the developer defines instead of programming, and the framework automatically provides the user interface, the data access, the default behavior, etc. In this way, all common issues are solved easily, but the developer always has the possibility of manually programming any part of the application, in this way it is flexible enough to solve any particular cases. OpenXava is based on the concept of the business component.

    Business component versus MVC

    A business component includes all software artifacts needed to define a business concept. OpenXava is a business component framework because it allows defining all information about a business concept in a single place. For example, for defining the concept of Invoice, in OpenXava a single file ( is used, and all information about invoice concept (including data structure, user interface layout, mapping with database, validations, calculations, etc.) is defined there.

    In a MVC framework the business logic (the Model), the user interface (the View) and the behavior (the Controller) are defined separately. These types of frameworks are useful if the rate of change of logic and data structures is low and the possibility of changing user interface technology or data access technology is high.

    In OpenXava, the addition of a new field to an Invoice only requires changing a single file: But MVC frameworks are cumbersome when changes to structure and data are very frequent (as in the business application case). Imagine the simplest change, adding a new field to an Invoice. In the MVC framework the developer must change three sections: the user interface, the model class and the database table. Moreover if the developer uses Java EE design patterns he has to change the DTO class, the Facade Session Bean, the Entity Bean mapping, etc.

    Using OpenXava makes it possible to allocate the development work using a business logic oriented task distribution. For example Invoice to one developer, Delivery to another, as opposed to technology layer business logic to one developer, user interface to another.


    These are some of the main features of OpenXava:

    • High productivity for developing business applications.
    • Short learning curve and easy to use.
    • Flexible enough to create sophisticated applications.
    • It's possible to insert custom functionality in any place.
    • Based on the concept of business component.
    • Generate a full Java EE application, including AJAX user interface.
    • Supports any application server (Tomcat, JBoss, WebSphere, etc.).
    • Supports JSR168: All OpenXava modules are standard portlets too.
    • EJB3 JPA complete support
    • It's tested with the portals: Jetspeed-2, WebSphere Portal, Liferay and Stringbeans.
    • Easy integration of reports made with JasperReports (that use Jakarta Velocity and VTL - Velocity Template Language)
    • Licensed under GNU Lesser General Public License.
    • All labels and messages are in English, Spanish, German, Polish, Indonesian, French, Chinese, Italian and Catalan, with more coming.

  • .

    Echo (framework) :
    Echo (framework)

    Echo is a web application framework that was created by the company NextApp. It originally started as a request-response web application framework that leveraged the Swing object model to improve the speed of application development. Through the use of the swing model, Echo was able to employ concepts such as components and event-driven programming that removed much of the pain of web application development.


    In late 2005, NextApp formally announced the release of their new AJAX based web application platform, "Echo2". This framework built on the concepts of Echo (well known API, total web abstraction) but delivered the additional benefit of being an AJAX environment. NextApp believed that this approach brought the framework extremely close to the capabilities of rich clients. NextApp also claimed that this reincarnation of the Echo framework provided dramatic performance, capability, and user-experience enhancements made possible by its new Ajax-based rendering engine.


    During 2007, development on a third generation of the framework, Echo3, began. The focus of this evolution was to move away from generating markup on the server side, and instead to implement rendering peers as native Javascript objects, with an XML-based state synchronization protocol between client (web browser) and server. This was developed in tandem with a core javascript framework, providing the ability to define inheritance hierarchies in Javascript in a way familiar to developers of object-oriented languages.


    Echo is often compared to frameworks such as GWT (Google Web Toolkit) as both Echo and GWT (among others) offer a programming model that completely abstracts users from the web tier. However Echo differs substantially from GWT in the way it interacts with JavaScript. GWT essentially implements a subset of the Java API in Javascript, and as such, Java code is compiled to JavaScript and fully executed on the client side. Echo on the other hand offers since version 3 a dual-stack approach. Applications can be written in JavaScript (Client-side) or Java (Server-side) or in mixed forms.

    Comparable frameworks include Vaadin, RAP, ZK, Openlaszlo, Icefaces, Thinwire, Apache_Wicket, and jSeamless.

    Quality Service

    Quality in a service or product is not what you put into it. It is what the client or customer gets out of it.
    -Peter Drucker

    Intelligent Quotes

    A solid working knowledge of productivity software and other IT tools has become a basic foundation for success in virtually any career. Beyond that, however, I don't think you can overemphasise the importance of having a good background in maths and science.....
    "Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equivalent of a sound bite that describes the system's architecture)... A step in thr development process is to articulate this architectural framework, so that we might have a stable foundation upon which to evolve the system's function points. "
    "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change"
    "The ultimate measurement is effectiveness, not efficiency "
    "It is argued that software architecture is an effective tool to cut development cost and time and to increase the quality of a system. "Architecture-centric methods and agile approaches." Agile Processes in Software Engineering and Extreme Programming.
    "Java is C++ without the guns, knives, and clubs "
    "When done well, software is invisible"
    "Our words are built on the objects of our experience. They have acquired their effectiveness by adapting themselves to the occurrences of our everyday world."
    "I always knew that one day Smalltalk would replace Java. I just didn't know it would be called Ruby. "
    "The best way to predict the future is to invent it."
    "In 30 years Lisp will likely be ahead of C++/Java (but behind something else)"
    "Possibly the only real object-oriented system in working order. (About Internet)"
    "Simple things should be simple, complex things should be possible. "
    "Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines."
    "Model Driven Architecture is a style of enterprise application development and integration, based on using automated tools to build system independent models and transform them into efficient implementations. "
    "The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs. "
    "Software Engineering Economics is an invaluable guide to determining software costs, applying the fundamental concepts of microeconomics to software engineering, and utilizing economic analysis in software engineering decision making. "
    "Ultimately, discovery and invention are both problems of classification, and classification is fundamentally a problem of finding sameness. When we classify, we seek to group things that have a common structure or exhibit a common behavior. "
    "Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world. "
    "The entire history of software engineering is that of the rise in levels of abstraction. "
    "The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exist "

    Core Values ?

    Agile And Scrum Based Architecture

    Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration.....


    Core Values ?

    Total quality management

    Total Quality Management / TQM is an integrative philosophy of management for continuously improving the quality of products and processes. TQM is based on the premise that the quality of products and .....


    Core Values ?

    Design that Matters

    We are more than code junkies. We're a company that cares how a product works and what it says to its users. There is no reason why your custom software should be difficult to understand.....


    Core Values ?

    Expertise that is Second to None

    With extensive software development experience, our development team is up for any challenge within the Great Plains development environment. our Research works on IEEE international papers are consider....


    Core Values ?

    Solutions that Deliver Results

    We have a proven track record of developing and delivering solutions that have resulted in reduced costs, time savings, and increased efficiency. Our clients are very much ....


    Core Values ?

    Relentless Software Testing

    We simply dont release anything that isnt tested well. Tell us something cant be tested under automation, and we will go prove it can be. We create tests before we write the complementary production software......


    Core Values ?

    Unparalled Technical Support

    If a customer needs technical support for one of our products, no-one can do it better than us. Our offices are open from 9am until 9pm Monday to Friday, and soon to be 24hours. Unlike many companies, you are able to....


    Core Values ?

    Impressive Results

    We have a reputation for process genius, fanatical testing, high quality, and software joy. Whatever your business, our methods will work well in your field. We have done work in Erp Solutions ,e-commerce, Portal Solutions,IEEE Research....



    Why Choose Us ?

    Invest in Thoughts

    The intellectual commitment of our development team is central to the leonsoft ability to achieve its mission: to develop principled, innovative thought leaders in global communities.

    Read More
    From Idea to Enterprise

    Today's most successful enterprise applications were once nothing more than an idea in someone's head. While many of these applications are planned and budgeted from the beginning.

    Read More
    Constant Innovation

    We constantly strive to redefine the standard of excellence in everything we do. We encourage both individuals and teams to constantly strive for developing innovative technologies....

    Read More
    Utmost Integrity

    If our customers are the foundation of our business, then integrity is the cornerstone. Everything we do is guided by what is right. We live by the highest ethical standards.....

    Read More