Traditionally, to provide richer client features to Web-based clients, you had to create Web-based applications that are comprised of a homogeneous system from various technologies, which may include:
- Server-side Web or application server, such as Apache HTTP Server, Microsoft® Internet Information Services (IIS), Sun Java™ Web Server, IBM® WebSphere®, or BEA WebLogic
- Server-side scripting or processing language, such as Java, PHP, JavaServer Pages™ (JSP), or Active Server Pages (ASP)
Before you can develop any Web-based applications that use Jaxer, you must first install it on your machine or in your development environment. There are three choices. Jaxer is available for Microsoft Windows®, Mac OS X, or Linux®. The Jaxer installation is a self-contained, stand-alone Apache/Jaxer server. However, you can also install it as a module in an existing Apache or Jetty environment. Aptana reports plans to support IIS in the near future.
For the purpose of this article, and because most developers write code on Windows and then deploy to a Windows or *NIX environment (such as UNIX® or Linux), I've chosen to install the stand-alone Windows version. Installing on Windows is very easy. You simply go to the Aptana Jaxer download page (see Resources for a link to this page) and download the compressed (.zip) file for the Windows stand-alone version. At the time of this article, the latest version was build 0.9.7.2472.
After you download and open the compressed file, copy the Aptana Jaxer folder to your hard drive. I copied mine directly to my C: drive. Thus, I can access my root folder for Jaxer by going to C:\Aptana Jaxer.
There are a number of files and folders inside the Aptana Jaxer folder. The root folder contains the following files:
It also contains the following folders:
Starting and testing your Jaxer server
Starting the server is even easier than the original installation. Simply run the StartServers.bat file, and the startup window shown in Figure 1 is displayed.
Figure 1. Jaxer startup window
You must keep this window open as long as you intend to use and test applications in the Jaxer environment. You can test that your Jaxer server is running correctly by opening a browser window and navigating to http://localhost:8081/aptana. The About Jaxer page shown in Figure 2 should display in your browser.
Figure 2. About Jaxer page
There are other Jaxer-based Web applications available in the Samples folder, which is located in <jaxer_install_dir>\jaxer\aptana\samples. You'll find several applications, including those described in Table 1.
Table 1. Applications included in the Jaxer Samples folder
|chat||Demonstrates the sending and receiving of chat messages without having to refresh the entire page.|
|rss-sample||Demonstrates how the page can be divided to show a list of news stories in one portion of the page while showing a selected story in another portion of the page. The story is shown within its section, without refreshing the entire page; all done using Ajax and Jaxer.|
|smtp-email||Allows you to use the Jaxer Simple Mail Transfer Protocol (SMTP) object for sending e-mail asynchronously.|
|tasks||Allows you to add, modify, or delete items in a simple to-do or task list using asynchronous communication.|
|wikilite||Allows the user to provide text for a simple wiki in edit mode, save the text, and then view it later.|
You can access these samples by clicking the Samples and Tools link shown in Figure 2. The resulting Samples and Tools page is shown in Figure 3.
Figure 3. Samples and Tools page
You'll be using the tasks sample application to learn more about Aptana Jaxer later in this article.
As you might have noticed, there are also several Web and diagnostic tools you can use to interact with Jaxer and diagnose issues when they occur. For example, clicking the Server Diagnostics link returns the Jaxer Diagnostics page shown in Figure 4.
Figure 4. Jaxer Diagnostics page
When I described the Jaxer root folder, I mentioned that there are several subfolders within it. One of these folders is named public. You can use this folder to provide your own content. If you do so, it will be called from the browser if you simply specify the host:port address in the browser's address line. For example, http://localhost:8081/ returns whatever index file you provide there.
Even better, you can create several projects within the public folder and load the project by name. For example, create a project named my_project. The complete path to this folder should be C:\<jaxer_root>\public\my_project.
Now create an index file named index.html and place it in the my_project
folder. You can load the file using the Jaxer server by entering its path in the
browser. In this case, you enter
http://localhost:8081/my_project. You can place any HTML, images,
Listing 1. Sample code to test Jaxer
When executed, the code produces the page shown in Figure 5.
Figure 5. Quick start code used in my_project
If you view the actual HTML source code sent to the browser, you find that it is quite different from the original code. Take a look at Listing 2.
Listing 2. Jaxer-generated HTML code returned to the browser
you normally write for a browser and this is that the code uses the
runat attribute to specify that the code should be executed
Jaxer high-level view
Before looking at the Jaxer architecture, first take a look at the architecture of a traditional application, as shown in Figure 6.
Figure 6. Traditional application stack
All stacks begin life with a request from the client to the server. In the traditional case, the server side responds by processing the request using one or more technologies, which might include PHP, Java code, C#, Ruby On Rails, or any number of other scripting/object technologies. The server side can perform database or file access, process the data, then format the data and return it back to the browser. These technologies are separate components that must be brought together by connecting code.
If the Web-based application is to use Ajax, it must take steps to process the client requests, wrap the call/parameters, and send the requests. On the server side, code must unwrap the request to determine the call/parameters, then execute the call, receive the response, rewrap the response, and return it to the client. The client then must unwrap the response and finally process it. The wrapping/unwrapping can be done using JSON, and the actual request/response/callback can be done using XMLHttpRequest. In contrast, take a look at what a Jaxer stack looks like, as shown in Figure 7.
Figure 7. Jaxer application stack
Notice the stack is much simpler. Also notice that there is no need for external
targets where it should run by specifying the location using the
Jaxer provides services to support the development of applications that require the following technologies:
- Database communication from the client or server
- Client- or server-side logging
- Session manipulation
- Client- or server-side network API connectivity
- File objects
- the list goes on...
Additionally, you can integrate Jaxer with traditional technologies such as Java code to help solve cross-platform issues.
To better understand how a Jaxer application is built, I'd like to walk you through one of the sample sites shipped with Jaxer. You'll be looking at the tasks application, which you can access by going to http://localhost:8081/aptana/samples/tasks. The page shown in Figure 8 is displayed. I've already added a few tasks.
Figure 8. Tasks sample main page
The tasks application is simple from a user's point of view. You simply type new tasks in the New box and click add. To remove items, simply click the checkboxes next to the items you want to delete.
runat attribute set to both, which means that the code
within will be made available to both the client and server side. The functions in
Listing 3 provide general functions accessible by
other functions executed on both the client and server side. The
$ function simply returns an element based on the provided ID. The
addTaskToUI provides the task on the client side using the
insertBefore methods to create the user interface.
There aren't too
many calls to any Jaxer-specific APIs here, only the definition of the events
attached to the input and checkboxes, and the logical comparison against the
Jaxer.isOnServer property, which is set to true if the
Jaxer.setEvent is used to establish the communication
proxies used to make calls from the client to the server. Stay with me, this will
become clear in a few paragraphs.
slated to run on the server, based on the value passed to the
runat attribute, as you can see in Listing
When you run this sample, take a look at the source code produced by Jaxer in your browser. Notice that the code from Listing 4 is missing. Conveniently, the defined functions have been converted to simple shells of the real functions. In their place, simple Jaxer remoting has been created.
Listing 4 provides some
side. In the first portion of this segment, note that a Structured Query Language
(SQL) table is created (if it doesn't exist). Next, an event similar to
onload on the browser side is established, except this one
is on the server side. The function defined and assigned to the
onserverload is called after Jaxer loads the entire file and makes note
of the all of the global server functions and variables.
In this case, the
methods defined include
deleteSavedTask. To have the functions callable from the
client side, a proxy must be defined. This is done by setting the functions'
proxy property to true.
After Jaxer loads the file,
the functionality assigned to
onserverload is executed.
In this case, the function executes a SQL call to retrieve the present tasks from
the database. Next, it proceeds to iterate over all of the tasks and calls the
addTaskToUI method. If you remember correctly, the method
inserts checkboxes and input boxes into the HTML document. But wait! That would mean
that the server is actually pushing those checkboxes and input boxes into the
document in this case. When this code is executed on the server side, the only thing
that doesn't execute within the
addTaskToUI is the code
wrapped within the logical check to see if
true or false. That piece of code is only needed for the client side to perform a
remote call to the server for adding the tasks to the database.
- Learn more about cross-site scripting on Wikipedia.
- Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
- Stay current with developerWorks' Technical events and webcasts.
- Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
- Go to the Aptana Jaxer download page to download the correct version of Jaxer for your operating system.
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.