List of Figures

Chapter 1. Introducing portals and portlets

Figure 1.1. The iGoogle home page containing portlets that show information from different sources: CNN, YouTube, Gmail, and so on. The portlets display the most relevant content and provide limited features to the user, in contrast to full-fledged web applications.

Figure 1.2. Portals aggregate content from different information sources. The portlets on the iGoogle portal page generate content for the page by retrieving information from the CNN, YouTube, and Gmail applications.

Figure 1.3. In this scenario, the user interacts with multiple web applications to access content. A separate web application exists to access content from each of the distinct sources of information.

Figure 1.4. The organization’s intranet makes it easy for users to access different web applications by redirecting users to the original web applications. In this scenario, the user is still interacting with individual web applications for information and services.

Figure 1.5. The organization’s intranet portal gathers content from different data sources, which means that users don’t need to access different web applications for information or services. In figure 1.4, the intranet website simply redirected users to the original web applications, but when using portals, the user is taken to the original web application only if little-accessed information or services are requested by the user.

Figure 1.6. An Articles portlet with buttons to configure, minimize, maximize, and close the portlet window. The options shown for a portlet will vary depending upon its configuration and the user’s access permissions.

Figure 1.7. The Location, Businesses, and Weather portlets interact with each other. The city information is passed from the Location portlet to the other portlets using the inter-portlet communication mechanism, resulting in seamless integration of the services represented by the portlets.

Figure 1.8. A portal server aggregates content generated by different portlets to form a portal page. Widgets in a web page interact with different information systems to obtain their content.

Figure 1.9. The portal infrastructure consists of a portal server and a portlet container. The portlet container manages the portlet instances and hands over the markup fragments generated by the portlets to the portal server. The portal server aggregates the markup fragments to create the portal page.

Figure 1.10. The portal server and portlet container roles in handling a portlet request. The portlet container is responsible for invoking lifecycle methods and handing over the portlet content to the portal server. The portal server assembles the content from different portlets to generate the portal page.

Figure 1.11. The directory structure for the Liferay-Tomcat prepackaged bundle. The deploy directory is the hot deployment directory, and tomcat-6.0.26 is the Tomcat home directory.

Figure 1.12. The Liferay Portal home page shows information about the portal server along with information about the sample website and the preconfigured users.

Figure 1.13. The Sign In option on the Liferay Portal home page

Figure 1.14. The Create Account option is for creating a user account with Liferay Portal

Figure 1.15. Authenticated users can do more things than unauthenticated users in Liferay Portal, such as changing their account settings and managing their public and private portal pages.

Figure 1.16. The iGoogle home page that users see when they log in. By default, the portal page has preconfigured portlets in it, which users can customize or personalize. A user-customized version of the iGoogle home page was shown in figure 1.1.

Figure 1.17. The My Pages option allows you to manage your public and private pages. The page information is displayed in a tree structure. You also have the option to create new pages for the portal.

Figure 1.18. The My Public Pages and My Private Pages options allow users to access the public and private portal pages associated with the organizations that the user has access to.

Figure 1.19. The More option in the Applications category allows authenticated users to add portlets to a portal page. Users can add portlets to portal pages only if they have permission to do so. By default, users can add or remove portlets from portal pages they created.

Figure 1.20. In most cases, portlets you add will have configure, minimize, maximize, and close options for customizing the portlet. The availability of these options depends upon the design of the portlet and the access permissions of the user.

Figure 1.21. The Configuration option for portlets in Liferay Portal allows you to set the access permissions for the portlet.

Figure 1.22. Permissions assigned to the RSS portlet. View permission allows the user to view the content generated by the portlet, and Configuration permission allows the user to configure the portlet’s look and feel and permissions.

Figure 1.23. In the New Server dialog box, select the Tomcat version used by your Liferay Portal installation. If you’re using Liferay Portal 6.x, Tomcat v6.0 Server should be selected.

Figure 1.24. Specify the Tomcat home directory and the JDK for the server. The Tomcat home directory is located inside the Liferay Portal home directory.

Figure 1.25. The Servers view shows the newly created server definition in Eclipse.

Figure 1.26. On the Server Locations tab, the Use Tomcat Installation option must be selected, and the Deploy Path setting must be webapps, which corresponds to the webapps directory inside the Tomcat installation.

Figure 1.27. Specifying additional virtual memory arguments in the launch configuration properties. If these additional arguments aren’t set, chances are good that you’ll get an out-of-memory error when you start Liferay Portal.

Figure 1.28. Adding libraries in the Edit Launch Configuration Properties page of the Edit Configuration dialog box. The libraries added here are used by Eclipse IDE to launch the server.

