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
