With the prerequisite work for upgrading the trunk to Pluto 1.1 complete I would like to start discussion around the appropriate approach for integrating Pluto and Portlets in uPortal.
The current approach for portlet integration is via CPortletAdapter, an IChannel that delegates to Pluto 1.0 for rendering a particular portlet. Part of the goal of this approach was to hide portlets as a concept from as much of the uPortal framework as possible. To that end there are many work-arounds such as specially prefixed channel parameters actually getting used as portlet preferences, bypassing the stock file-upload handling code for portlet specific requests and others. When thinking about how to re-work this integration to resolve some of these work-arounds and resolve some of the mismatches between the portlet and IChannel APIs there have been several ideas. 1. Make portlets 'first class citizens' that is create some interface parallel to IChannel that is specific to the portlet rendering life cycle. Adding this interface would require that the ChannelManager and associated rendering code be modified to deal with portlets specifically as well as CChannelManager to allow for publishing of portlets, and the Layout management code for subscribing to portlets, the list likely goes on. With this cursory overview the 'parallel to IChannel' approach doesn't seem feasible as far as amount of work involved or reasonable as far as amount of code that would be duplicated. 2. Follow the IChannel to Portlet adapter path but add portlet life cycle requirements and concepts to the IChannel interface or perhaps better a specific IPortletChannel interface. This approach would result in pushing portlet concepts into areas of the framework where there are currently workarounds to 'hide' these specifics but I think this is a good thing. CChannelManager would be updated to provide a more specific UI for portlet preferences, layout management information would be exposed to the IPortletChannel to fulfill some of the portlet API requirements. This approach will also easily provide for additional portlet life cycle methods such as the specifics of the event distribution phase by simply adding to the interface and adding specific support in the relevant rendering classes. 3. Follow the IChannel to Portlet adapter path and continue to try and hide as many portlet concepts from the rest of the portal as possible, This mimics how the adapter is implemented now and unless others have some good arguments for this approach I am advocating against it. As always, looking for thoughts, ideas and comments from everyone. -Eric
smime.p7s
Description: S/MIME Cryptographic Signature
