John,
I agree with Elliot's solution that some kind of request attribute which
is injected during the initial processAction or doRender invocation is
the way to go if you really need to determine the request type. This
will ensure the behavior no matter what implementation choice the portal
has made. This type of setup could be done in your
Dispatcher/FrameworkPortlet.
I know that many bridges use the instanceof operator, but I'm not sure
that means that it's right. To me, the implementation details of
weather or not the interfaces are implemented separately or not should
be left up to the portal implementer. I'm not convinced that the 168
group intended to imply that this separation should occur. Instead, my
guess is that the intention was to impose constraints as to what types
of processing could be done in each request cycle (without ignoring
compliance and casting to an implementation specific class), while still
allowing developers access to a common model between the two requests.
One reason that this portal vendor may have chosen to implement the
interfaces in the same class is that they do not use a
redirect-after-action approach. In this case, there would be no need to
construct seperate request objects for each RenderRequest. Instead,
they may want to leverage the existing PortletRequest (in this case the
existing ActionRequest) and not have to take care of copying/translating
render parameters to a new instance.
Hope that helps,
David
Elliot Metsger wrote:
Hi John,
John Lewis wrote:
In a few places in the framework, we have code that generally handles
PortletRequest objects, but then may need to do some special logic
depending on if it is an ActionRequest or RenderRequest. In those
cases, we test it with instanceof and proceed accordingly.
Whereabouts in Spring do you perform special logic? I saw this in
FrameworkPortlet's processAction method (but didn't look much further):
if (request instanceof ActionRequest) {
doActionService((ActionRequest) request,
(ActionResponse) response);
}
else {
doRenderService((RenderRequest) request,
(RenderResponse) response);
}
Could you add a parameter to processRequest(PortletRequest,
PortletResponse) which would indicate whether or not it was called
from processAction(ActionRequest, ActionResponse)?
<snip>
Can anyone suggest a better way to detect what kind of request is
being processed when working with a PortletRequest?
My suggestion would be to add a request attribute to the
PortletRequest in Spring's FrameworkPortlet that would indicate it is
an ActionRequest. Or, if the processAction method is the only place
where you perform special logic, modify the method to take a boolean
indicating whether or not it is an action.
Is the way that a lot of existing code is doing it reasonable and
should this portal look to change it's class structure? Should there
be an errata against the current spec about this issue? Should this
be clarified in the JSR-286 spec?
I agree that it is a common assumption and common practice to
implement ActionRequest and RenderRequest separately, and that the
instanceof idiom is common.
Hope this helps, keep up the good work on Spring Portlet - I've been
using it since the m2 days and it has really done wonders for me.
Best,
Elliot
Thanks in advance for your opinions on this topic.
John Lewis
