Since, I don't have cycles to contribute to the coding I'll refrain from voting...but all told option #2 sound like the best bet. One questions...could the changes for #2 be made in a way that would not cause major pain for existing Channels? ( I don't count recompiling a Channel to pick up some new interface as major pain. )
Bill On 10/5/07, Eric Dalquist <[EMAIL PROTECTED]> 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 > > > -- William G. Thompson, Jr. Associate Director - Architecture & Engineering Enterprise Systems and Services, Rutgers University voice: 732 445-5428 | fax: 732 445-5493 | [EMAIL PROTECTED] -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
