Not having cycles to code doesn't mean you shouldn't vote and I hope everyone contributes to the discussion here even if that is all they can do.
I would think #2 (my vote) this won't cause any pain to existing channels. I would opt for creating a new IPortletChannel interface that extends IChannel and add all the new functionality needed for a portlet (probably not much) to that interface. -Eric William G. Thompson, Jr. wrote: > 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 >> >> >> >> > > >
smime.p7s
Description: S/MIME Cryptographic Signature
