-Eric
David H. DeWolf wrote:
I'm not convinced that is what we want. Pluto should enforce the spec, as the container, and like the other services, only delegate when hooks are needed. I feel like delegating everything would be inconsistent with our approach in other services (for instance preferences, in which pluto does the checking of read-only prefs).I don't really see why this is an issue though, because you override the request objects anyways, right?David Eric Dalquist wrote:The UserInfoService is in 1.1.1 (which uP3 is now running on BTW, thanks all!) but there is some logic related to the USER_INFO Map that is in the RenderRequestImpl, because of how some of our domain object model work I need my own logic for USER_INFO handling and would rather Pluto completely delegate to this service instead of just partially delegate. Right now Pluto expects the UserInfoService to return all attributes for a user, the problem is in uP3 the list of user attributes is affected by the portlet the attributes are for.-Eric Charles Severance wrote:Eric - I think that this is there already (in 1.1.1). I attach our optional container services - note that the 1.1.1. stuff is commented out so my trunk works with 1.1.0./Chuck On Mar 5, 2007, at 12:40 PM, Eric Dalquist wrote:Actually, to expand on this. The default logic in PortletRequest.createUserInfoMap() doesn't mesh well with what uPortal needs to do. I can override the method but because of the class hierarchy I have to override it twice, once in a custom RenderRequest impl and once in a custom ActionRequest impl. Would it be possible to move all of this logic into an the optional UserInfoService? That would let me override it in one location for the container.-Eric Eric Dalquist wrote:Any reason why UserInfoService doesn't pass the PortletWindow in along with the request? I realize I can pass it as a request attribute or some such but it would seem to be a bit easier if it could be provided.-Eric
smime.p7s
Description: S/MIME Cryptographic Signature
