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
--
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
