1. JSR-168 Portlets and uPortal Matt Young matt.young@duke.edu

2. Goals Familiarity with portlet architecture Familiarity with the services provided to portlets by the spec Ability to write useful portlets Provide examples that can be used as a cut & paste source for common tasks Explore MVC options

3. Overview What’s a portlet? What is its relationship with a portal? How is it deployed on a web server? What deployment descriptors does it need? How is the code laid out? What services does it provide?

4. What is a Portlet? A portlet produces an HTML fragment that populates a window (or channel) within a portal page The portlet can communicate with the portal container

5. Portals and Portlets Portal Tomcat Application Server Portlet App Weather Portlet Search Portlet Events Calendar Portlet Search Controller Portlet Search Results Portlet Pluto

6. uPortal and Portlets uPortal Tomcat Announcements Channel UBC Webmail Application Server RSS Feed Weather Portlet Wrapper Search Portlet Wrapper Event Cal. Portlet Wrapper Pluto Weather Portlet Search Portlet Events Calendar Portlet

7. uPortal Announcements Channel UBC Webmail RSS Feed Weather Portlet Wrapper Search Portlet Wrapper Event Cal. Portlet Wrapper

8. A Portlet in uPortal Weather Portlet Wrapper (an instance of CPortletAdapter) edu.duke.oit.ows.portlets.WeatherPortlet

9. The Portlet Pieces Source Code portlet.xml web.xml

10. <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> Hello World Portlet

11. portlet.xml <portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd" version="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"> HelloWorldPortlet edu.duke.oit.ows.HelloWorldPortlet 0 text/html EDIT HELP Hello World Portlet

12. When changing portlet.xml You’ve got to restart uPortal for the changes to show up, even after a re- deployment! I will forget to do this at least once today

13. Portlet source code Extend GenericPortlet (or other portlet class, like JSPPortlet) Override one or more standard methods: doView, doEdit, doHelp, processAction

14. Portlet Modes View: The default portlet mode, providing the standard UI for the portlet Edit: A mode for setting user-configurable preferences Help: Displays help for using the portlet Modes can be specified on a per mime-type basis Custom modes can be defined by the portal to provide more modes

15. Window States NORMAL: A regular window MAXIMIZED: A window taking up the entire content space of the portal page MINIMIZED: Just the title bar of the portlet Custom window states make also be defined by the portal EXCLUSIVE: uPortal adds this mode to facilitate file uploads

16. processAction The processAction method is called when the portlet receives an action. This is where any logic that the portlet provides should be tripped, including storing/updating preferences

17. Call sequence

18. About the init method It is not safe to assume that the portlet is in an active portal container until the init method is called. Therefore, make no attempt to access services from the constructor of the portlet or in any location before the init method is called

19. Hello World Portlet

20. Deploying the Portlet Step 1: User uPortal ant target ‘deployPortletApp’ to deploy application to the server ant deployPortletApp -DportletApp= Step 2: Configure uPortal to see the portlet as a channel Portlet Defintion ID: warFileName.portletName

21. Notes about Portlet Deployment If you do something wrong, uPortal is likely to cache the error. Best to restart in a development environment to make sure deployment descriptors are correct Deployment happens just like a regular web app, except that the ant task alters the web.xml file to make it usable by uPortal

22. Creating an action First, generate an actionURL PortletURL actionURL = response.createActionURL(); Then, actionURL.toString() will provide the URL that will trip a processAction call. Parameters can be added to the actionURL (or any other PortletURL) with actionURL.setParameter(String name, String value);

23. Changing Modes VIEW / EDIT / HELP are default modes To change modes, generate an action URL: PortletURL actionURL = renderResponse.createActionURL(); This calls the processAction method when followed, then, within the processAction method, set the appropriate destination mode: actionResponse.setPortletMode(PortletMode.EDIT);

24. Modes and uPortal buttons EDIT -> EDIT HELP -> HELP

25. Portlet Parameters Parameters can be set within the portlet.xml file so that compiles are not required to move portlets from installation to installation There are 2 kinds of parameters, init- params and portlet-preferences

26. init-param Initialization parameters (ie. Site dependant constants) specified in portlet.xml defaultZipCode 27705 Readable from a PortletConfig object available in all init methods String zipCode = config.getInitParameter(“defaultZipCode”);

27. portlet-preferences When defined within the portlet.xml file, these are default values for the per-user runtime preferences Preference values may be set as read-only Essentially a variable initialization mechanism for runtime user preferences

