Introduction to java standard portlets


Published on

This presentation gives an overview on Java standard portlets. It speaks about the trends in java portals and java specification requests created to achieve the Java portlet programming. It also tells the portal advantage over the conventional approach of web programming based on Java platform.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introduction to java standard portlets

  1. 1. Introduction to Java Standard Portlets R O H A N FAY E 1
  2. 2. Contents World before portlets A typical JSP based architecture Limitations with application based on Servlets / JSP Rise of portals – the introduction Portal and Portlets Examples Advantages Portlet Lifecycle 2
  3. 3. Contents (contd.) Portlets Request and Response Java Portlet Specification Portlet modes and window states Portlet filters Inter Portlet Communication Code Walkthrough Q&A References 3
  4. 4. World before portlets Conventional approach Static HTML Dynamic web applications ◦ Servlets and JSP technologies Examples 4
  5. 5. A typical JSP based Architecture 5
  6. 6. Limitations with application based on Servlets / JSP Following are the notable drawbacks of the Servlets and JSP based web applications: User can view and has access to the single web application at a time Lack of content aggregation Limitations to the content configuration and customization per user Lack of different application modes Lack of Window states support 6
  7. 7. So how to deal with this? Are we not at our best in the business?? 7
  8. 8. Rise of portals – the introduction Need of a real application, which itself will act as a base engine Container for other integrated applications Secure and robust API Cost effective Developer friendly Ease of use 8
  9. 9. What is a portal? A portal is designed to be a single web-based environment from which all of a user’s applications can run, and these applications are integrated together in a consistent and systematic way. 9
  10. 10. Gotcha! Then what is a portlet? Portlets are pluggable user interface software components that are managed and displayed in a web portal. Produce fragments of markup code that are aggregated into a portal. Displayed as a collection of non-overlapping portlet windows, where each portlet window displays a portlet Resembles a web-based application that is hosted in a portal. Portlet standards are intended to enable software developers to create portlets that can be plugged into any portal supporting the standards. 10
  11. 11. For example… 11
  12. 12. Advantages Portlets have additional characteristics that make them different from Servlets. Portlet Modes Window States Portlet Preferences Standard Inter Portlet Communication (IPC) ◦ Public Render Parameter ◦ Events Resource Serving ◦ AJAX Support ◦ Binary data support Portlet Filters 12
  13. 13. Wonderful! This will definitely enhance the way we do business and attract more customers!!! I smell money… $$$ 13
  14. 14. Portlet lifecycle init() : Initializes the portlet render() : Renders the content processAction() : Called when the user performs the action processEvent() : Called when an event has been triggered serveResource() : Called when a ResourceURL is requested Destroy() : Releases the portlet object so it is eligible for garbage collection. 14
  15. 15. Portlet lifecycle (contd.) init phase – The init() method is called by the Liferay portlet container during the deployment of the project. This method is typically used to read initialization parameters from the portlet.xml. Render phase – During the Render phase, the portlet generates content based on its current state. The Render phase is called on all of the portlets on a page when that page is rendered. Portlets typically enter the Render phase as a result of page refresh or after the completion of the Action phase. Action phase – The portlet enters the Action phase as a result of the user interacting with that portlet. Specifically, the user interaction should result in a change of the state in the portal. Only one portlet can go through the Action phase during single request/response cycle. 15
  16. 16. Portlet lifecycle (contd.) Event phase – The Event phase is used to process any Events triggered during the Action phase of the portlet lifecycle. Events are used for Inter Portlet Communication (IPC). Resource Serving phase – This phase allows portlets to serve dynamic content without the need calling the Render phase on all the portlets on the page. In Portlet 1.0, portlet requests always returned a full portal page. Destroy phase – This method gets called by the Liferay portlet container when it is removed from service. This phase allow to release any resources. 16
  17. 17. Portlet Request and Response 17
  18. 18. Java Portlet Specification The Java Portlet Specification defines a contract between the portlet container and portlets and provides a convenient programming model for Java portlet developers. ◦ JSR 168 ◦ JSR 286 18
  19. 19. JSR 168 (Portlet 1.0) The Java Portlet Specification V1.0 introduces the basic portlet programming model with: Two phases of action processing and rendering in order to support the Model-ViewController pattern. Portlet modes, enabling the portal to advise the portlet what task it should perform and what content it should generate Window states, indicating the amount of portal page space that will be assigned to the content generated by the portlet Portlet data model, allowing the portlet to store view information in the render parameters, session related information in the portlet session and per user persistent data in the portlet preferences A packaging format in order to group different portlets and other Java EE artifacts needed by these portlets into one portlet application which can be deployed on the portal server. Portal development is a way to integrate the different web-based applications for supporting deliveries of information and services. 19
  20. 20. JSR 286 (Portlet 2.0) It was developed to improve on the short-comings on version 1.0 of the specification, JSR-168. Some of its major features include: Inter-Portlet Communication through events and public render parameters Serving dynamically generated resources directly through portlets Serving AJAX or JSON data directly through portlets Introduction of portlet filters and listeners 20
  21. 21. Portlet Modes Each portlet has a current mode, which indicates the function the portlet is performing All Java Standard compliant portals must support the View, Edit and Help modes. Portlet modes are defined in the portlet.xml file. Custom modes may be created by developers. View Mode – Typical portlet is first rendered in View Mode. Edit Mode – When the user clicks on the “Preferences” icon, the portlets switches to Edit mode. Help Mode – When the user clicks on the Help icon, the portlet switches to Help Mode. 21
  22. 22. Window States Window States indicate the amount of space that will be assigned to a portlet. All Java Standards compliant must support minimized, maximized and normal. Minimized Window State – When the user clicks on the Minimize icon, only the portlet titlebar is displayed. Maximized Window State – When the user clicks on the Maximize icon, the portlet will take up the entire width of the page, and become the only portlet rendered on the page. Remove Window – When the user clicks on the Remove icon, the portlet is removed form the page. 22
  23. 23. Portlet Filters Filters are Java components that allow on the fly transformations of information in both the request to and the response from a portlet. They allow chaining reusable functionality before or after any phase of the portlet Lifecycle: ◦ ◦ ◦ ◦ processAction processEvent serveResource render Modeled after the filters of the Servlet specification 23
  24. 24. IPC (Inter Portlet Communication) Inter-portlet communication (IPC) is a technique whereby two or more portlets on a portal page share data in some way. In a typical IPC use case, user interactions with one portlet affect the rendered markup of another portlet. 24
  25. 25. IPC - Importance IPC becomes important with Portlet applications which are composed of more than one portlet for their functionality. Consider a banking application with one portlet at the top screen which allows users to search for customers. When a customer is selected, a portlet on the bottom of the screen shows a list of that customer’s information and associated bank accounts. With IPC this functionality can be done in a standard way-and the two portlets don’t even need to be on the same portlet page. 25
  26. 26. Achieving IPC The Portlet 2.0 standard provides two techniques to achieve Inter portlet Communication : ◦ Public Render Parameters ◦ Server-Side Events 26
  27. 27. Public Render Parameters The Simplest method for developer to perform standard IPC. A developer can declare a list of public render parameters for a portlet application in portlet.xml: The parameter names are namespaced to avoid naming conflicts.. </portlet-app> <public-render-parameter> <identifier>foo</identifier> <qname xmlns:x="">x:foo2</qname> </public-render-parameter> . . </portlet-app> 27
  28. 28. Public Render Parameters (contd.) Portlets must declare which public render parameters they want to read by using supported public-render-parameter element : <portlet> <portlet-name>Portlet A</ portlet-name>< <supported-public-render-parameter> foo </supported-public-render-parameter> </portlet> 28
  29. 29. Public Render Parameters (contd.) A portlet can read a public render parameter by using: ◦ request.getPublicParameterMap() Public parameters are merged with regular parameters so can also be read using: ◦ getParameter(name) ◦ getParameterMap() A portlet can remove public render parameter by invoking: ◦ response.removePublicRenderParameter (name) ◦ portletURLremovePublicRenderParameter (name) 29
  30. 30. Server-Side Events Very powerful and highly decoupled method for IPC. Uses a producer-listener pattern. ◦ One portlet generates an event. ◦ Other portlets may be listening and acting upon it. Allows communication between portlets in different applications. Additionally the container may also generate its own events. ◦ No Specific container has been standardized yet. But beware of the added complexity. 30
  31. 31. Server-Side Events (contd.) Portlets can publish events from its processAction code. Publishing an event causes one or more invocations of the new processEvent method in this or other portlets. From the implementation of processEvents new events may also be published . Note that there is no guarantee in the order of delivery of events. 31
  32. 32. Code walkthrough 32
  33. 33. Questions, comments or suggestions? 33
  34. 34. Thank You! References: Liferay in Action – Manning 34