I'm not sure why your two actions can't extend a base action, but if
that's the real issue, it seems like you may have a modeling issue.
If nothing else, you could use composition instead of inheritence.
Anyways, I agree that the PortletWindow should be provided. I'm going
to deprecate the current method in favor of one that accepts both the
request and the window.
David
Eric Dalquist wrote:
That is a good point, and it isn't a big issue, more just annoying that
I have to duplicate code since I can't really extend PortletRequestImpl
and have both RenderRequestImpl and ActionRequestImpl use my one bit of
code.
-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
