Cosua

Why is the use of JSTL a good practice?

2010-07-17T09:08:00.000-07:00

I've been doing software development for a long time. I've worked with new technologies, new practices and approaches at solving problems using the technologies at hand. One of the things I've learned is to follow good practices and work towards simplicity. And simplicity is what I don't see when using things like JSTL or other custom tag libraries from various product vendors.

I've been working with Java for a long time now, and when JSP's first came into picture it was a nice thing to be able to include Java code to control the rendering of the HTML output. It was a simple template mechanism without much complexity other than mix HTML and Java. Later some people thought adding tag libraries was a better approach, the reasoning behind it, I believe, was mainly that embedding Java into HTML pages is not elegant and makes the source of HTML pages hard to read by the HTML designers and the programs used to design them. This, to me, is not a good reason to make custom tag libraries or JSTL needed. In most cases, once the HTML page is designed is then given to a Java developer to convert it into a JSP. The converted source will never go to the original HTML designer. The JSP version of the original HTML page is no longer useful to the designer, unless He is viewing it from the actual application server. So let's face it , the JSP will almost never go to the hands of the HTML designer for changes, it will always be the Java developer the one making the changes.
Another reason, for not needing to add to the confusion and complexity of the JSPs by using JSTL, is that you can not do everything using just tag libraries. You will most likely need to embed some Java scriptlets, making the source more complex to understand (HTML + JSTL + Custom Tags + Java scriptlets), so why not just use Java scriptlets as the way to control the output generation. This way we do not have to be learning new tag libraries, we do not need to figure out what we can and can not do with these libraries. Combining HTML and Java scriptlets only makes our job much easier.

Benefits of using a good RIA Framework and IDE

2009-02-13T10:52:00.000-08:00

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:

Create function to be called when onkeyup event is triggered
Create XMLHttpRequest
Make Server side request to process event
Process validation on the server
Create XML data to send back as response
Create callback function
Parse response XML
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:

Bind onkeyup event to call server side method
Process input validation
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

2009-02-13T09:01:00.000-08:00

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

I had forgotten how much I like Smalltalk

2008-12-10T23:25:00.000-08:00

I've been working in Java for many year now and had not done any real work with Smalltalk until recently. We have a tool that we are now porting to Smalltalk and I just remembered why I did not like Java initially, everything seems much simpler in Smalltalk. Processing collections is much simpler in Smalltalk :

To iterate through a collection of Employee objects to collect the name from each employee only requires the following code: aCollection collect: [:eachEmployee | each name ]
To iterate through a collection of Employee objects and select all employees where last name is "Smith": aCollection select: [:eachEmployee | eachEmployee lastName = 'Smith']

There have been many new features added to Java that make it a little more like Smalltalk but it will never be the same.