Many times I am asked why I’m such an advocate of portlet development over standard servlet development. “What are the advantages” the naysayers wonderk?  Well, for those of you still considering portlet development, let me give you ten reasons why you should make the switch.

1. Portlets development is the componentization of your web interface.  Just like desktop applications use windows to represent separate processes, portlets do the same for web-based applications.
2. Portlets are reusable.  If done correctly, portlets can be developed to be used over and over again on multiple pages with little or no customization.
3. Portlets frees you from being tied to one framework over another.  You could have five portlets using five different frameworks on the same page and still have robust web application.  This means you can harness the strengths of your resources rather than forcing them to all learn one development stack over another.
4. Portlets development is a relative easy paradigm shift.  That’s because its creators modeled it after the standard Servlet API.  (Check out my article on the topic for more info).
5. Deployment is a step easier if you use portlets.  Since portlets are only sub-components of the entire web application, you can easily install/uninstall portlets without affecting the overall webapp.
6. Portlet applications are easier to maintain. For the same as reason as #5, you can upgrade a portlet without having to re-install or re-work your entire web inteface.
7. Portlets are interoperable.  With JSR-286, inter-portlet communication is a built-in feature.
8. Portlets are supported by all the major frameworks.  Yes, this may seem like a repeat of  #3, but really it isn’t. The point here is that if you’re using Spring, Struts, or  JSF you can continue using those frameworks without having to learn a totally different one.
9. Portlets are easily customizable. In fact, this was one of the hallmarks of JSR-168: portlets can be customized by an authorized user while its active by just switching to the Edit mode and making the changes.
10. Portlets are skinnable.  In these times when having themes for skinnability, portlets have always been way out front in featuring this ability.

Well, I hope these 10 reasons help in convincing any skeptics that portlet development really is the only direction that future web application development can trend.   Please feel free to add any other reasons you can think of in the comments section.

Okay, okay. I admit I started out as an Eclipse user and thought very highly of that development environment — and I still do. However, several months ago I was on a project that encouraged the use of Netbeans so I decided to fit right in and just use it.

It took some adjustment but now, several months later, I still find myself going back to Netbeans again and again. Whether developing Swing, Java Web, or Liferay Portlets, Netbeans’ platform offers such a great development and testing framework thats hard to resist. For me, its the ease of use and integration with other tools with especially tight integration with Application and Web Servers.

But the very best part: Netbean’s debugging facility is sooo easy to use that it all comes down to just clicking a button. No messy steps to find and download appropriate plugins and then hope that they’ll work. Right now I’m testing a new Spring web app with Tomcat and I must say I’m very pleased with how easy it is to test.

I know, I know. Most Eclipse users won’t be so easily swayed. But that’s their problem. As for me, I’m loving using Netbeans and if you’re reading this I invite you to give it a chance as well. I think it can only your development life easier.

So, for all you willing and open-minded souls, here’s the link to the download page: Netbeans.org. Happy hunting!

When using the Liferay Plugin SDK to build portlets, I’ve discovered that:

1. Your portlet lib folder should contain only jars that are NOT in the Liferay portal ROOT lib folder.
2. If your portlet needs access to jars already in Liferay, edit the WEB-INFliferay-plugin-package.properties file and add those jars to the portal-dependency.jars area.

During the build, those jars are temporarily copied to the porlet lib area and deleted afterwards.  During deployment, those jars are copied from Liferay’s lib folder to the deployed portlet lib folder.

Problem:  if you’ve already copied the jars yourself, Liferay won’t do the copy.  This could lead to version headaches and all kinds of strange Exception errors within Liferay.