Atif Khan’s Blog

I have been spending time on and off looking at various web frameworks available for a little more than a year. A lot of this has to do with keeping track of what’s going on in the web framework arena and keep in sync with the technologies. Another focus of mine is to see how the new (at least for me) frameworks affect the productivity of a developer.

I first looked at RIFE last year and I have been very impressed by the concepts.The developers of RIFE, Geert Bevin and others have been very helpful when I had some questions. I was even able to get answers on the IRC channel for RIFE. It was not until recently that I tried to write an application using RIFE that I really got a feel of it.

Pros

• A complete framework. It includes basic web framework, ORM, Content Management, Validations, Templates etc.
• Good support from developers
• A nice quick start application to get you running quickly
• Good support for constraints for adding validations
• Continuations - ability to pause, rewind, jump through transaction steps

Cons

• Templates are really weird to work with. The syntax for the templates really did me. It is not really designer friendly like Tapestry or Wicket
• The concept of flowlink and datalink is just too verbose and not clear
• Using annotation didn’t do me any good as well for defining the flow and data links. There isn’t enough documentation for annotations
• The only way for form validations I could find was to define the a MetaData class equivalent to the domain object representing the form and define the validations in there. This just seems like way too much of work for simple validations.
• I could not figure out how to customize the error messages for form validations

In the end, I feel that it’s the lack of documentation that prevented me from really exploring it. I know Geert is a very sharp guy and if he ever gets to read my blog, I welcome his comments. I think the learning curve is too much for RIFE and lack of documentation adds to it and I am not sure if the return is proportional to the effort compared to other frameworks.

Have you ever been in a situation where you wanted to write a simple application for internal use that should be portable and completely self contained (including the database)? I am pretty sure you have. I had to do this recently for one of the simple reporting applications and I didn’t really want to create a dependency on external database like MySQL or PostgreSQL. This application needed only 4 tables and the data in these table is never going to be large enough to warrant an extensive database system. I thought about putting the data in flat files and write the code to access it. But, then I found this really neat gem called KirbyBase that does exactly the same and little more.

• Pure Ruby code
• Data is kept in simple delimited files, allowing the modification in any text editor
• It’s not an in-memory DB. The data is actually stored on the disk
• Allows various data types like String, Integer, Float, Boolean, Time, Date, DateTime, Memo, Blob, and YAML
• Allows creating indexes on fields
• Query results can be sorted
• Allows to define one-many links between tables similar to joins in RDBMS
• The columns can be defined with a formula, so the value will be calculated during insertion
• Automatic lookup fields can be defined to lookup the related values from another table

To give a simple example on how all this works, let’s consider a scenario of Department and Employees. The simple requirements can be laid out as each employee has personal information and belongs to a department. Also, each department has a name and identifier and can contain multiple employees. Following is how the code going to look using KirbyBase. Please keep in mind that I have tried to write a reusable DAO, hence the code may look a little verbose. You can very well short circuit the whole thing and write very concise code.

The output after execution will look like this:

Employee in IT department
Doe
John

Employee in IT department
John
Doe

This should also generate 2 files in your current directory, department.tbl and employee.tbl. Let’s look at content of these files now.

department.tbl

000001|000000|Department|recno:Integer|dept_name:String:Key->true:Index->1|employee:ResultSet:Link_many->recno=employee.dept_id
1|IT|kb_nil

employee.tbl

000002|000000|Employee|recno:Integer|dept_id:Integer:Key->true:Index->1|name:String:Key->true:Index->1
1|1|John
2|1|Doe

That’s all there to it. It is very powerful and easy to work with library.

As the Web 2.0 grows in popularity, so does the urge for a lot of organizations to revamp their legacy applications and make them web based. Their are obvious benefits to this as the application becomes more accessible and requires less effort to deploy and maintain as there is single point of deployment and maintenance, the application server. What gets lost in all this excitement is the functionality that may have been available in the existing applications with rich user interfaces can not be easily replicated in the web application replicating it. By using the readily available javascript libraries and AJAX techniques some of this pain can be alleviated. It’s not necessary that web applications may always lose the usability of functionality of the original application. In fact they can actually simplify some of the transactions if the user experience is considered from beginning during the rewrite process.

It has a rich set of components and event model that can all be used and programmed to using the LZX language. You can also write your own components using the LZX markup. The important thing to keep in mind is that OpenLaszlo is strictly a UI technology. You still need to get your data to display from the backend whether it being database of another middleware. This is where OpenLaszo excels. At the core it can interact with a back end system using the RPC. Various RPC options include:

• Java RPC
• SOAP
• XML RPC
• XMLHttpRequest for Ajax

So, you can pretty much have you back end written in Java, PHP, Ruby or whatever you like as long as it supports either RPC, SOAP or XMLHttpRequest. If you are wondering about what do you need on your server to run OpenLaszlo, it is basically a Java Servlet based web application. So, you do need the Java servlet container on your server to run OpenLaszlo. That shouldn’t be an issue at all if you already use Java.