Figure 1.29. Adding the ch1_HelloWorld source in the Edit Launch Configuration Properties page of the Edit Configuration dialog box. This ensures that you can debug the source code.

Figure 1.30. Specifying timeouts for the server. If the timeout has a lower time limit than it takes to start the portal server, an exception will be thrown during server startup.

Figure 1.31. The Installed JREs preference allows you to set the JDK that will be used by the Eclipse IDE for all projects. The Add button allows you to add a new JDK to the Eclipse IDE.

Figure 1.32. The Add JRE wizard will help you add a new JDK to the Eclipse IDE.

Figure 1.33. The Compiler preferences let you specify compliance level for source code and generated class files.

Figure 1.34. Specifying the home directory of the JDK you want to add to the Eclipse IDE

Figure 1.35. The ch1_HelloWorld project structure is a generic project structure that we’ll use consistently in this book for creating portlet applications.

Figure 1.36. A simple Hello World portlet that displays the message “Hello World” when added to a portal page

Figure 1.37. Ant targets defined in build.xml. The build target is selected by default. The compile and clean targets can also be executed separately, if you want to compile or clean the project.

Figure 1.38. Bruno is the default administrator of Liferay Portal. Click the Login as Bruno link to log in to Liferay Portal as the portal administrator.

Figure 1.39. The Control Panel provides administrative options, which include granting access to portlets to roles defined in Liferay Portal.

Figure 1.40. The Roles option lets the administrator view, edit, and create roles. The administrator can also modify permissions associated with different roles in the portal.

Figure 1.41. The Define Permissions option lets a portal administrator define permissions for a role, including permission to add a portlet to a portal page.

Figure 1.42. The Add Permissions drop-down list shows the portlets currently deployed in Liferay Portal under the Applications category. You can select the portlet for which you want to modify permissions.

Figure 1.43. Permissions defined for the My Hello World portlet. Add to Page permission allows a user to view and add portlets from the Add > More option (under the Applications category).

Figure 1.44. The My Hello World Portlet listed under the Chapter 01 Portlets category, and the Hello World portlet on the portal page

Chapter 2. The portlet lifecycle

Figure 2.1. The form displayed by User Registration portlet

Figure 2.2. The User Registration success page shows the information that was entered during registration. The Home link takes the user back to the portlet’s user registration form.

Figure 2.3. An error message is displayed if the user doesn’t enter a value for the required Email field. The entered values for first and last name are redisplayed.

Figure 2.4. The message displayed when a user selects the option to personalize the User Registration portlet

Figure 2.5. The User Registration portlet’s help information page, displayed when the user selects the option to view help information about the portlet

Figure 2.6. A portlet’s request-processing phases apply to incoming requests based on the request type (action or render). The portlet’s render method is always called to ensure that the updated portlet content is displayed by the web portal.

Figure 2.7. The portlet URL is interpreted by the container to generate the portlet request. During request processing, the portlet sets self-referencing portlet URLs as part of its content.

Figure 2.8. Portlet lifecycle methods defined in the Portlet interface. An action request invokes the processAction method, followed by the render method. A render request invokes the render method. The timing of the init and destroy invocations depends on the portlet container implementation.

Figure 2.9. The GenericPortlet abstract class implements the Portlet, EventPortlet, and ResourceServingPortlet interfaces. It provides default implementations of the Portlet interface’s render method, and it dispatches render requests to the doView, doHelp, and doEdit methods, depending upon the portlet’s mode.

Figure 2.10. Additional options are available when the portlet supports additional portlet modes. The Preferences option is available when the portlet supports EDIT portlet mode, and the Help option is available when the portlet supports HELP portlet mode.

Figure 2.11. These personalization options for the News portlet are displayed when you select the Preferences option.

Figure 2.12. Help information for the News portlet is displayed when you select the Help option.

Figure 2.13. A sequence diagram depicting the default implementation of the GenericPortlet class’s render method. Based on the portlet mode, either the method with the @RenderMode annotation or the corresponding doXXXX method is invoked.

Figure 2.14. The User Registration portlet makes use of several objects, including PortletConfig, PortletContext, and RenderResponse, to accomplish its task.

Figure 2.15. The User Registration portlet page flow. The portlet defines the renderForm method for rendering the registration form and the registerUser method for processing the form submission.

Figure 2.16. Registration information sent by the User Registration portlet is rendered again by the portlet using the javax.portlet.actionScopedRequestAttributes container-runtime option. The portlet container retains the request attributes stored in the ActionRequest object and makes them available to the render method through the RenderRequest object.

Chapter 3. Portlet 2.0 API—portlet objects and container-runtime options

Figure 3.1. The Book Catalog portlet makes use of the BookServlet to generate content and process actions. The BookServlet generates HTML markup using JSP pages, and it interacts with the database to obtain or store book information.

Figure 3.2. The Book Catalog portlet’s home page. The portlet provides features to search for books, run the portlet in full-screen mode, upload and download book TOCs, and display the current portal server information.

Figure 3.3. The Add Book form of the Book Catalog portlet lets you add new book information to the book catalog.

Figure 3.4. The Upload TOC form used to upload a TOC for a book

Figure 3.5. PortletRequest is the superinterface of the RenderRequest, ActionRequest, ResourceRequest, and EventRequest interfaces. The subinterfaces define methods and fields specific to the request type.

Figure 3.6. The RenderResponse, ResourceResponse, ActionResponse, and EventResponse interfaces have a common superinterface, PortletResponse. The subinterfaces define additional fields and methods specific to the response types.

Figure 3.7. The What’s New portlet shows two major project wins. The Learn More About Wins link takes you to the Latest Wins portal page.

Figure 3.8. The HttpSession can access PortletSession attributes, which are stored with fabricated names in PORTLET_SCOPE. It can also access PortletSession attributes stored in APPLICATION_SCOPE using the names under which they were stored.

Figure 3.9. A series of action and render requests is sent to a portlet to demonstrate the behavior of the portlet on different portal servers: Liferay Portal 5.2.3/6.x, Jetspeed 2.2, and GlassFish Server (with OpenPortal Portlet Container 2.1.2).

Figure 3.10. The servletDefaultSessionScope container-runtime option allows included or forwarded JSPs or servlets to set or retrieve attributes directly to and from the PortletSession’s PORTLET_SCOPE. The APPLICATION_SCOPE session attributes are no longer accessible to included or forwarded servlets and JSPs.

Chapter 4. Portlet 2.0 API—caching, security, and localization

Figure 4.1. Initial content of the Book Catalog portlet, showing current date and time, books in the catalog, and the options to search for books in and add books to the catalog

Figure 4.2. Validation caching in the Book Catalog portlet. The portlet obtains the value of the validation token (which represents the record count value when the portlet content was last cached) from RenderRequest using the getETag method. The portlet then compares that value with the current record count in the database or data store.

Figure 4.3. The Book Catalog portlet displays labels in French when the locale is fr_FR.

Figure 4.4. The Language and Locale Selector portlets built into Liferay Portal and Jetspeed, respectively. You can select the locale by selecting one of the locale icons displayed in the portlets.

Figure 4.5. The Book Catalog portlet shows Help and Preferences links to view the portlet in HELP and EDIT portlet modes. The Print hyperlink displays the portlet in print custom portlet mode supported by Liferay Portal.

Figure 4.6. The Book Catalog portlet in print mode shows no form elements, making it easier for users to print out the book catalog.

Figure 4.7. The portlet’s doView or @RenderMode(name="VIEW") annotated method delegates render requests to more specific methods for content generation.

Figure 4.8. Liferay Portal’s built-in Document Library portlet allows you to manage documents. You can create folder structures and search for documents maintained by the library.

Figure 4.9. The PortalService interface defines methods that invoke portal server–specific methods. LiferayPortalService and JetspeedPortalService are concrete implementations of PortalService and provide service implementations specific to Liferay Portal and Jetspeed.

Figure 4.10. The BookCatalogService class implements the business functionality of the Book Catalog portlet. The BookCatalogService uses factory classes to obtain portal server–specific DAOs and services.

Figure 4.11. A sequence diagram showing how MyBookCatalogPortlet accesses the Liferay Portal–specific services. BookCatalogService has a reference to the appropriate implementation of the PortalService interface (LiferayPortalService, in this case), which invokes the addFile method of the DLLocalServiceUtil Liferay Portal service class.

Chapter 5. Building your own portal

Figure 5.1. The process described in this chapter for setting up a portal in Liferay Portal

Figure 5.2. Click the Add button to add a new organization to the portal.

Figure 5.3. Create an organization by entering a name and type for it. Clicking the Save button will save the organization information in the database used by Liferay Portal internally. The Modified message is displayed at the top right whenever a modification is made to the organization’s information.

Figure 5.4. Additional organization information is displayed to the administrator after the organization information is saved the first time. The administrator can upload a logo for the organization and specify its parent organization (if any). The Group ID uniquely identifies an organization in Liferay Portal.

Figure 5.5. Role information that needs to be added to Liferay Portal

