You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Eric Dalquist <er...@doit.wisc.edu> on 2008/07/16 16:35:43 UTC

Re: Refactor request attribute handling (PLUTO-489)

I just wanted to check if anyone had any comments on this before I went 
ahead and committed the changes this week.

-Eric

Eric Dalquist wrote:
> I created https://issues.apache.org/jira/browse/PLUTO-489 this morning 
> along with a patch that creates a new optional service for handling of 
> request attributes. PortletRequestImpl is modified to delegate all 
> four request attribute methods (get, names, set, remove) to this 
> interface, included in the move is the createUserInfoMap method from 
> PortletRequestImpl.
>
> The motivation behind the change is to allow a portal to have 
> influence on the handling of request attributes and filtering of the 
> USER_INFO Map without having to re-implement the entire PortletRequest 
> hierarchy.
>
> The patch attached in Jira is functionally identical to the existing 
> code. Current users of Pluto that use their own direct implementations 
> of the OptionalContainerServices interface will have to implement a 
> new method from that interface when upgrading. To retain existing 
> behavior that implementation would simply be to return the provided 
> DefaultRequestAttributeService.
>
> I'd like to propose this change for 1.1.6 and 2.0.0. I'm going to hold 
> off on any commits until I hear back on this list.
>
> -Eric