Re: [uportal-dev] Channel rendering cycle

[Eric Dalquist]

Thanks for the affirmation Susan.








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



-Eric

Susan Bramhall wrote:

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

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.

init
   setStaticData

render
   setPortalControlStructures
   setRuntimeData
   generateKey
   isCacheValid
   renderCharacters


   setPortalControlStructures
   setRuntimeData
   doAction

event

   receiveEvent




Thanks,
-Eric

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: action //This doesn't exist yet but will be added to the IPortletAdapter interface setPortalControlStructures //This call doesn't happen before receiveEvent currently but the change will be made in the framework to ensure it does 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?

smime.p7s
Description: S/MIME Cryptographic Signature