Figure 5.6. Assigning a Liferay Portal role to an organization. The Update Associations button lets you associate a particular role with an organization.

Figure 5.7. Enter information about the user to be created in Liferay Portal.

Figure 5.8. Additional user information can be entered after the basic information is saved. The User ID uniquely identifies a user in Liferay Portal, the Password option is used to set the user’s password, the Organizations option is used to assign the user to an organization, and the Roles option is used to assign roles to the user.

Figure 5.9. Clicking the Select hyperlink opens the list of organizations in Liferay Portal. To associate the Book Portal administrator with MySamplePortal, Inc, click MySamplePortal, Inc organization from the list.

Figure 5.10. The Select option under Regular Roles lets you select regular roles like Administrator, Power User, BookUser, and so on. Select Administrator as the role for the Book Portal administrator.

Figure 5.11. MySamplePortal, Inc is shown as an organization that has been created in Liferay Portal.

Figure 5.12. Options available to the Book Portal administrator on the MySamplePortal, Inc organization

Figure 5.13. The Public Pages top-level tab shows three subtabs for managing the public portal pages of the MySamplePortal, Inc organization. You can add a new page here, edit an existing page’s title, or change the order in which they’re displayed in the portal.

Figure 5.14. The newly added Home page is shown in the page hierarchy displayed on the left side of the form. The View Pages button lets you view the pages of the MySamplePortal, Inc organization. The Display Order option lets you change the order in which the pages are displayed in the web portal.

Figure 5.15. Book Portal’s Home page, consisting of built-in Announcements, RSS, Sign In, and Calendar portlets

Figure 5.16. The 2 Columns (70/30) page layout partitions the page into two columns where the first column takes 70 percent of the page width and the second column takes 30 percent of the page width.

Figure 5.17. The Manage Entries tab allows you to add, edit, and delete announcements. The Distribution Scope drop-down list allows you to select the role for which you want to view, add, modify, or delete announcements.

Figure 5.18. The Announcement portlet allows you to specify the date and time when the announcement will be published and expired. The Distribution Scope lets you choose the user roles for which the announcement is being published.

Figure 5.19. The announcement portlet shows published announcements.

Figure 5.20. The Configuration option for the RSS portlet lets you specify the URL from which to receive the RSS feeds.

Figure 5.21. The RSS portlet showing the most popular products from Amazon tagged with “Java”

Figure 5.22. You can define permissions for a portal page by selecting the Manage > Page option from the dockbar. The Permissions button lets you modify permissions for the selected portal page.

Figure 5.23. Home page permissions for different roles. The BookUser role isn’t even allowed to view the portal page, and the Guest user can view the portal page but can’t update it.

Figure 5.24. The Permissions tab shows the permissions for the portlet. On this screen, you can modify the permissions for a portlet.

Figure 5.25. The Catalog portal page shows the Book Catalog and Document Library portlets to a portal administrator. The Document Library portlet isn’t visible to registered users of the portal.

Figure 5.26. The Add Folder option enables you to add a folder to the Document Library portlet. The Add Document option is for uploading a document to be stored by the portlet.

Figure 5.27. The Document Library portlet is used to store documents. You can view the download URL for a document by selecting the document in the portlet.

Figure 5.28. The Document Library portlet provides the download URL for a document, which can be used by other portlets to download a document directly without needing to go to the Document Library portlet.

Figure 5.29. The Download link in the Book Catalog portlet refers to the download URL obtained for the e-book from the Document Library portlet.

Figure 5.30. The Book Catalog portlet’s Upload Book form. You don’t upload the e-book; instead, you enter the download URL of the e-book, which is then used by the Book Catalog portlet’s Download link.

Figure 5.31. Giving View permission to the BookUser role and removing it from the Guest role

Figure 5.32. View permission for Guest is removed to restrict BookUser from accessing the Document Library portlet.

Figure 5.33. The Forums portal page contains the Message Boards portlet, which shows the message boards for various books.

Figure 5.34. Authentication settings allow you to set the authentication mechanism used to authenticate users with the portal server. You can choose LDAP, OpenSSO, or any other appropriate authentication provider supported by Liferay Portal.

Figure 5.35. OpenSSO authenticates the user against the User Repository, and if the authentication is successful, it allows access to the Book Portal and In-Demand Book Apps. The User Repository contains user credentials, and it’s in sync with the user information stored in the Liferay Portal database.

Figure 5.36. The BookUser role is specified as the default role for users. You can associate multiple default roles with a registered user by specifying each role on a separate line.

