So it sounds like #2 is generally considered the best approach. I'll be starting on the Pluto work later this week. I would be more than happy to have a hand with this or with any of the other open tasks for 3.0 http://www.ja-sig.org/issues/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&fixfor=10496&sorter/field=priority&sorter/order=DESC
I'll also be active in the IRC channel and having more people to bounce ideas off in that forum is always good. -Eric Elliot Metsger wrote: > I vote for #2. It seems extend the concept of portlets into the > framework where appropriate without the cost of code duplication. > > IPortletChannel as an interface is just a best practice which I > believe should be adhered to, at minimal cost (a thin layer of > abstraction). You may have an IPortletChannel which supports 286, one > supporting 168, and one which supports experimental or optional > features such as ajax, or perhaps a widget (google, yahoo) adapter. > > Elliot > > Eric Dalquist wrote: >> 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
