I stuck both Chris and Andrews replies below since it will be easier to reply to both at once.
All of the issues with the Channel Manager's handling of Portlets in the UI is due to the original approach of hiding everything portlet specific behind CPortletAdapter and making uPortal think of it as just another channel. The only approach that won't solve that is #3. I do agree that once the underpinnings are converted over to use Pluto 1.1 the next very important task is to fix all the UIs that deal with Portlets to make them work well. Not having to re-enter data that exists in the portlet.xml, removing channel specific concepts such as "About" and channel properties, having to just know the portlet definition ID. All of those things can and will be fixed once a more integrated portlet container is implemented and we don't shy away from propagating portlet concepts throughout the rest of the uPortal framework. As for why to do a specific IPortletChannel interface? Even if there is only one implementation (like there is with most of the interfaces in the portal) having the interface strongly defines the portlet specific APIs. Andrews suggestion of moving as many of the features as possible out into other IChannel extensions I think is a good one as well. This was already partially demonstrated with the IDynamicChannelTitleRenderer interface which provides dynamic title support but was never integrated back into CPortletAdapter. Defining missing features this way fits in with the channel concepts and allows for re-use of a lot of code while also ensuring we can fully support the needed features. The AJAX feature sounds interesting and it would be good to get a pointer on who to talk to about how this group is standardizing on it and what we can do to support that standardization as well. It sounds like we have 4 votes for option 2 so far. -Eric Cris J Holdorph wrote: > 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. Andrew Petro wrote: > 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 [email protected] as: [EMAIL > PROTECTED] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
