Pre-conference seminar from the March 2010, Jasig (www.jasig.org) conference in San Diego, CA. Additional presentation materials are available at the following page - http://www.ja-sig.org/wiki/display/JCON/JSR+286+Seminar+March+2010

1. Developing JSR 286 Portlets Cris J. Holdorph Unicon, Inc. JA-SIG Conference 7 March 2010 © Copyright Unicon, Inc., 2009. Some rights reserved. This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/us/

3. JSR 286 Major Changes

4. JSR 286 Minor Changes

5. Questions and Answers Special thanks to John Lewis from Unicon for helping to prepare this material.

6. Portlet Specs & Features

8. Led by Sun and IBM

9. Started: 29 January 2002

10. Released: 27 October 2003

11. Reference Implementation: Apache Pluto

12. Interoperability between Portlets / Portals

13. Set of APIs defining Portlets

14. Linked to WSRP 1.0 Specification

17. Released: 12 June 2008

18. TCK Complete

19. Reference Implementation (Pluto 2.0)

20. Linked to WSRP 2.0 Specification

22. Portlet URLs (Render URL, Action URL)

23. Portlet Mode (View, Edit, Help)

24. Window States (Normal, Maximize, Minimize)

25. Render Parameters

26. Portlet Preferences

27. Portlet Session

30. Public Render Parameters

31. Resource Serving

32. Portlet Filters

33. Caching Changes

35. Namespacing

36. Lifecycle Phase Request Attribute

37. RENDER_HEADERS Sub-phase

38. Portlet Cookies

39. Setting Markup Head Elements

41. Portlet Tag Library Changes

42. Additional CSS Classes

43. Portlet Request Dispatcher Changes

44. Portlet Resource Bundle Changes

45. Portlet Container Runtime Options

46. Action-Scoped Request Attributes

48. Window States

49. Portlet Preferences

50. Portlet Security

51. User Information

55. mvn clean install cargo:redeploy

56. Portlet Events

59. Event Phase – called on as many portlet windows as necessary

61. Diagram from Java ™ Portlet Specification, Version 2.0

64. processEvent is similar to processAction for copying renderParameters

68. After event definition, each portlet must declare what events it will publish or receive

69. Portal-defined events do not have to be defined in portlet.xml

71. Receiving events can end with a * wildcard

72. Can declare default-event-namespace in portlet.xml and just use local names

74. JAXB is necessary for interoperability with WSRP events

75. Implementing event payload class must be Serializable and annotated with JAXB annotations

77. Modify the CensusView Portlet to listen for events and track / show the data it receives

79. New event

82. Add new processEvent method

83. (Collect only) create event in processAction method mvn clean install cargo:deploy mvn clean install cargo:redeploy mvn eclipse:clean eclipse:eclipse

84. Public Render Parameters

88. A portal can decide which public render parameters will be shared by which portlets

91. Modify portlet to participate in the public render parameter

92. Resource Serving

95. Not guaranteed to go through Portal

96. Will not have portal context available

99. OutputStream

101. Portlet should not use HTTP GET for state change use HTTP POST/PUT/DELETE instead

103. ResourceURL only valid if a Portlet implements ResourceServingPortlet

104. Does not cause processAction to be invoked

105. Cannot change Portlet Mode or Window State

106. All current render parameters will be included

107. New parameters set do not become render parameters

109. PORTLET – URL needs portlet state (render parameters, portlet mode, and window state), but does not need the state of the rest of the page

112. Full access to HTTP headers (can set on response as well)

113. HTTP Method of the request

114. The Resource ID set on the Resource URL (if any)

115. The ETAG for cache validation

119. Create a resourceURL

121. Portlet Filters

123. Modify request data by wrapping request

124. Modify response data by wrapping response

125. Intercept invocation of a portlet before and after it is called

126. Filters may be chained

128. Must provide a public no-arg constructor

129. init() method will be called on all Filters before being called on any Portlets

130. destroy() will be called if Filter is removed from service

131. doFilter() method called if processAction() , processEvent() , render() , or serveResource() would be called on Filtered Portlet

133. <filter-mapping> element must specify the applicable portlets

134. Restrict to specific lifecycle methods using the <lifecycle> element in <filter-mapping>

135. Order in portlet.xml matters for multiple filters of the same portlet

136. Portlet containers are expected/allowed to cache the “filter chain”

138. EventRequestWrapper EventResponseWrapper

139. RenderRequestWrapper RenderResponseWrapper

140. ResourceRequestWrapper ResourceResponseWrapper

142. Action

143. Event

147. Track counts

149. Modify list.jsp to display values

150. Portlet Caching

155. expiration-time and cache-scope can be changed programmatically

157. New render/resource requests will only be called after expiration-time is reached

158. New request will be sent the ETAG

159. Portlet should examine it and determine if cache is still good – if so, set a new expiration-time and do not render

160. Must set the ETAG , expiration time, and caching scope before writing any output

162. Extra Credit: Modify the CensusView Portlet to use Validation Based Caching

163. JSR 286 Minor Changes

166. Portlet Definition : Publish time information

167. Portlet Entity : Subscribe time information

170. Provides a unique value for the current Portlet Window

171. Value may be used to prefix Javascript functions / variables or other items within a portal page that must be unique

172. Will return the same value for the lifetime of the Portlet Window

174. EVENT_PHASE = EventRequest

175. RENDER_PHASE = RenderRequest

178. Should be used when setting headers, cookies, the title, or next portlet modes

180. RENDER_MARKUP on the second call, so now render the actual markup

182. These cookies may be stored by the Portal and may not actually reach the client

183. Cookies set in the response of one phase will be available in subsequent phases (e.g. a cookie set in the action phase will be available during the render phase)

185. Provided DOM element should be added to the markup <head> section of the response to the client

186. Support for this property is optional – verify via the MARKUP_HEAD_ELEMENT_SUPPORT property on the PortalContext

187. For a Render Response, should be done in RENDER_HEADERS sub-phase

189. Portals should limit available navigation controls accordingly

190. To ensure this works in all portals, set them during the RENDER_HEADERS subphase

192. Provides callbacks for all portlet URL types

193. URL generation can be intercepted and modified

194. Apply cross-cutting concerns

197. All non-render lifecycle methods will not be allowed to be write to any output stream

198. PortletRequestDispatcher now has both an include() and a forward() method

199. Portlet Request Dispatchers must follow any Servlet Filters set up

202. Custom portlet modes and window states

203. Event definitions

204. User attributes

206. Defined at portlet application level or the portlet level

207. Use <container-runtime-option> element

209. javax.portlet.renderHeaders

210. javax.portlet.includedPortletSessionScope

211. javax.portlet.actionScopedRequestAttributes

213. Request parameters only handle strings

214. Only option is to park it in the Session

216. Action scope ID Render param “javax.portlet.as”

217. Can cache multiple scopes so back button will work for multiple actions

219. Existing namespace tag required to match the value of PortletResponse.getNamespace()

220. New copyCurrentRenderParameters attribute on Action and Render URLs (default: false)

221. New escapeXML attribute on Action, Render, and Resource URLs (default: true)

222. New property tag for use in Action, Render, and Resource URLs to set request properties

223. defineObjects tag now includes all new request/response objects and access to PortletSession and PortletPreferences

225. Some additional Forms and Menus styles have been added

226. Includes examples of how the Forms and Menus styles are intended to be used

227. Still pretty weak. Would be better if portals had better implementations and portlet developers committed to using them.

228. Resources

230. Questions & Answers Cris J. Holdorph Software Architect Unicon, Inc. [email_address] www.unicon.net