[
https://issues.apache.org/jira/browse/PLUTO-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478239
]
David DeWolf commented on PLUTO-328:
------------------------------------
I like this. Thanks for the patch. I'm going to make two changes:
1) Use an event object to encapsulate event info. This will allow us to more
easily provide backwards compatibility as we add additional methods (for
instance when we need to include eventing invocations in 286). It will also
allow portals to use the same listener method for multiple types if they desire.
2) Revert back to PortalAdministrationService because this talks about WHAT it
does rather than HOW it does it. At some point I wouldn't be shocked if we
don't have a Servlet for invocation but have a Filter or perhaps even another
method that doesn't use cross context dispatching (way in the future, don't get
excited). This will prevent us from having to rename these in those situations.
> 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.1
> Reporter: Charles Severance
> Assigned To: David DeWolf
> Priority: Minor
> Fix For: 1.1.2
>
> Attachments: pluto-csev-patch-PLUTO-328.txt
>
>
> 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.