If you do use Java on the server side and you have been trying to decide between various web application frameworks available and there are a ton of them :), OpenLaszlo can make your life a little simpler as you don’t have to worry about the components or the component state management (JSF, Wicket, Tapestry etc). All you need is a solid framework that can preferably produce XML output and serve some data (Struts, WebWork, Spring MVC, RIFE) or any other similar framework and leave the UI aspect to OpenLaszlo. OpenLaszlo may not be suitable in all the cases, but it is worth a look if you want a web application with the look and feel and usability of a desktop application.

A lot of Java applications run on Sun’s JDK due to various reasons. In fact till recently Sun had a very restrictive license policy for Java. So, effectively Sun’s JDK has been a de facto standard. That’s the reason Sun’s JDK code is supposed and expected to be of high quality and following at least the coding conventions recommended by Sun in a 1999 article that is widely used.

If you look under the hood of JDK, you will find a completely different picture. Here is an example from the Java 6 source code of StringBuilder class. (I have noticed similar stuff in 1.4 and 1.5 releases.)

• Indentation - not sure if it was edited in notepad (even vi does indentation) or a result of source control merge?.
• If clause doesn’t use brackets- Here is an excerpt from Sun’s Java coding conventions. The if-else class of statements should have the following form: if (condition) { statements; } if (condition) { statements; } else { statements; } if (condition) { statements; } else if (condition) { statements; } else { statements; } Note: if statements always use braces {}. Avoid the following error-prone form: if (condition) //AVOID! THIS OMITS THE BRACES {}! statement;

  Need I say more?

• Creating “null” string instance- Why can’t it be represented by a static final constant and reused? All the string literals are stored in JVM in a String pool, even the ones defined as constants. Isn’t it more optimized if you have a direct reference to it rather than JVM doing a lookup in the pool every time you call the method?
  Note: After looking at the bytecode generated by the compiler, it looks like a direct reference is pushed on the stack for the string literal. So, it effectively doesn’t matter if you use a literal or a constant. Still, if you are using a string literal over and over again, it may be a better idea to create a constant. This way if you need to change the string literal, there is only one place where you need to make change. So, you protect yourself against future changes. Thanks to Messi for pointing this out in the comments :).
• Variables can be made final-The method parameter sb and local variables len and newcount can all be declared final for optimization. This article has good explanation for it.
  Note: Again after analyzing the bytecode it seems like compiler really doesn’t care about the final declaration for the local variables. The method parameter are a different case as by declaring them final you make sure that they are not modified by mistake. Also, the local variables can be declared as final as a coding practice to mark them as immutable even though it doesn’t affect the byte code. But it makes it clear for a person looking at your code that the variable can not be modified. Thanks to Messi and Kevin Riff for pointing this out in the comments

This is just an example. There are instances like this all over the JDK code base. I want to make it clear that I am not commenting on the performance aspect of JDK, just the code conventions and formatting (for the obvious reasons that the code should be properly formatted). Now, since Sun has released the JDK source code under GPL license, do we expect to see things like this continue? Do you think people will take more responsibility and clean up the JDK code? I hope so. I also hope that Sun does not blacklist me after this post

One of the biggest feature added with JDK 1.5 is enum support. At last you can use a language construct to define constants in the system rather than using the static final to define the constants. The obvious benefits of enums are type safety and type checking.

Also enums let you define meaningful values for the constants. e.g.

As you can see in the above example, you can use the enum constant PI across your code, but if you wanted to get the value of PI, you can do that by using PI.getValue().

This is where things get a little fuzzy. What if you have a double value representing either PI or LOG_E and you want to find out which constant in MathEnum represents that value? This is the reverse lookup of enum. The Java implementation of enum does not allow reverse lookup by value. It is a very useful feature if you are working with an existing code base and an external system returns values for the constants that need to be translated into Java Enums.

Here is how this problem can be solved by using the Reversible Enum Pattern. First we need to create a ReversibleEnum interface that will mark the Enums as reversible and define the required method.

Next, we need to define a Map that will be used to store the enum constant values and for reverse lookup.

You will notice that in both the ReversibleEnum interface and the ReverseEnumMap class the Generics template is used. This is done to customize these based on the type of the enum that will use them and the type of the value of enum constants. If this sounds confusing, it will become more clear after we see the modified version of the MathEnum class from earlier.

The changes you will notice here are:

• MathEnum implements the ReversibleEnum interface.
• New variable for ReversibleEnumMap
• New method reverse(final Double value) to do the reverse lookup. This is from the ReversibleEnum interface.
• New static method getInstance() that just returns the first constant of the enum. This is kind of a hack to get a reference to an instant of the enum, so that the reverse(..) method could be called on it.

Now to do a reverse lookup on the MathEnum, all you need to do is:

Lets recap all the steps needed to be done to create a reversible enum:

1. Define an interface ReversibleEnum. — One time job.
2. Define a new class ReverseEnumMap. — One time job.
3. Implement the ReversibleEnum interface and define a member variable of type ReverseEnumMap in the enum that you want to be reversible. If you do not need the reverse functionality, you don’t need to do any of this.

So, effectively once you have the interface and map class created, it’s minimal effort to create a reversible enum. I wish this was a built-in functionality in the JDK enum implementation.