Five portlet development tips software engineers can't ignore

Here are five quick portlet development tips that software engineers will find helpful as they develop applications for the portal.

Anything worth doing is worth doing right, and that applies just as much for web based software development as it does for anything else. If you are a software engineer or application developer who is building software using the JSR-286 portlet API, here are some quick tips to help ensure that you are developing your applications the correct way.

Portlets should be fairly thin, primarily focused on client side presentation.

Cameron McKenzie, Editor of TheServerSide (@potemcam)

Use the expiration-cache Tag

Each portlet can have an expiration-cache entry in its deployment descriptor. This entry allows a portlet to cache content for a specified period of time. Caching of content can significantly improve the response time of a portlet and subsequently relieve the portal server from doing unneeded processing.
Furthermore, the RenderRepsonse object can be used to override the time specified in the deployment descriptor by using the EXPIRATION_CACHE property:

renderResponse.setProperty(EXPIRATION_CACHE, time);

Note that the time is entered in seconds. Setting the time to –1 means the cache will never expire and setting the cache to zero means the caching mechanism for the portlet is completely disabled. Think about the life expectancy of your portlet content, and set an expiration-cache tag appropriately.

Get Service Oriented

Don’t try to do too much in your portlets. Behavior coded into one portlet is very difficult to reuse in another portlet. Instead, factor our useful and potentially common behavior into a service layer. Portlets themselves should be fairly thin and primarily focused on client side presentation. Making a portlet too complex can slow down the portal and create a frustrating experience for the user. When common and useful behavior is factored out into a service tier, the service layer can be accessed by many different portlets, workload managed, and updated in a much more controlled fashion.

Handle IO Exceptions

When the portal invokes your portlet, but decides that it’s not going to wait for your portlet to finish processing, your portlet will encounter an IOException. You should handle the IOException in your code to ensure that when there is a problem, your clients get a message that’s a little more informative than simply seeing the words Portlet Unavailable.

If a portlet consumes a massing amount of processing time, and the portal server doesn’t want to wait for your portlet to finish processing, your portlet will encounter an IOException. In fact, if you’re doing a lot of heavy lifting in a portlet, you should occasionally check the flush method of the PrintWriter and handle a potential IOException. If you call the flush method of a PrintWriter or OutputStream in a portlet, and you get an exception, the portal server has essentially put the kibosh on your portlet and your portlet will not be rendered. At that point, you can end all of your complex computations because nobody is ever going to see the results.

Look out for the IOException in your portlet code. It will make your portlet applications all the more robust.

Encode Your NameSpaces

Many portlets, from potentially many different portlet providers, can appear on a single portal page. Each of those vendors can potentially throw a textfield on the page named password, or a JavaScript method called validate. These types of name collisions can result in portlets reacting to the wrong input data, or even worse, scripting errors when the web page is delivered to the user. To avoid name collisions on the portal server, all scripts, URLs, HTML form attributes, and the like, should be namespace encoded. Without encoding a namespace, your portlets will likely work properly in a sequestered, local test environment, but may encounter some very obscure and difficult to reproduce errors when your portlets go into production.

Comment Your Friggin’ Code

Good code comments itself. Good variable names, and a proper use of the API, should make it fairly easy for a new developer to figure out what your code is doing. But it is also true that good code is commented.

Commenting your code makes it extremely clear to other developers what your code was trying to accomplish. It also makes it easier for you to clear your thoughts and think about what you are trying to achieve as you write your code. Commented code is also a great reminder about what you were trying to accomplish when you first wrote the code. You’d be surprised how many times you come back to a piece of code and think "what the heck was I trying to do there???"

With these five tips in mind, software engineers are well on their way to effectively developing portlet applications that embrace a variety of important patterns and best practices.

Do you have any quick tips for mastering the JSR 286 portlet API? Let us know how you learned to be a great portlet developer.

Follow Cameron McKenzie on Twitter (@potemcam)

Recommended Titles

Liferay Portal Systems Development By Jonas X. Yua
Liferay in Action By Richard Sezov
OSGi in Action By Richard Hall
Enterprise OSGi in Action By Holly Cummins
The Well-Grounded Java Developer By Martijn Verburg

Dig Deeper on Web application framework and Java middleware

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.