Figure 5.37. The Plugins SDK directory structure. The build.asarin.properties file represents a custom properties file that overrides the configuration in the build.properties file.

Figure 5.38. A Book Portal page that uses a custom theme. The background color is grey, the company logo is no longer the default Liferay Portal logo, and the breadcrumbs image looks like an arrow and not like an angle bracket (>) character.

Figure 5.39. Subdirectories of the classic folder, which contains the default Liferay Portal themes

Figure 5.40. Liferay Portal’s theme directory structure. The _diffs directory contains the custom CSS, images, and JavaScript files for the custom theme.

Figure 5.41. The custom Book Portal theme is displayed along with other themes.

Figure 5.42. The Look and Feel tab allows you to change the theme for the portal or for an individual portal page.

Figure 5.43. Contents of the 2-column-layouttpl project’s docroot directory

Figure 5.44. The newly created “2 columns (80/20)” layout template is available in the list of layout templates.

Chapter 6. Using the portlet tag library

Figure 6.1. The Book Catalog portlet’s Home page showing debugging information, including the values of the myaction request attribute, the myaction session attribute, and the uploadFolder portlet initialization parameter, along with the current portlet mode, the window state, and so on

Figure 6.2. The Book Catalog portlet implementation (from chapter 4), where the PortletSession stores the ISBN of the book for which the user wants to upload a TOC. The book’s ISBN is used to name the uploaded TOC file.

Figure 6.3. This Book Catalog portlet implementation makes use of the <actionURL> tag’s copyCurrentRenderParameters attribute to send the book’s ISBN to the action method responsible for uploading the book’s TOC. The book’s ISBN is used to name the uploaded TOC file.

Chapter 7. Getting started with Spring Portlet MVC

Figure 7.1. OrderHandler depends upon OrderService, which in turn depends upon OrderDAO.

Figure 7.2. Request processing in Spring Portlet MVC. The DispatcherPortlet acts as the front controller for each portlet and finds the handler mapped to the request using HandlerMapping. The result of executing a handler, ModelAndView, is used to resolve the actual view to be rendered, and the request is dispatched to ViewRendererServlet for rendering.

Figure 7.3. The web application context XML file is located in the WEB-INF directory and is named following the portletName-portlet.xml convention.

Figure 7.4. The controller hierarchies in Spring Portlet MVC. The command and form controllers are deprecated in Spring 3.0 in favor of annotated controllers.

Figure 7.5. The role played by HandlerMapping in fulfilling the portlet request. DispatcherPortlet obtains a HandlerExecutionChain from the HandlerMapping bean and invokes the HandlerExecutionChain’s handler and interceptors (if any).

Figure 7.6. The HandlerMapping interface is implemented by the AbstractHandlerMapping class, which is in turn subclassed by the PortletModeHandlerMapping, ParameterModeHandlerMapping, and PortletModeParameterHandlerMapping classes.

Figure 7.7. The Book Catalog portlet page that shows the list of books in the catalog. The portlet allows users to add books to the catalog, edit books already in the catalog, and remove books from the catalog.

Figure 7.8. ParameterHandlerMapping maps portlet requests to appropriate handlers based on the value of the myaction request parameter. If the request parameter is missing from the request, or if its value isn’t mapped to any handler, the handler specified using the defaultHandler mapping is executed.

Figure 7.9. A portlet request is mapped to a handler by matching the current portlet mode and the value of the myaction request parameter. The default handler is executed if no matching handler is found for the combination of portlet mode and request parameter value.

Figure 7.10. Handler interceptors are invoked before and after the execution of the handler. The preRenderHandle method is invoked before the handler execution, and the postRenderHandle method is invoked after the handler execution. The afterRenderCompletion method is invoked after the postRenderHandle method of all the interceptors is executed.

Figure 7.11. The request flow when an action request is received by DispatcherPortlet. The AddBookController is the handler for the action request because the value of the myaction parameter is addBook. If AddBookController changes the myaction parameter’s value to editBook, the render request would be handled by EditBookController instead.

Figure 7.12. DispatcherPortlet uses HandlerExceptionResolver to resolve exceptions that occur during the execution of the handler. HandlerExceptionResolver returns a ModelAndView object that is then forwarded by DispatcherPortlet to ViewRendererServlet to render the view.

Chapter 8. Annotation-driven development with Spring

Figure 8.1. The Book Catalog portlet’s home page listing the books in the catalog. The page gives the option to edit or remove an existing book’s information or to add a new book to the catalog.

Figure 8.2. The form for adding a new book to the catalog. Book title, author, and ISBN information must be supplied to add a new book to the catalog. The Home link takes the user back to the home page of the portlet.

