The Power of Portlets
Submitted by Steve Moyer on Fri, 2006-06-23 15:40.
I've been an advocate, user and sometimes promoter of the Plone CMS (an extensible content management system built on the Zope application server, using the Python scripting language) for quite some time. For me, Plone's most important feature is the ability to create Plone "products", which plug into the CMS. This allows the creation of a web portal that provides standard HTML CMS functions out-of-the-box, but can be extended to include almost any imaginable application. There's also a great versioning system built into Plone products that allows a CMS administrator to update a product right from the user interface. It also doesn't hurt that I chose Python as my main scripting language (sorry Ruby users/lovers/zealots, but Ruby was my dogs name ... I didn't want to get the two confused. Just kidding! I like Python's consistent and minimalistic syntax. Unlike PERL, there's generally only one right way to do it).
With many sites already running on Plone, I still haven't been able to justify using it for any major web application development projects. For these, we need industrial strength scalability, a more structured language and the support of a mature application server. Combined with the availability of a large pool of expert developers, Java and J2EE has always made the most sense. The problem with selecting Java for these projects was the lack of a framework that allowed the easy, modular development of the application. The adoption of JSR-168 Portlets by the Java community and its implementation by several major application server vendors has finally created an environment that promotes modular components on a Java driven web application.
Here's the basics of how it works; The portal server determines which portlets are to be rendered on a requested page. It then asks each of those portlets to render HTML (it can actually be any content) and return it to the portal. The portal then inserts the content into a page and returns it to the user. To many of you, this sounds like a standard template system. What differentiates portlets from template fragments is the fact that each portlet can be a standalone J2EE application. The primary demonstration used for showing portlets power is to slightly modify and package the "Duke's Pet Store" application to run as a portlet. Now it is within the site administrators power to choose which applications are on each page of their web site.
Some of the features I like in the portlet system are:
- Portlet Modes - each portlet may have a view mode, edit mode and help mode by default and custom modes can be added.
- Window Modes - each "window" showing a portlet can be minimized, normal or maximized.
- Users and Roles - user privileges are determined using the authentication system of the underlying portal. With JACC and JAAS, you can plug in difference security and authentication modules ... want to use LDAP or a database table for user names and roles? Just pick one!
- Portlet properties - allow a prepackaged application to be somewhat customized after installation on a portal server.
- Application server - all the services available from a traditional Java application server are also available to each portlet.
- Themes/Layouts - Sites are completely skinnable. Each type of element on a Portal uses a specific CSS class, allowing L&F customization.
There are definite differences between the Plone and Portal servers. The major one relates to how the content is viewed:
- Plone is an object CMS and products define how new objects are created, edited, displayed and managed by the CMS system.
- Portals are generic application containers which only define how the page designed by the administrator is displayed.
After using Zope for 6 years and Plone for 3, it took a while to get used to these differences. On a Java Portal platform, I have complete freedom with how each application uses its portlet window, mode and controls. There aren't as many interfaces to implement, since there's no CMS wanting a "edit" method. On the other hand, if I want an HTML CMS system, I have to install a portlet that implements one and, once installed, I can't use it to manage other types of content. While this is a bit more limiting for a web site CMS, it ends up liberating an enterprise application. I can have teams independently develop application modules as portlets. These portlets are then combined to form each page of the application. If the customer wants to change the order of elements on a page, or wants to eliminate some of them altogether, it can be done without code changes.
I'm now in the process of designing my first enterprise application using portlets. Thus far, the feedback that I've received from my potential customers has been very positive (this all started with a customer asking me for Legos ... he wanted me to provide the tools for them to easily "snap together" an application that was organized the way they wanted it). I'll continue to provide updates as the development process progresses and I gather feedback on its use.
Here are some resources for further information on Java portlets:
- JSR-168 Portlet Specification - This is a relatively easy-to-read specification and a great starting point for understanding portlet technology
- JBoss Portal - A JSR-168 compliant portlet container. For a quick start, download the Portal server packaged with a JBoss application server.
- Portlet Swap - Open source portlets, themes and layouts to create your own site.