One thing to consider, is a small group from within the 286 committee
are committed to AJAX 'read-write' support for Portlets. This was not
included with the spec. However, this group has all agreed to "do it
the same way". I only partially understand what idea they had (mainly
from JavaOne presentation), but it might be worth looking at this idea
in addition to 286 for consideration over which route is the best.
Beyond that....
At a framework level I don't see the value for an IPortletChannel
interface. We're still going to have the same situation where all
Portlets use one Adapter channel right? If there is only one
implementation of an interface, what value is it bringing? Maybe I'm
missing something. To me, option #2 is more just about continuing with
the PortletAdapterChannel concept or not.
My opinion on option #1 versus #2 versus #3, has more to do with what is
the likely difference at the "ui"/"system admin"/"portlet developer"
level. For example, I really dislike having Portlets forced into the
"Channel Manager" UI. Portlets don't have an "About" mode. It's not a
custom mode that uPortal supports either. Nearly all of Channel
Manager, having no concept of reading the portlet.xml, etc. If someone
was to explain to me, I could have a better Portlet
Deployment/Publication experience with one of these options over the
other, that's what I would choose.
My desire for improved Portlet support in uPortal is first and foremost,
support for JSR 286. Second, support for the "sub group's" AJAX
read-write unofficial 'add on' spec. Third, support for a better user
interface for deploying, publishing and subscribing to Portlets. So,
whichever option makes these things easier, is the one I'd vote for.
---- Cris J H
ps. I'll try to hunt down the speaker name who I heard about the
Portlet AJAX read-write 'add-on', and contact him off-list. Now that
the spec is complete, he should be willing to share at least a few
details. It's possible Chuck Severance might know as well.
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