Figure 8.3. When editing an existing book’s information or adding a new book to the catalog, error messages are shown if the required fields aren’t completed or the ISBN value is non-numeric.

Chapter 9. Integrating portlets with databases

Figure 9.1. Database tables used by the Book Catalog portlet to store book data

Figure 9.2. The context.xml and server.xml files in the Eclipse IDE’s Server project

Figure 9.3. Right-clicking the server instance in the Servers view shows the Publish option.

Figure 9.4. The Spring and non-Spring components that form the Book Catalog portlet. The BookCatalogPortlet class is a non-Spring object because it’s not registered with Spring’s web application context.

Figure 9.5. A high-level view of how AOP works. Calls to the target object are intercepted by an intermediate AOP proxy object, which is generated by the AOP framework.

Figure 9.6. The Book class maps to the BOOK_TBL table in the database. Attributes of the Book class map to columns of the BOOK_TBL table.

Chapter 10. Personalizing portlets

Figure 10.1. The Gmail portlet provides personalization options for portlet content and behavior.

Figure 10.2. The Book Catalog portlet’s Preferences page shows the options that can be personalized by users, including the preferred category, case-sensitive or case-insensitive search, preferred book, and so on.

Figure 10.3. The Book Catalog portlet’s home page shows personalized content to the user. Each book catalog entry shows the category to which the book belongs.

Figure 10.4. The PreferencesValidator’s validate method is invoked when the store method of PortletPreferences is called by the portlet implementation class.

Figure 10.5. The Book Catalog portlet shows a custom error message when the validation of one or more preferences fails.

Chapter 11. Communicating with other portlets

Figure 11.1. The Order and Inventory portlets communicate with their respective source systems and with each other.

Figure 11.2. The Add Book form of the Book Catalog portlet, for adding books to the catalog

Figure 11.3. The Recently Added Book portlet is updated every time a book is added to the catalog.

Figure 11.4. The Book Catalog and Recently Added Book portlets are on the same portal page. The Recently Added Book portlet shows information when a new book is added using the Book Catalog portlet.

Figure 11.5. Public render parameters are set as if they were private render parameters. The portlet deployment descriptor is responsible for distinguishing public render parameters from private ones.

Figure 11.6. The Book Catalog and Recently Added Book portlets communicate with each other using a render parameter that maps to the myBookISBN name in the http://www.mynamespace.com/ namespace.

Figure 11.7. The Recently Added Book and Book Catalog portlets get book data from their respective ServletContexts. In a real-world situation, both portlets would obtain book data from a shared database.

Figure 11.8. Portlet C processes the event generated by portlet A in the event phase. The portlet container processes generated events before invoking the render method of the portlets on the portal page.

Chapter 12. Ajaxing portlets

Figure 12.1. Ajax request handling. JavaScript in the portal page sends an asynchronous request to a servlet or portlet component, which processes the request and returns an HTML, XML, text, or JSON response to the browser. JavaScript in the portal page makes use of the response data to update a part of the portlet’s content.

Figure 12.2. A Date/Time portlet that displays a “Hello World” message and the server’s current date and time when the Refresh hyperlink is clicked

Figure 12.3. A sequence diagram of the resource request-processing lifecycle. The resource request doesn’t result in the invocation of the render methods of other portlets on the portal page.

Figure 12.4. In the case of a non-Ajax resource request, the only HTML displayed in the web browser is the HTML written to the ResourceResponse.

Figure 12.5. The Book Catalog portlet uses a tabbed pane to divide up content in the user interface. If a new book is added or removed from the catalog, a notification is displayed to the user.

Figure 12.6. Form for uploading a book’s TOC file. This form is displayed when the user clicks on the Upload link for a book (see Figure 12.5).

Figure 12.7. Form for adding a new book to the catalog. The form is displayed when the user selects the Add Book tab or clicks the Add Book link shown on the catalog page (see Figure 12.5).

Figure 12.8. Sequence diagram that shows the steps required in calling a remote Java object using the XMLHttpRequest object and parsing the results to update the portal page. The web browser sends a request to a portlet or servlet component which creates the SearchCriteria object and passes it to the searchProfile method of the ProfileBean object.

Figure 12.9. The Comet implementation in the Book Catalog portlet using DWR. The web browser creates a ScriptSession when the portal page containing the Book Catalog portlet is loaded. Every 60 seconds, a long-lived HTTP connection is created by sending a request containing the ScriptSession ID to the server. UpdateSender writes JavaScript code to ScriptSession, which is sent to the browser for execution.

