Differences between revisions 1 and 2
Revision 1 as of 2007-03-01 05:33:42
Size: 991
Editor: dhcp64-134-214-164
Comment:
Revision 2 as of 2007-03-01 05:39:20
Size: 1655
Editor: dhcp64-134-214-164
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

I have uploaded a zip file of the converted Person Manager application to my people directory. [
Line 5: Line 7:
*You either are responsible for moving data from the server to the client using XHR and updating the UI with JavaScript code or
*The markup is down convert into HTML and JavaScript on the server as in some JSF implementation
*You either are responsible for moving data from the server to the client using XHR and updating the UI with JavaScript code

*The markup is down convert into HTML and JavaScript on the server as in some JSF implementation.

By rendering the markup on the client the developer can reuse alot of existing code they already have in there application. Most of the time the Model and the controller code is reused. This leave developers to only change the view layer of their application. This is exactly what I did in the conversion of the Person Manager Sample.

Another reason that integration is fairly seamless with web frameworks is that XAP communicates with the server in the same manner that a HTML application does through the use of HTTP get and posts.

In the example

This page describes how to integrate [http://incubator.apache.org/xap Apache XAP] with [http://struts.apache.org Struts2]. I use the Person Manager struts sample to illustrate how to upgrade an html application to use XAP. Overall the integration is quite simple. I was able to repurpose all of the Java code (Data Model, ActionHandlers) from the sample. All that needed to be done was to re-write the *.ftl files to output a combination of <strong>xModify</strong> and <strong>XAL</strong> instead of html.

I have uploaded a zip file of the converted Person Manager application to my people directory. [

The reason why integration with web frameworks is so easy, is that the XAP client retrieves the markup used to describe the application from the server and then renders it entirely on the client. This is the opposite of other Ajax toolkits where:

*You either are responsible for moving data from the server to the client using XHR and updating the UI with JavaScript code

*The markup is down convert into HTML and JavaScript on the server as in some JSF implementation.

By rendering the markup on the client the developer can reuse alot of existing code they already have in there application. Most of the time the Model and the controller code is reused. This leave developers to only change the view layer of their application. This is exactly what I did in the conversion of the Person Manager Sample.

Another reason that integration is fairly seamless with web frameworks is that XAP communicates with the server in the same manner that a HTML application does through the use of HTTP get and posts.

In the example

xap/XAPStruts (last edited 2009-09-20 23:07:09 by localhost)