Liferay Portlet Backend: Service Builder Discussion

Is service builder good enough? Are Spring and Hibernate the best option?

When I first started Liferay Portlet development, the first thing I came across with was "Service Builder", my first thought was "this is awful", with the following reasons:

• It didn't allow me to do TDD but to directly write business code and then generate the interface out of it.
• It generates a lot of classes, and I'm only allowed to modify a few (just one I think).
• The resulting code throws a lot of exceptions (the same as the Liferay API) and I'm really not into throwing lots of exceptions.

But as every first step I was able to look at the configuration files it generates and then learn how I could create my own Spring framework context using the same data source as liferay and having a great coding experience with Hibernate and Spring.

Everything seemed fine until I realized that it wasn't the best option, three reasons I can think of right now are:

• No support for global transactions, this means the transaction my code manages is different than the transaction of the Liferay API calls so no global rollback for me.
• No support for database sharding, well not precisely but If I wanted it to work transparently, I would have to make my own way through it.
• No direct relationships of my data model with the Liferay entities, this means no automatic foreign keys for example.

So then I realized that I was trying to kill a fly with a nuclear bomb, this is the fact: You COULD create huge applications with portlets in Liferay but portlets (as any other liferay plugin) are for customizing the web portal and not to build huge applications. 

If we lower down the scale and say a portlet is just a customization:

• It's so simple we don't need to write many test classes.
• We may care of having it done quickly and don't care so much if it's THAT pretty.
• We may want to make things consistent with the existing API.
• We don't want to miss Liferay features.

Service Builder is great at this, it generates code following many conventions, it generates javadoc and it basically does all the boilerplate for you so you only need to write 10 to 20 lines of business code and that's it.

So as a conclusion I would say that Service Builder is the best option if you're planning to use liferay as a web portal and not as an app container. If you're using it as an app container (which I really don't recommend) and you don't care that much of loosing a couple of liferay features, then you should definitely go with Spring and Hibernate since your life will be a LOT easier and you'll be able to write unit tests and those kinds of thins. 

jDTO Binder - Immutable DTOs

jDTO Binder 0.6 is out and with one new great feature. A really good practice in java is to minimize mutability of objects and with this you gain thread safety and also you can optimize memory by creating an instance pool; jDTO Binder can now instantiate objects by using a constructor other than the default and therefore making possible immutable DTO's

In order to take advantage of this feature, your DTO class should have one or more constructors with arguments and none default constructor. Also since some limitations of the Java Reflection API you need to configure each constructor argument to specify which will be the source value.

The following is an example of an immutable DTO:

public final class SimpleImmutableDTO {
    private final String firstString;
    private final String secondString;
    
    //make this the DTO constructor.
    @DTOConstructor
    public SimpleImmutableDTO(@Source("myString") String firstString, @Source("related.aString") String secondString) {
        this.firstString = firstString;
        this.secondString = secondString;
    }
    
    public SimpleImmutableDTO(String firstString, String secondString, String thirdString) {
        this.firstString = firstString;
        this.secondString = secondString;
    }
    
    public String getFirstString() {
        return firstString;
    }

    public String getSecondString() {
        return secondString;
    }
    
}

Immutable DTOs can take advantage of all of the features regular DTOs can except for "transient" constructor arguments which at the time doesn't make sense to me.

Also this feature is enabled for XML configuration:

<dto type="com.juancavallotti.jdto.dtos.SimpleImmutableDTO">
    <immutableConstructor>
        <arg type="java.lang.String">
            <source name="myString" />
        </arg>
        <arg type="java.lang.String">
            <source name="related.aString" />
        </arg>
    </immutableConstructor>
</dto>

Best Web Framework for Liferay Portlet Development

Over the past months I've tried several web frameworks for portlet development on the liferay community portal.

The options I've tried are:

• The framework liferay provides. (MVC Portlet, Alloy UI)
• Spring Portlet MVC
• Vaadin
• Java Server Faces (Portletfaces and Primefaces components)
• Java Server Faces (Portletfaces and IceFaces components)
• Apache Wicket.

In my opinion, I would rate these frameworks in the following way:

1. JSF Primefaces
2. Spring Portlet MVC
3. Vaadin
4. Liferay Framework
5. JSF IceFaces
6. Wicket.

This is the discussion of each:

JSF Primefaces

This is the one I found best, easy to configure, most of the components working out of the box, and easy spring integration. The con is, if you're used to JSF 2 and greater you'd find some missing features which are kind of important like view scoped managed beans and you loose the ability to send parameters over EL (this is because of the spring integration). But in general terms this framework fits great for general portlet development.

Spring Portlet MVC

This framework really gets along with the portal and is the ideal thing if you like to code tons of javascript and have fine grained control over everything. The con is the increased development time and if you have a project with lots of portlets then you'll have a lot of xml files.

Vaadin

Vaadin does a great job also for portlet development most of the components work out of the box, but it has some annoyances: 

• Every time you change something you need to re deploy your portlet.
• You need to have the same vaadin library you're developing deployed on your portal which may cause problems with older vaadin portlets.
• Compile-time weaving for spring integration.
• Some features mising.

Liferay Framework

This framework works really well on liferay, but is really a developer nightmare, not well documented, lots of javascript and java code, difficult to integrate with your own spring context. In general terms, this is only well-suited for really simple portlets with no ajax support.

JSF IceFaces

This is supposed to be the best option for liferay JSF portlet development, or at least that's what the creators say, nevertheless I couldn't really make it work after several hours of configuration and web browsing, but as it is a JSF framework, the basic jsf features work well, and I think with the proper documentation this could get really good.

Wicket

Even though I love wicket and was the first option I tried, I was disappointed that it barely worked. No wicket magic for ajax support and also wicket dropped support for portlets on 1.5 so really, is not a good option for liferay.

Well, that's it with the frameworks, I hope this short review can help you to find the best framework for developing liferay portlets.