Figure 12.10. A cross-domain request can be proxied through the server from which the portal page was downloaded, in order to address security issues related to cross-domain requests.

Figure 12.11. Inter-portlet communication using Comet. The UpdateSender thread retrieves communicated information from the in-memory ActiveMQ JMS destination.

Figure 12.12. Inter-portlet communication using a JavaScript function. The Book Catalog portlet invokes the getRecentBook method of the Recently Added Book portlet, which updates the content.

Chapter 13. Reusable logic with portlet filters

Figure 13.1. The filter interfaces that apply to the different lifecycle methods of a portlet. PortletFilter defines init and destroy methods, and each subinterface defines a doFilter method.

Figure 13.2. The portlet filter lifecycle. The portlet filter does the preprocessing of the request or the postprocessing of the response. FilterChain passes the request to the next filter in the chain, or to the target portlet if the filter is the last filter in the chain.

Figure 13.3. UtilityFilter shows the message, “WARNING: Action request makes use of GET HTTP method” when the action request sent to the Book Catalog portlet uses the HTTP GET method. In the case of the Book Catalog portlet, an HTTP GET is used for the action request that’s sent when a user clicks the Remove hyperlink.

Figure 13.4. The name of technology in the book title is displayed as a hyperlink. RenderResponseWrapper is used to convert the text to a hyperlink in the response.

Chapter 14. Portlet bridges

Figure 14.1. The Portlet bridge plays the mediatory role in adapting a web application to the portlet environment.

Figure 14.2. The iFrame portlet in the Sample category is used to display external web applications as portlets in a web portal.

Figure 14.3. Configuration options for the iFrame portlet. You can specify the URL of the external web application, the authentication details, and the attributes of the HTML <iframe> element that’s used by the iFrame portlet.

Figure 14.4. The Book Catalog web application home page. The Remove hyperlink lets a user remove a book from the catalog, and the Add Book button show a form for adding a new book to the catalog.

Figure 14.5. The Add Book form is used to add a book to the catalog. This page makes use of JSF 2.0 Ajax support to validate the form.

Figure 14.6. Directory structure for creating Book Catalog JSF web application and portlet application that uses PortletFaces Bridge

Figure 14.7. The Book Catalog web application developed using the Wicket web framework. It shows the books in the catalog in a tabular format and lets you page through the list.

Figure 14.8. Directory structure for creating the Book Catalog Wicket web and portlet applications

Chapter 15. Web Services for Remote Portlets (WSRP)

Figure 15.1. The web service provides the business logic, and the web service client provides the user interface and presentation logic.

Figure 15.2. The seller publishes a Merchant portlet that merchants add to their web portal. The WSRP producer and WSRP consumer act as publisher and consumer of the Merchant portlet, respectively.

Figure 15.3. Producers and consumers communicate with each other to make remote portlets a reality. A consumer communicates with remote portlets using portlet handles.

Figure 15.4. Clicking the Install More Portlets button shows the list of portlets that aren’t yet installed in the Liferay Portal instance. You can also search and install portlets.

Figure 15.5. Search for WSRP portlet by entering wsrp in Keywords field and click the Search button. Search result will show a WSRP plugin portlet.

Figure 15.6. Details of WSRP plugin portlet. Clicking the Install button installs the WSRP plugin portlet in Liferay Portal instance.

Figure 15.7. The WSRP option allows the portal administrator to manage WSRP consumers and producers configured for the Liferay Portal instance.

Figure 15.8. Clicking the Producers option allows the Liferay Portal administrator to manage WSRP producers for the Liferay Portal instance.

Figure 15.9. The Producers tab displays a list of WSRP producers configured in Liferay Portal, and it allows the administrator to add new WSRP producers or make changes to existing WSRP producers.

Figure 15.10. The Add Producer form allows the administrator to add a new WSRP producer. It also allows one or more installed portlets to be added to the WSRP producer.

Figure 15.11. The Edit option allows the administrator to modify the details of a WSRP producer, and it also displays the URL of the producer’s web service endpoint.

Figure 15.12. The URL field shows the WSRP producer’s web service endpoint URL. The WSRP consumer uses the producer’s web service endpoint URL to interact with the portlets hosted by the producer.

Figure 15.13. The Consumers tab displays a list of WSRP consumers configured for the Liferay Portal instance and also provides the option to add new WSRP consumers.

Figure 15.14. Add a WSRP consumer by specifying a name for it and the URL of the WSRP producer web service endpoint for which it acts as a consumer.

Figure 15.15. The Consumers tab shows the list of WSRP consumers. The Actions button allows you to manage remote portlets made available to the local Liferay Portal instance by each WSRP consumer.

