An integration example
We are going to discuss an example of integrating a data grid widget as it is offered by the Ext JS framework, into the Backbase framework.
We have a dual purpose for this:
- Firstly, it will give you a feel for what it is like to program using a framework that employs JavaScript exclusively
- Secondly, we show that it is fairly easy to incorporate functionality that is offered by another framework or library, if for some reason you prefer that over what is offered by Backbase or if it offers something additional
To start, we are going to display a data grid with XML data. For clarity, we show the code for the dataGrid here:
<b:dataGrid
<b:dataGridCol
name</b:dataGridCol>
<b:dataGridCol
description</b:dataGridCol>
<b:dataGridCol
start date</b:dataGridCol>
<b:dataGridCol
end date</b:dataGridCol>
<b:dataSource e:
<b:dataContainer>
<xi:include
</b:dataContainer>
</b:dataSource>
</b:dataGrid>
Of course, we have to embed this file into an HTML page, which we assume that you know how to do.
So far, nothing new. But we know that Ext JS offers a very nice data grid and let's assume now that we would like to use the Ext JS grid in our application instead of the Backbase dataGrid.
Our first question is what the example would look like, without using the Backbase framework:
<html>
<head>
<title>XML Grid Example</title>
<link rel="stylesheet" type="text/css"
href="ext/ext-all.css" />
<script type="text/javascript" src="ext/ext-base.js">
</script>
<script type="text/javascript" src="ext/ext-all.js">
</script>
<link rel="stylesheet" type="text/css"
href="ext/grid-examples.css" />
<link rel="stylesheet" type="text/css"
href="ext/examples.css" />
<!-- The javascript for the example -->
<script type="text/javascript" src="tripdata-grid.js">
</script>
</head>
<body>
<h1>XML Grid Example</h1>
<p>
The data in the grid is loaded from tripdata.xml
</p>
<div id="tripdata-grid"></div>
</body>
</html>
We hear you say :"Huh! Where is my grid?" We just see a div that suggests holding the div because of the value of the id attribute.
In the previous sections, we have claimed a few times that declarative code using XML markup is preferable over a pure JavaScript approach, and here you see why.
Compare this with the grid we coded for the pure Backbase solution and then decide for yourself. We do not want to pick on Ext JS in particular because all pure JavaScript libraries and frameworks are like this.
Some call this unobtrusive JavaScript and will tell you it is a virtue!
To know what is going on, we need to look at the JavaScript file in tripdata-grid.js:
Ext.onReady(function(){
// create the Data Store
var store = new Ext.data.Store({
// load using HTTP
url: 'data/tripdata.xml',
// the return will be XML, so let's set up a reader
reader: new Ext.data.XmlReader({
// records will have an "Item" tag
record: 'record',
id: 'id',
totalRecords: '@totalRecords'
}, [
// set up the fields mapping into the xml doc
// The first needs mapping, the others are very basic
'name', 'description', 'startDate', 'endDate',
])
});
// create the grid
var grid = new Ext.grid.GridPanel({
store: store,
columns: [
{header: "Name", width: 200, dataIndex: 'name',
sortable: true},
{header: "Description", width: 400,
dataIndex: 'description', sortable: true},
{header: "Start Date", width: 80,
dataIndex: 'startDate', sortable: true},
{header: "End Date", width: 80, dataIndex: 'endDate',
sortable: true}
],
renderTo:'tripdata-grid',
width:780,
height:160
});
store.load();
});
If you study this piece of JavaScript, you will probably understand how the grid is coded. You can see that similar concepts are used as for a dataGrid in the Backbase framework. There is a data source called Ext.data.Store with fields, there is an Ext.data.XmlReader that reads and maps the data like a data container in the Backbase framework, and there is a grid with columns, here it's called Ext.grid.GridPanel, where the columns are embedded as anonymous objects.
Here is a picture of what the grid looks like when the example is executed:
Another problem with this kind of JavaScript coding is that everything, the name of the XML file, the names of the columns, and the div where the grid is rendered is hard coded. If we want to use the grid in a different situation, the best we can do is cut and paste this code and adapt it to the new situation. For our example, we have already done this, using the original example and changing it to suit our trip data.
What if you have five grids in your application? Do you still know from the id of the div which is which? And what particular mappings to XML fields you were using or column sorting, and so on? Or which JavaScript file contains the code to fill the grid? You would have to open up the JavaScript files to find out.
To improve on the situation, you could try to generalize the data grid functionality and encapsulate it into a parameterized function. You could embed the JavaScript code in script tags right where the div is that contains the grid. Within a short time, your HTML page will become cluttered with intangible JavaScript and your UI designers will probably not be very happy.
There is nothing technically wrong with putting any JavaScript in your Backbase application, although it is probably necessary to keep grid code like this outside the Backbase areas. But, there is an alternative: use the TDL markup language of the Backbase framework. We are going to encapsulate the Ext JS grid into a Backbase widget.
From the description above, you would've guessed that we need four elements for our grid example. We will call them grid, gridCol, dataStore, and field. Further more, we thought it was a good idea to place the widgets in their own namespace:.
The code that you need to put into a Backbase application for an Ext JS grid, after you have done the integration, looks like this:
<ext:grid xmlns:
<ext:dataStore
<ext:field
<ext:field
<ext:field
<ext:field
</ext:dataStore>
<ext:gridCol
<ext:gridCol
<ext:gridCol
<ext:gridCol
</ext:grid>
We hope you agree that this code is similar to the code we made for the pure Backbase example, except for the names of the widgets and the attributes used. We could have made them more similar to the Backbase equivalents, but we have chosen to define names closer to the names used in the pure Ext JS example.
Now that you have seen what the final result is, it will be easier to understand the definition in TDL for the grid itself:
- The grid needs to have two attributes to hold the size of the grid: width and height.
- The template of the grid element needs to be a div that can be used to attach the Ext JS grid to. Using this div to put the grid, we do not need the external div with a specific id
<d:element
<d:attribute
<d:attribute
<d:template
<div xmlns="">
<d:content />
</div>
</d:template>
<d:handler
// The rendering of the div takes place here.
</d:handler>
</d:element>
If you look at the JavaScript code for the example (tripdata-grid.js), you will see that the grid is rendered after the page is loaded, using Ext.onReady(function(){...}. We mimic this behavior by using the DOMNodeInsertedIntoDocument event. Here is the code for the event handler:
<d:handler
// get the store
var oStoreEl =
this.getElementsByTagNameNS('',
'dataStore')[0];
var store = oStoreEl.getStore();
// create the grid columns
var aColElements =
this.getElementsByTagNameNS ('',
'gridCol');
var aCols = new Array();
for (var i=0; i < aColElements.length ; i++) {
aCols[i] = {
header: aColElements[i].getAttribute('header'),
width: parseFloat(aColElements[i].getAttribute('width')),
dataIndex: aColElements[i].getAttribute('dataIndex'),
sortable: (aColElements[i].getAttribute('sortable') ==
'true')? true : false
};
}
// create the grid
var grid = new Ext.grid.GridPanel({
store: store,
columns: aCols,
renderTo: this.viewGate,
width: parseFloat(this.getAttribute('width')),
height: parseFloat(this.getAttribute('height'))
});
store.load();
</d:handler>
The code in the DOMNodeInsertedIntoDocument event handler is essentially a copy of the original example code. Look carefully at the following though:
- The dataStore widget is created by placing the widget as a nested element within the grid element. All we need to do is find it, using this.getElementsByTagNameNS('', 'dataStore')[0].
- The Ext JS dataStore object is created by calling the getStore() method on the dataStore element. Be careful to make the distinction between the Ext JS data.Store object that we get returned from the getStore() method and the Backbase dataStore that is returned by the getElementsByTagNameNS function.
- In a very similar way as finding the data store, we find a set of gridCol elements. The anonymous column elements in the array that we will need to create the grid are created using the attributes provided in the gridCol elements.
- Next, the grid itself, a new Ext.grid.GridPanel object is created, which has the store object and the column array we created before as arguments. The width and the height are taken from the width and height attributes, which have a default value, therefore, you will always see a grid, even if it does not have theproper size.
- Note in particular the renderTo attribute, which specifies this.viewGate, indicating that the grid will be rendered as child of the view node of the widget. This is exactly what we want because the grid will be shown where the grid widget is placed, and no extra div with a specific id is needed.
The gridCol widget is very simple: just a set of attributes. This is all we need to build the columns array.
<d:element
<d:attribute
<d:attribute
<d:attribute
<d:attribute
</d:element>
We know about the dataStore widget already. However, we would still like to point out a few things in the getStore() method:
- The field elements contained in the dataStore are found in a similar way as the gridCol elements in the grid.
- The data to be inserted in the grid is retrieved by an AJAX call from the server by the XML reader. The url used is an attribute for the dataStore widget.
- The reader needs to know a few things, like how many records there are in the file, what tag it should look for, and what is the ID in each record. This is very similar to what is needed in the Backbase case, and our XML file already contains the necessary information. We need to define attributes on the dataStore widget to provide these values. We gave them handy defaults because we know that our XML files always look the same, except for the record contents of course.
<d:element
<d:attribute
<d:attribute
<d:attribute
<d:attribute
<d:method
<d:body
var aFields =
this.getElementsByTagNameNS('',
'field');
var aStoreFields = new Array();
for (var i=0; i < aFields.length ; i++) {
aStoreFields[i] =
aFields[i].getAttribute('name');
}
var store = new Ext.data.Store({
// load using HTTP
url: this.getAttribute('url'),
// the return will be XML, so let's set up a reader
reader: new Ext.data.XmlReader({
// records will have a "record" tag
record: this.getAttribute('record'),
id: this.getAttribute('id'),
totalRecords: '@' + this.getAttribute('totalRecords')
}, aStoreFields )
});
return store;
</d:body>
</d:method>
</d:element>
The field element is very simple. It just has one attribute specifying its name. In fact, we could have made this element a bit more interesting by allowing mappings of the xml tags to grid fields to take place. We did not need it here; therefore, we decided to keep it simple.
<d:element
<d:attribute
</d:element>
You already saw what the code to place our example grid on the page looks like. The HTML page needs to contain a link to all the Ext JS scripts in its head part, except the tripdate-grid.js script because its logic is now captured in the set of widgets we just defined.
One more remark: we found it quite difficult to assemble the required CSS and images. We think the way Backbase handles this (keeping all CSS and images together with the widget definitions) is much more manageable, although it may have a small adverse effect on performance.
The picture shown earlier was actually a picture of running the Backbase version of the Ext JS grid example; the output is identical for both.
You saw that it is indeed not difficult to encapsulate Ext JS widgets into Backbase widgets. There is no general rule to how you can do this encapsulation. To start, you can take a look at the Ext.onReady(function(){...} or similar code that many framework plugins use to start rendering their widgets. Just fold this code into the DOMNodeInsertedIntoDocument event handler of your new widget, and you have a working start to continue with, in a refactoring process.
AJAX toolkit reference
Here is an alphabetical, short description of the libraries and frameworks mentioned in this article. Some of the descriptions are directly taken from the website where the library or framework is hosted and therefore, may sound a bit subjective. We provide a link to the website of each of the toolkits, to allow you to find out more.
ASP.NET AJAX
ASP.
Obviously, ASP.NET AJAX depends on a Microsoft server environment, but Microsoft makes it possible to use the AJAX Library on any site by offering a Content Delivery Network where an ASP.NET AJAX application can link to. Remarkable is also the standard inclusion of the jQuery library into ASP.NET AJAX.
Reference:.
Bindows
Bindows is an object-oriented platform for developing AJAX applications. With Bindows, you can generate web applications with the exact look and feel of Windows applications.
Bindows applications require no end-user downloads: it has a true zero-footprint (no Java, Flash, plug-ins, or ActiveX are used).
The Bindows framework is based on Dynamic HTML and the programming language used is Application Description Files (ADF), which is executed at the client's end as JavaScript.
The framework follows the Swing programming and DOM models. Class names start with "Bi", that is BiObject, BiRadioButton, and so on. The name Bindows comes from a combination of Business Intelligence (BI) and windows, BI being one of the interests of the company MB Technologies, responsible in creating the framework.
Reference:.
Cappuccino
Cappuccino is an open source framework that makes it easy to build desktop-caliber applications that run in a web browser..
Cappuccino was implemented using a new programming language called Objective-J, which is modeled after Objective-C and built entirely on top of JavaScript.
Reference:.
Ext JS
Like Backbase, Ext JS is developed commercially and has both open source (GNU GPL v3) and commercial licensing options. It is primarily a widget-based framework, although it seems to provide the essential cross-browser utilities, including a powerful element selection mechanism.
Ext JS is backed up by subscription-based support services, professional training, and consulting. One of the strengths of the framework is the cosmetic appeal of the widgets, which is complimented by extensive use of animation (that is, open/ close effects for windows and tree branches). Grid support is also impressive and includes XML and JSON data binding, editing, row-based grouping, enhancement (conversion of an HTML table to an interactive grid component), and filtering.
Compared with Backbase, the syntax can be more complex, as JavaScript is used exclusively.
Reference: Ext JS ().
The Dojo toolkit
Dojo is an open source framework that has been in development for approximately four years. The latest release (1.3.2) consists of three distinct components: Dojo core, Dijit, and DojoX. The core file is relatively lightweight (less than 30k gzipped) and provides a comprehensive set of cross-browser utilities including DOM manipulation, normalized event handling, and basic animation. The second component (Dijit) is a widget library consisting of relatively common widgets including button, menu, panel layouts, progress bar, rich text editor, slider, and tree. The final component (DojoX) consists of a wide range of extensions at varying levels of readiness. For example, charting support is available as an extension, but the online demos do not work in IE7. The intention is that widgets will be moved from DojoX to Dijit as and when they reach the appropriate level of quality.
Widgets can be added to a document either using a declarative model or JavaScript. The declarative model makes use of HTML with the class or custom dojoType attributes used to identify widgets. When the document is parsed, elements having a class or dojoType attribute referencing a known widget will be replaced with the relevant HTML. When creating a widget programmatically using JavaScript, a constructor for the desired widget must be used. For example, calling new dijit.ProgressBar() with appropriate parameters will create a progress bar widget.
In Dojo, widgets consist of three files: an HTML file that defines the component structure, a CSS file for styling, and a JavaScript file for implementing control logic. However, the general architecture seems significantly less powerful and harder to use than the Backbase approach.
Reference:.
Google Web Toolkit
With Google Web Toolkit (GWT), you write your AJAX frontend in the Java programming language, which GWT then cross-compiles into optimized JavaScript that automatically works across all major browsers. During development, you can iterate quickly in the same "edit-refresh-view" cycle you're accustomed to with JavaScript.
Reference: Google Web Toolkit ().
Javeline
Javeline Platform is an application development framework (also called a library, or toolkit) aimed at developers for building applications that run via web browsers, but look and feel like conventional desktop applications.
Javeline seems to have a very similar philosophy of development as Backbase. It uses JML (Javeline Markup Language) with a j: prefix, to code web applications. There are extensive MVC facilities built in, but there does not seem to be a custom component building facility.
Reference:.
jQuery
jQuery is a concise but complete AJAX library. Although the core is small, the plugins contain all of the necessary parts. The relationship between jQuery and jQuery UI is similar to the one between Prototype and Script.aculo.us, where jQuery contains the basic AJAX functions and jQuery UI contains behaviors like drag-and-drop and widgets like an accordion and slider.
One advantage of jQuery is its powerful multi-selector, which makes finding an element easy. The syntax looks similar to CSS selector and it adds many more filters, such as content, attribute, and forms. Another advantage is its big plugin community. It has over 300 different plugins to choose from. You can find cutting edge UI-like fisheye or carousel view, as well as functional plugins for event propagation. These plugins are specific to certain purposes and are maintained by the community.
On the down side, the plugin community requires a lot of time to maintain and update these plugins.Reference: jQuery ().
MooTools
MooTools is a compact, modular, object-oriented JavaScript framework designed for the intermediate to advanced JavaScript developer.
Mootools seems to be rather limited in scope; it has animation and event handling, but just a limited set of available plugins: Accordion, slider, and sortables.
Reference:.
Prototype and Script.aculo.us
These two libraries are most often mentioned in one sentence. There are other libraries that are based on the Prototype library, but Script.aculo.us is certainly the best known.
Prototype
Prototype is more like a basic AJAX tool that allows you to extend from it and make your own AJAX library (like Script.aculo.us).
One advantage of Prototype is that it is very generic and focuses on JavaScript and DOM data manipulation. Because it is one of the first AJAX frameworks, Prototype has many JavaScript add-on functions that allow you to take advantage of other language features, such as inheritance, complicated data structure (hash table), and array manipulation.
On the other hand, Prototype delegates fancy layout functions, such as animation, charting, drag-and-drop, or resize, to Script.aculo.us. Also, it does not have its own widgets library.
Reference: Prototype ().
Script.aculo.us
Script.aculo.us is based on Prototype, so it inherits all Prototype functions.
Script.aculo.us has over 20 types of high quality animation effects. Another advantage is that the cores are modulated, so that you can easily pick the core that you need. For example, if you do not need drag-and-drop functionality in the project, you can simply exclude the dragdrop.js file.
A drawback of Script.aculo.us is that it focuses too much on animation rather than creating more useful widgets and demos. For example, it does not have form validation and data binding services.
Reference: Script.aculo.us (). been ported to many development platforms among which is JavaScript.
Reference:.
qooxdoo
qooxdoo is a comprehensive and innovative framework for creating RIAs. Leveraging object-oriented JavaScript allows developers to build impressive cross-browser applications. No HTML, CSS, or DOM knowledge is needed.
qooxdoo has a comprehensive set of widgets. Using JavaScript and no HTML makes it orthogonal in development philosophy to Backbase. This seems to be squares circled instead of circles squared.
Reference:.
SproutCore
This is an HTML5 Application Framework for building rich cloud applications running in any modern web browser without plugins.
Reference:.
The Yahoo User Interface (YUI) library
The Yahoo User Interface (YUI) library consists of five distinct elements: a set of CSS files designed to ensure that interfaces look the same in different browsers, the core engine, which includes normalized DOM and Event utilities, and the global YAHOO object, a utility module that provides support for features like animation and drag-and-drop, widgets, and developer tools.
Reference: YUI ().
ZK
ZK is an open source AJAX web application framework, written in Java that enables creation of rich graphical user interfaces for web applications with no JavaScript and little programming knowledge.
The core of ZK consists of an AJAX-based event-driven mechanism, over 123 XUL and 83 XHTML-based components, and a markup language for designing user interfaces. Programmers design their application pages in feature-rich XUL/XHTML components, and manipulate them upon events triggered by end user's activity. It is similar to the programming model found in desktop GUI-based applications.
ZK takes the so-called server-centric approach that the content synchronization of components and the event pipelining between clients and servers are automatically done by the engine and AJAX plumbing codes are completely transparent to web application developers. Therefore, the end users get the similar engaged interactivity and responsiveness as a desktop application, while programmers' development retains a similar simplicity to that of desktop applications.
In addition to component-based programming in a manner similar to Swing, ZK supports a markup language for rich user interface defi nition called ZUML.
Reference:.
Summary
In this article, we illustrated the difference in coding style for a pure JavaScript framework as opposed to the Backbase framework using XML for UI layout. We also illustrated how easy it is to integrate other frameworks into the Backbase framework.
In order to enable you to explore all the frameworks mentioned, we included references and a short description.