Two (and a half) Proposals to Extend Portlet Modes Craig Doremus October 19, 2006

Preconditions I do not know what I'm talking about - I'm the guy who suggested that remotable portlets be optional in JSR- 286 at the first F2F meeting - What do you expect from somebody who got up at 3 am all week? - Some of these ideas are not fully baked ● Try not to all talk at the same time - Give someone another chance, Mike ● Some of my best friends are WSRP portlet developers - But we're no longer in WSRP-land here

Craig's Skewed View of a Portlet Mode ● A portlet mode is a loosely-coupled unit of portlet function – portlet developer's perspective ● A portlet mode is a navigational convenience – portal user's perspective ● Who's in control here (with modes)? a. Portlet 1. Controls function – what happens when a mode is rendered depends on the portlet implementation b. Portal 1. Renders appropriate window controls for supported modes 2. Controls security – edit or admin (config) mode 3. Controls screen real estate (window state) – print or preview mode JSR-168 déjà vu?

Imagine a world where a developer has full control over a portlet mode's function? ● Setting security aside (for now) - And conceding that the portal is in charge of window controls and window state ● We'll call this world an 'extension' to keep the WSRP folks happy (for now) ● What if we define a custom mode by a method call? - Like we do with doView(), doEdit() and doHelp() ● This opens up custom modes to anything the developer can think of - A scary thought!

@CustomModeHandler(mode="edit content", content-type="text/html") public void doHtmlEditContent(RenderRequest req, RenderResponse resp) {.....//do view mode logic and rendering here for text/html content", content-type="text/wml") public void doWmlEditContent(RenderRequest req, RenderResponse resp) {.....//do view mode logic and rendering here for text/wml } The content-type attribute is optional. In that case, all mime type renderings for a mode pass through the method. Method Annotation for a Custom Portlet Mode

Custom Mode Considerations ● Custom mode controls will be rendered as a drop-down or fly-out menu 1. Conserves screen real estate, which can be a premium for portlets ● Custom portlet modes will continue to be get/set as they are in JSR For custom modes, the method parameter will be annotation's mode attribute. ● Custom modes could be delegates for standard modes 1. Improves usability – e.g. Use a Customize Mode instead of Edit Mode ● Custom mode use cases are unlimited, but here are a couple of common ones: 1. Shopping cart portlet Shop/Continue Shopping Mode View Shopping Cart Mode Checkout Mode 2. Content management portlet: View Content Mode (could delegate to view mode) Edit Content Mode Approve Content Mode ● Usage of Custom Modes in this way promotes loose coupling in portlet design

Declarative Portlet Mode Security A contract between the developer and the portal administrator defined in portlet.xml ● User roles are either JEE roles or proprietary roles/groups defined in the portal implementation a. JEE role may be required if a portlet uses EJB/JSP/servlet with JEE security (jee attribute). ● Default is no portlet mode security (nothing in portlet.xml). ● This security model could be optional?In that case the administrator can override declarative security. a. Or we can be a hard ass and say that declarative security always wins ● If a user is in a role not allowed access to a specific mode, then the window control or menu to select that mode must be disabled or removed from the user interface. ● Declarative portlet mode security is applicable to all content types for a specific mode. ● Portlet mode security could work with both custom and standard modes except View mode (its up to you). ● PortletRequest.isUserInRole() can still be used inside the portlet for fine-grained security control. a. But the developer must keep in mind that the isUserInRole() call will never happen for a user restricted by declarative mode security. Using non-JEE roles/groups also complicates this issue.

..... text/html create content edit content approve content..... Creates portlet content create content Edits portlet content edit content Approves portlet content approve content..... create content content creator edit content content editor content approver approve content content approver Declarative Portlet Mode Security

..... create content content creator edit content content editor content approver approve content content approver..... Portlet.xml portlet-mode-security Element

Now for Something Completely Off-the-Wall! 1. Enable/disabling portlet mode controls in processAction() 1. Disable a specific mode: ActionResponse.enablePortletModeControl(“Whatever mode”, false) - What if you just called response.setPortletMode(“Whatever mode”) ? -- throw new StupidIdiotException() ?? 2. Setting initial portlet mode control content", content-type="text/html", initial-state=”disabled”) public void doHtmlEditContent(RenderRequest req, RenderResponse resp) {.....//do view mode logic and rendering here for text/html } 3. Used to assure that state is set before a mode is enabled. a. E.g. Disable the View Shopping Cart or Checkout Mode until at least one item is selected 4. How does it relate to Portlet Mode Security? - I'm going back to bed! You figure it out! (In other words, if you didn't like portlet mode handlers and portlet mode security, you really aren't going to like this)