Figure 15.16. The Manage Portlets screen shows the list of portlets that have been locally registered by the WSRP consumer. The Add Portlet option allows the WSRP consumer to locally register remote portlets.

Figure 15.17. The Add Portlet screen allows you to locally register remote portlets.

Figure 15.18. The User Registration portlet is displayed with the title “Register Me !!” under the WSRP category.

Figure 15.19. The OpenPortal WSRP producer portlet allows consumers to register using in-band or out-of-band registration. The Registration Property Descriptions section defines properties that are required for registering using the in-band approach.

Figure 15.20. The Edit Registration option is available when the corresponding WSRP producer requires consumers to register.

Figure 15.21. The Registration screen allows you to enter the WSRP consumer’s registration information so it can register with a WSRP producer. Registration can be in-band or out-of-band.

Figure 15.22. Out-of-band registration only requires you to enter the registration handle.

Figure 15.23. The Lifetime Supplied option allows you to enter a specified time period for the registration.

Appendix A. Getting started with GateIn Portal

Figure A.1. The GateIn-Tomcat bundle’s directories. The gatein directory contains configuration and portal data used by GateIn Portal. The webapps directory is Tomcat’s hot deploy directory, which contains the WAR files.

Figure A.2. The GateIn Portal home page. The Administrator option allows you to log in to the GateIn Portal as an administrator. The Sign In option allows you to provide your own login credentials to log in.

Figure A.3. A logged-in user sees a toolbar with various additional options determined by the access permissions defined for the user. Additional portal pages are also displayed, depending upon the user’s access permissions.

Figure A.4. The Site option is used to manage web portals created in the GateIn Portal instance. The Add New Portal option is used to add a new portal to the GateIn instance.

Figure A.5. The form for entering details to create a new web portal

Figure A.6. The Properties tab lets you specify the timeout property for the user session.

Figure A.7. The Access Permission Setting subtab is used to specify access permissions for the web portal.

Figure A.8. Clicking the Select Permission button allows you to select the user groups and roles you wish to grant permission to make modifications to the web portal.

Figure A.9. The Permission Selector shows the user groups on the left side and the memberships (or roles) on the right side. Select the user groups on the left, and then the roles you want to assign to those groups on the right.

Figure A.10. Select Platform > Administrators as the user group and manager as the membership to assign edit permission to the Administrator user.

Figure A.11. Selected permission settings are displayed in the Edit Permission Setting subtab.

Figure A.12. The newly created Book Portal is displayed in the list of web portals that the Administrator can manage.

Figure A.13. The form for entering user details. The user’s account details are entered on the Account Setting tab, and personal information about the user is entered on the User Profile tab.

Figure A.14. User, group, and membership management options available to administrators

Figure A.15. The + button in the Groups pane is for adding a new group or subgroup to GateIn Portal.

Figure A.16. The Add New Group form lets you add a new group or subgroup to GateIn Portal.

Figure A.17. Selecting a group shows the users that belong to that group, their memberships, and an option to search for and add users to the group.

Figure A.18. The Edit Portal’s Config option allows you to change the access and edit permission settings for a web portal.

Figure A.19. The web portal’s Navigation Management window allows you to modify the navigational structure of the web portal. Right-clicking a navigation node allows you to perform various actions on a node.

Figure A.20. The Page Creation wizard for entering navigation node and page details

Figure A.21. Page Editor shows portlets/gadgets that you can drag and drop on the portal page, view page properties, save changes to the portal page and add container(s) to the portal page to organize portlets/gadgets on the portal page.

Figure A.22. The View Page Properties button opens this dialog box, which allows you to set permissions for the portal page.

Figure A.23. The Add Category panel shows the portlets that are currently registered with GateIn Portal. Clicking the Import Applications option imports the portlets defined in the deployed portlet applications.

Appendix B. Configuring Liferay Portal with MySQL database

Figure B.1. The MySQL Server Instance Configuration Wizard allows you to specify the root user’s password.

Figure B.2. The HeidiSQL client screen for connecting to a MySQL instance

Figure B.3. The HeidiSQL client user interface lists databases in the MySQL Server instance, lets you run SQL queries, and offers many other features.

Figure B.4. The Create Database option is available when the user right-clicks inside the window pane listing databases in the MySQL Server instance.

Figure B.5. The Create Database dialog box, where you enter the database name

Figure B.6. The_USER table lists the registered users in Liferay Portal.

Figure B.7. The ROLE_table stores the roles defined in Liferay Portal.

Figure B.8. The PERMISSION_table stores permission definitions for resources in Liferay Portal