Recently, I was charged with the task of creating a portlet that would interact with Confluence. The idea was to see how difficult it is, to make a Proof of Concept (ideally, something useful), and to generate a bunch of documentation about the process.
So how difficult was it?
Not so bad, given that I had next to no prior experience with portlet development. I’d say the biggest hurdle was administering the portal application. I chose to develop with Liferay. I wouldn’t say that it was exactly a joyous experience working with it. (About once a day for the first week and a half, I’d run into some truly gruesome administrative problem, and lose 2 hours or worse trying to track down how I had broken it.) On the other hand, now that I’ve passed the initial learning curve, I’d be willing to continue developing with it.
What about portability? Are these portlets only good with Liferay?
The portlets should be portable to any JSR-168 compliant portal application. Many major portal applications (Oracle, Websphere, and also Liferay) repute JSR-168 compliance. In theory, this should mean that a JSR-168 compliant portlet should be easy to install into a JSR-168 compliant portal. In reality, JSR-168 compliant portal apps can still require portal specific libraries and other dependencies. So, once you know what those are, it shouldn’t be too difficult to install the portlet. But it is disappointing that you can’t just deploy the portlet as it stands and expect it work. Since I’ve only developed with Liferay, I can only give advice on deploying the portlets to Liferay, and so portability is currently a matter of optimism more than certainty. I mean, really, they should work in other portal apps.
Did I come up with something useful?
I’d like to think so. 🙂
There’s 2 portlets and a new XMLRPC plugin bopping around on CONFEXT as a result:
These basically do what you’d expect.
The Search Portlet allows users to query any Confluence server that can take anonymous Remote API requests. Results are links to Confluence pages.
The Recently Updated Portlet displays the 10 most recently updated pages anonymously visible on a Confluence Server.
The Recently Updated Xmlrpc Plugin exposes a getPages method as an Xmlrpc Service so that the portlet can display the correct results.
Each of these would allow a portal server to have functionality very similar to elements of the Confluence Dashboard. This could be very handy for improving Confluence visibility and user adoption in an enterprise setting where their portal app is highly used.
So how are these useful as portlet development examples?
Aside from just being relatively simple examples of working portlets, they both handle server requests differently.
If you want to see the standard portlet way of submitting POST requests, then you should look at the Recently Updated Portlet.
If you want to see an AJAX way of submitting requests to the portlet, then check out the Search Portlet.
Code is available here:
Documentation on Installing the Portlets is here:
And Documentation on Developing the Portlets is here: