Re: [uportal-dev] Pluto 1.1 integration design

[Andrew Petro]

Eric, I strongly favor #2, retaining portlet-adapter-as-an-implementation-of-a-channel-API and making this an easier pill to swallow by introducing even more powerful (IPortletChannel) interfaces.  There's a tremendous amount of machinery re-use gained from the CPortletAdapter being "just another IChannel" in appropriate respects -- worker thread dispatching, timeout support, error channel replacement support, so forth.  I don't see any reason not to introduce new IBetterThanChannel APIs to implement better support for portlet adapters -- those IBetterThanChannels can be supported alongside IChannel, which seems to me to get all the value of what is meant by supporting portlets "as first class citizens" with less apocalypse.  There are some things that Portlets do better than channels.  As a trivial example: On sober second thought, help, about, and edit are better represented as modes than as events.  There's nothing stopping uPortal from evolving IChannel-ish-APIs towards this better approach -- in reality the number of implementations of receiving the Edit, About, and Help events out there in the wild are small and the effort to refactor towards an IBetterChannel API to take advantage of that sort of modeling as we incrementally improve those channels is modest. It's the duplication of code spectre that pushes me towards #2.  Rendering a channel and rendering a portlet share more than they differ. I think we should be very open to powerful innovations to make JSR-168 and JSR-286 support really good --- it's been commented many times that uPortal should be smarter about reading portlet preferences declared in portlet.xml and making them available in the channel publishing workflow in a more natural way.  Absolutely!  This can be part of a re-visitation of the way that Channel Manager workflow is currently implemented.  Right now it's really good at what it does, and that's a good thing, cuz it's really hard to change.  (Massive XSLT, anyone?)  A more pluggable Channel Manager and way to implement even better publication workflows would be a good thing.  One important application of this, but by no means the only one, would be to implement better portlet publication support. Better UIs and user experiences for publishing portlets does not necessitate abandoning the concept of an adapter class. Having an API for the adapter class and an implementation of that API has nice properties in the ability to introduce alternative implementations.  Is Sun's portlet container implementation better than Pluto's in some way?  I don't know, but I prefer an architecture that makes it easy to contemplate introducing an alternative implementation of the adapter and having that bake-off.  Do you need your portlet adapter to introduce CAS proxy tickets in particular places, say as special request parameters?  We've seen a demonstrated need for this already.  Would you sleep easier at night if only the portlets that actually need the end user's password have them available to them, rather than the adapter always passing the password along when it is available?  I just might. Conceivably, we'd have a different adapter implementation for JSR-168 and JSR-286, and yet another for the JSR-286-plus-non-standard-but-widely-adopted-AJAXY-stuff. Note that there's already a marker interface for IChannels wishing to be treated specially as portlet adapters.  I introduced this once upon a time when trying to remove classname-specific checking in channel rendering.  That might be something to evolve into the new interface. Andrew 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 -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev