I've started a development project on the Liferay Portal server. Liferay is a nice opensource Java Portal server with auser-friendly  Web-2.0 interface. For example adding or repositioning portlets on a page is a simple drag-n-drop affair. Liferay also ships with a lot of portlets, so it's easy to build a portal site with Wikis, RSS feeds, and discussion forums right out of the box. However, I did run into a few irritating issues with Liferay:

jQuery version clash

I decided to use a third-party date-time picker widget that's built upon the excellect jQuery JavaScript library. The bad news is that I was not able to get this widget to work with the version of jQuery that Liferay requires for its own user interface. Luckily, I found a blog post that explained how to use multiple versions of jQuery in the same web page.

After loading my version of jQuery I restore the global "$" variable from Liferay's version...

<script type="text/javascript" src="js/jquery-1.4.2.min.js"></script>
<script type="text/javascript" src="js/jquery-ui-datepicker.js"></script>
<script type="text/javascript" src="js/date-en-US.js"></script>
<script type="text/javascript" src="js/newtimepicker.js"></script>
<script type="text/javascript">
    var jQuery_1_4_2 = $.noConflict(true);
</script>
 

Now my version's jQuery "$" variable is stored in "jQuery_1_4_2."  Everywhere in my code or the date-time picker code that references "$" has to be changed to reference "jQuery_1_4_2."  Ok, that worked around the problem, but it would have been much more efficient for Liferay to rename it's jQuery variable instead of forcing it's customers to rename theirs.

No-op CacheControl Object

The Java Portlet Specification defines a portlet content caching framework that can be programmatically controlled through a CacheControl object retrieved from the portlet container. Liferay's CacheControl object is just a plain Java bean with no connection to Liferay's caching facility. Portlet containers are not required to implement the caching portion of the specification, so Liferay has the right to return a useless CacheControl object. However, Java defines the java.lang.UnsupportedOperationException class specifically for the situation in which you don't implement an expected functionality. MimeReponse.getCacheControl() should return an UnsupportedOperationException in Liferay.

base.css Run Amok

Some of my new portlets needed to display data in HTML tables. For some reason the tables were ignoring my cellpadding attribute. In the end, I found that Liferay loads a bass.css style sheet that begins with:

body, div, dl, dt, dd, ul, ol, li, h1, h2, h3, h4, h5, h6, pre, form, fieldset, input, textarea, p, blockquote, th, td {
    margin: 0;
    padding: 0;
}

Let me be clear - there is no cause for a portal vendor to globally override the style of HTML elements that will be used by portlet developers. These CSS attributes should have been assigned to a Liferay-specific class:

.nopadding{
    margin: 0;
    padding: 0;
}

Then that class could be added to Liferay's HTML. Instead, I have to add a css class to my HTML. Rather than add a class attribute to every <td> element, you can add a class attribute to tables, then add the following css: 

.myTableStyle tr  th, .myTableStyle tr td{

    padding: 5px;

}