Benefits of using a good RIA Framework and IDE

While doing demos of Swan, people quickly ask - what are the benefits and savings of using a Framework and IDE for building Ajax based RIAs in Java?
To be able to answer that question with confidence, I decided to work on some examples to somehow measure the benefits with regards to development productivity. In my examples I used different metrics such as Number of Steps required to implement, Lines of Code, Cyclomatic Complexity, etc. In this article I present one of the examples I worked on including number of steps required as metrics. Note that this is not a very scientific approach for measuring the benefits, but is a good start and is simple enough to describe in this blog.

The example consists on implementing a common Ajax scenerio for processng input validation. The scenario is implemented using two solutions or approaches: plain JavaScript and the Swan Application Framework. I then compare the amount of steps required to implement each and get the metrics to compare each approach.

Processing Input Validation Scenario

Validate the data entered by the user and provide feedback as soon as possible without waiting for a full page submit. The validation should be executed on the server side.


Solution 1: Plain JavaScript

This solution uses plain JavaScript and pretty much shows what a developer would have to do in order to implement this scenario without the aid of any framework or RIA Generation Tool such as Swan. Figure 1, illustrates the steps required by a developer to implement this scenario.

Figure 1 - Input Validation Process

This implementation requires at least 8 steps, besides designing the page, to handle the input validation:

1. Create function to be called when onkeyup event is triggered
2. Create XMLHttpRequest
3. Make Server side request to process event
4. Process validation on the server
5. Create XML data to send back as response
6. Create callback function
7. Parse response XML
8. Update DOM
   

Solution 2: Using Swan's IDE and Framework

This solution uses Swan Framework and I used the IDE tools to implement it. Figure 2, illustrates the steps required for implementing the same functionality but now using Swan.

Figure 2 - Input Validation With Swan

This implementation requires at least 3 steps, besides designing the page, to handle the input validation:

1. Bind onkeyup event to call server side method
2. Process input validation
3. Update validation message

Note, that while using Swan's tools after creating the HTML page I just had to configure the event to call the required method on the server, then just implement the method on the server to handle the required business logic and update the validation message. All this within the server side context.

Metrics

As mentioned at the begining, I'm using the number of steps required to implement the Ajax Scenario as metrics. So here are the results:

• Plain JavaScript Approach: 8 Steps
• Using Swan Tools and Framework: 3 Steps
• Savings: 62%
  

Summary

Using a good RIA Framework and application builder like Swan speeds up the development process by reducing the amount of work required to build an Ajax based RIA, saving IT time and money which is very important specially with the Financial times we are leaving today.

Portable UI and re-usable controller in Java

I'm a lead developer of Swan, an end-to-end application framework for building RIA using Ajax. The current implementation supports the Java platform and has plugins for Eclipse.


One of the goals for building Swan has been the ability to build portable UIs that can be re-used in different presentation platforms. This will enable developers , responsible for supporting tools on different presentation platforms, to easily port a UI without having to re-do much of the work. Instead of maintaining a different version of the tool/product for each presentation platform we thought there should be an easier way to do this, so we created the core framework behind Swan to enable the truly separation of the View from the Model and the Controller. This was nothing new for us, the work we did was initially based on the work we had done many years back in the Smalltalk platform. Swan's framework allows us to define view builders/engines for each platform reusing the controller and the UI specs defined in XML.
The controller can then remain separate from the actual UI composition, and developers do not have to worry about creating the platform specific components. In essence we created our own UI abstraction that enables the developers to compose a UI using our widget hierarchy instead of the host widgets, hence enabling portability.
At runtime, the selected UI engine is responsible for building the actual host components and delegates the handling of events to the re-usable controller. The image below shows the same UI rendered as a SWIN based application and as a Web based app.

In the image above you can see how the controller is reused for both presentations. Notice the highlighted code, which is called on the list click event, uses an abstracted API that is independent of the target platform: web vs. swing.
We still have work to do but we are confident that we'll be able to provide the framework capable of supporting portable UIs.

To learn more about Swan visit Swan Home Site