Re: [jira] Created: (PLUTO-328) Add support for a callback right before Render and Action in PortletServlet

[Eric Dalquist]

Note what uP3 does. We have a custom impl for RenderRequest and ActionRequest that we provide to Pluto. The current use is this request watches for a portlet trying to access the USER_INFO Map and we actually do a DAO call in the *Request object. We also provide a custom PortletPreferences impl via these objects since we have a fairly complex prefs hierarchy that requires a custom implementation.

-Eric


Charles Severance wrote:

Are there still things that you couldn't do with custom request objects that you need a listener for? Not saying it isn't a good idea, sounds like a neat hook, just not sure it actually needed or more useful than just having custom request objects.

I would also say one more thing about Sakai's implementation. Just using Sakai's request filter would not work in a portlet environment. Sakai's request filter is the complete equivalent of PortletServlet and handles the protocol between Sakai's portal re-dispatch and Sakai's tool run-time.

/Chuck

On Mar 4, 2007, at 2:06 PM, Elliot Metsger wrote:

It is completely parallel to the container doing the re-dispatch and sending stuff to PortletServlet. So I can't just add Sakai's request filter to the web.xml for a portlet - because Sakai is not doing the redispatch for portlets - only Sakai tools.

> In Sakai's case the use case is that we need to put a few items
> (context) into thread local on every request so that the entire suite
> of Sakai APIs works in portlets.






Elliot

When you say "entire suite of Sakai APIs work in portlets" do you mean that the portlet will be able to invoke a Sakai API directly in the body of a doView() or processAction()? If that is the case then you have already lost compatibility right? In that I can't take the same war file and deploy it in Jetspeed or uPortal.

smime.p7s
Description: S/MIME Cryptographic Signature