28. User Preferences Each portlet can use the portal’s data store to hold on to per-user preferences To read in preferences: PortletPreferences prefs = request.getPreferences(); To read a particular named preference: prefs.getValue(String pref_name, String default); The above will return default if there is no preference named pref_name for that user, otherwise the value of that preference will be returned

29. User Preferences The getValue() method returns a String The getValues() method returns a String[] Preferences are read-only in all the “do” methods Preferences are read-write in the processAction method

30. User Preferences To store preferences: PortletPreferences prefs = actionRequest.getPreferences(); prefs.setValue(“nickname”, “Matt”); prefs.store(); Values are not committed until the store() method of PortletPreferences is called User preferences should not be used as a general purpose database. The intent is only to hold portlet preferences (settings) Use JNI or another method for getting a database handle if larger scale db operations are needed

31. User Attributes Some basic security attributes are available from the request object: request.getAuthType() <-- returns a constant request.getRemoteUser() <-- login ID request.getUserPrincipal() <-- returns user principal request.isUserInRole(String) <-- role (group) checking request.isSecure() <-- https? (or equivalent?)

32. User Attributes Portlets can be granted access to the user attributes available in the portal framework In uPortal terms, these are the attributes defined in the PersonDirs.xml file Available attributes must be defined in the portlet.xml file (JSR-168) spec in addition to the PersonDirs.xml file (uPortal)

33. User Attributes Attribute values can be retrieved in the portlet from the USER_INFO map returnable from a renderRequest or actionRequest Map userInfo; userInfo = request.getAttribute(PortletRequest.USER_INFO); String uniqueID = userInfo.get("uniqueID");

34. Caching uPortal caches portlet content until the portlet receives and action or a render request. This means that the ‘reload’ button will not update content in portlets. Only interaction with the portlet will cause an update This turns out to be a useful mechanism for reducing load on external resources It also keeps portal response very fast

35. Better display options Keeping your (X)HTML in the portlet code is not optimal. Best practice is to separate logic from view. Some options for a better View technology:  JSP  JSF  XSLT  Spring (in beta - coming soon, example in the CVS repository for uPortal)

36. Request Dispatchers You can use a PortletRequestDispatcher to send the PortletRequest onto another rendering service First obtain the request dispatcher from the portletContext: PortletRequestDispatcher rd = getPortletContext.getRequestDispatcher(“/MyPortletView.jsp”); Then, include the current request and response so that parameters can be seen by the.jsp (or JSF, or other rendering service): rd.include(request,response);

37. CSS Standards The JSR-168 spec lists standard CSS class names for use within portlets Adhering to these names is suggested. uPortal will most likely adopt these standards See Appendix C of the JSR-168 spec

38. Request Attributes Request attributes can be used to send data to JSPs or other rendering technology: request.setAttribute(“name”, “Matt”); In the JSP this attribute can be retrieved with:

39. Response Properties Properties can be added to the PortletResponse: response.setProperty(“expiration-cache”, 0); The above is a useful property to set if there’s an exception thrown in the Portlet

40. What doesn’t uPortal implement? The portlet title, usually read from a parameter in portlet.xml or a resource bundle, is defined in the channel definitions Expiration cache has no meaning within uPortal - update: just added User elements accessed via a portlet must be defined both in portlet.xml and PersonDirs.xml

41. What does JSR-168 miss? Inter-portlet communication

42. “Trick” Inter-portlet communication A portlet application is a collection of individual portlets User the PortletSession available from a PortletRequest to transport attributes between portlets within a portlet application

43. Inter-portlet Communication Since the processAction method is guaranteed to run first, make any state changes there first: PortletSession ps = actionRequest.getPortletSession(); ps.setAttribute(“zip”, zip, PortletSession.APPLICATION_SCOPE); The SCOPE specified in the setAttribute method allows the attribute to be seen on either the Portlet level or the Portlet Application level

44. Inter-portlet Communication Attributes can be retrieved from the session in the “do” methods of a portlet: PortletSession ps = renderRequest.getPortletSession(); String zip = (String)ps.getAttribute(“zip”);

45. Inter-portlet Communication Caution! There’s no guarantee of execution sequence of doView, doEdit methods of the portlets on a portal page Some “do” methods may not be fired because of the caching paradigm being applied to that portlet There is no guarantee that a user might delete one essential part of a portlet app without removing the others, so something like Aggregated Layouts would have to be used

46. Resources