Swingweb in a nutshell

Before we get into the details of swingweb application development, it is better for the developer to have a basic understanding of how swingweb framework works.





From the picture above, we can see that the goal of Swingweb is to enable AWT/Swing application to run under web environment. For example, given a running AWT/Swing application, what we want to achieve are simply two simple things:

  • render the corresponding html representation of the swing application and html form information that is required for event input
  • accept event input (e.g. button click, text changes etc) through http servlet request
To achieve this, the event input and presentation operation in Swingweb is grouped as a unit of operation that can be completed within a single request/response cycle. The rendering/event-input are performed by traversing through the application component tree and calling the corresponding RenderDelegate/InputDelete of each component to render/fire event on the behalf of the component.



For rendering, the RenderDelegates will render the component using jxp templates. A jxp template is essentially a template file that contains some html text and some java code similar to jsp. For example, the jxp template of a button looks like this:







Nothing fancy here. It's just a html presentation of the java.awt.Button component. If you look close enough, you will notice that the name of the button is the expression "_com.getId()" will would be the id of the ButtonPeer. That way when the form is clicked, the corresponding ButtonInputDelegate that handles event input of the component could detect that the specific button has been clicked.



As for the input, the InputDelegate of the components looks for the information inside a map object (created from servlet request) to change the state of the components (e.g. set the text of a TextComponent to changed text) and/or fire events (e.g. button click event). For example, the ButtonInputDelegate that handles the awt button input has the following implementation:







The ButtonInputDelegate uses the id from the component peer to check whether the button is clicked, and posts an event to the AWT event queue. The AWT EventQueue will then handle the rest of the processing including firing the events to all the listeners of the button.



This is a simplistic overview of what Swingweb does without going into much detail of what's underneath the framework. Swingweb provides the RenderDelegate/InputDelegate implementation for most of the major components so if an application only uses these components, the application should work inside Swingweb. Otherwise, you need to implement your own RenderDelegate/InputDelegate, which is not hard to do and it only need to be done once for each type of component. This will be discussed in greater detail in section 2.2.