Chapter 14. Portlet bridges
This chapter covers
- Introducing portlet bridges
- Using the iFrame portlet
- Developing with the JSF portlet bridge
- Developing with the Wicket portlet bridge
So far in this book, we’ve focused on creating portlets using the Portlet 2.0 API, but in some, if not all, portal development projects you may also want to expose an existing web application as a portlet. Let’s say that you have a Book Catalog web application for managing your book catalog, and it’s developed using the JSF, or Struts, or Wicket web application framework. You have the choice of rewriting the Book Catalog web application as a portlet or exposing it as a portlet by using an appropriate portlet bridge.
Think of a portlet bridge as a wrapper around your existing web application that’s responsible for converting portlet requests to something that your web application can understand and converting responses from the web application to something that your portlet environment can understand. Rewriting a web application as a portlet may be undesirable in many scenarios, mainly due to the learning curve associated with portlets, extra development and testing effort, and duplication of business logic. Rewriting an existing web application as a portlet may only be desirable if an appropriate portlet bridge doesn’t exist, or if the portlet bridge doesn’t support important portlet features, like using portlet events and public render parameters for inter-portlet communication.