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

["David DeWolf (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PLUTO-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David DeWolf updated PLUTO-328:
-------------------------------

    Fix Version/s:     (was: 1.1.1)
                   1.2.0
         Assignee: David DeWolf

> Add support for a callback right before Render and Action in PortletServlet
> ---------------------------------------------------------------------------
>
>                 Key: PLUTO-328
>                 URL: https://issues.apache.org/jira/browse/PLUTO-328
>             Project: Pluto
>          Issue Type: New Feature
>          Components: portlet container
>    Affects Versions: 1.1.0
>            Reporter: Charles Severance
>         Assigned To: David DeWolf
>            Priority: Minor
>             Fix For: 1.2.0
>
>
> Basically we need another Optional service that provides a user of Pluto's container (like Sakai) with the opportunity to adjust things *right* before Action and Render is called.
> 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.
> For Sakai tools, this is done with a Request Filter - but for Pluto I do not want to add anything like a filter because I want to maintain 100% binary compatibility of war files between Sakai and all other Pluto 1.1 based implementations - so for me an answer that says "just hack the web.xml and add your filter" is not acceptible.
> I am already working on this and have complete but untested code.  Once everything tests out, I will post a patch.  Here is the basic idea (imitating the ADMIN listener):
> +public interface PortletPrepareListener {
> +
> +    void preRender(PortletRequest request, PortletResponse response);
> +
> +    void preAction(PortletRequest request, PortletResponse response);
> +
> +}
> I use Exactly the same pattern as the ADMIN listener.  I decided one listener with two methods was better than two listeners.  
> And frankly - people smarter than me migh actually decide to refactor this and call our new friend the "PortletServletListener" and have three mentods (admin, preRender, and preAction).
> Once I hand in my patch - I am happt to see the refactor happen - based on what folks think.
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.