Very funny actually but completely different use case, right? There wasn't really any functional benefit from IMultithreaded but your adapter handles all the IChannel lifecycle calls and translates to alternate implementation. Looks neat to me. Susan
Eric Dalquist wrote: > Thanks for the affirmation Susan. > > Following along this thread I've been trying to figure out how to do a > 'Spring configured IChannel'. I've worked out the following idea and > I'd like to get some feedback on it. > > The core of the idea is a CSpringAdaptor channel, this would get > access to the WebApplicationContext in the setStaticData method > (possibly add the uPortal context as a property of the > ChannelStaticData) and use a channel parameter to pull out a named > bean to delegate to. A new interface would be created for delegating > to that can handle being accessed as a singleton. The chain of method > calls representing each step in a channel lifecycle would be condensed > into a method on this interface and the adaptor would handle calling > these methods at the appropriate time with the appropriate information. > > Here is a very rough cut at doing this, the CSpringPortletAdaptor > implements all the interfaces a portlet adaptor channel will need to > and does the bean lookup and lifecycle method delegation. The > ISpringPortletChannel provides the basis for the singleton channel > instances. > > http://developer.ja-sig.org/source/browse/jasigsvn/up2/branches/working-pluto/uportal-impl/src/main/java/org/jasig/portal/channels/portlet/CSpringPortletAdaptor.java?r=42659 > http://developer.ja-sig.org/source/browse/jasigsvn/up2/branches/working-pluto/uportal-impl/src/main/java/org/jasig/portal/channels/portlet/ISpringPortletChannel.java?r=42659 > > This is eerily similar to IMultithreaded which is why I want to bring > it up here. In my view the major benefits are a spring configurable > 'channel' and singleton coding styles. Since the actual adaptor > IChannel is doing the little bit of work required in managing the > mapping of IChannel instance data to the singleton it keeps that code > out of the rest of the framework (what IMultithreaded did). > > -Eric > > Susan Bramhall wrote: >> Congratulations on becoming a channel author Eric. ;-) I believe >> you have the order correct for IChannel anyway. The only reason I >> can think of to save the ChannelRuntimeData and >> PortalControlStructures values across requests would be if they were >> going to have an effect on isCacheValid. For example, returning true >> to skip rendering when values have not changed. Not sure if this is >> ever applicable to your case though. >> Susan >> >> Eric Dalquist wrote: >>> Believe it or not the new portlet adapter channel for pluto 1.1 will >>> be the first channel I've ever written. To that end I want to make >>> sure I have some things figured out correctly. >>> >>> The channel implements the IPortletAdapter, ICharacterChannel, >>> IPrivilegedChannel and ICacheable interfaces. From what I've seen >>> the following method call ordering is what I should expect for each >>> type of event targeting a channel: >>> >>> init >>> setStaticData >>> >>> render >>> setPortalControlStructures >>> setRuntimeData >>> generateKey >>> isCacheValid >>> renderCharacters >>> >>> action //This doesn't exist yet but will be added to the >>> IPortletAdapter interface >>> setPortalControlStructures >>> setRuntimeData >>> doAction >>> >>> event >>> setPortalControlStructures //This call doesn't happen before >>> receiveEvent currently but the change will be made in the framework >>> to ensure it does >>> receiveEvent >>> >>> >>> If those are correct, does it seem valid to clear out references to >>> the ChannelRuntimeData and PortalControlStructures at the end of the >>> renderCharacters, doAction and receiveEvent methods? >>> >>> Thanks, >>> -Eric >> -- It's no use trying to be clever--we are all clever here; just try to be kind--a little kind. -- F.J. Foakes Jackson -- 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
