Implementing both Interfaces in one Class is, in my opinion, certainly not what was intended by the JSR168 group. There's a reason for having two Interfaces: so we can distinguish them.
Since both Interfaces are implemented in the same class, you should be able to do setRenderParameter during the render phase. Since you can only call setRenderParameter in the action phase, that class should throw an Exception or something. So that could be a way to determine in which phase we are and thus, if we're working with an Action- or a RenderRequest... But in the end, the above is only an ugly workaround and I think V2.0 of the Portlet Spec should clarify this issue. Either by prohibiting the implementation of both Interfaces in the same class or by adding a method getPhase to the PortletRequest Interface. I think the getPhase method would be a pretty nice thing because you can then get rid of all these instanceof statements and people could still implement both Interfaces in one class. Just some random thoughts... Patrick 2006/8/18, John Lewis <[EMAIL PROTECTED]>:
I'd like to get an opinion from the Pluto developer community on an issue that has come up with Spring Portlet MVC. 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. Some other frameworks also use this technique, such as the FacesPortlet and StrutsPortlet classes in the Apache Portal Bridges project and the PortletFileUploadInterceptor class in BEKK's PortletWork project. In JSF itself, the only way to retrieve the PortletRequest is via the ExternalContext.getRequest method, which returns an Object. The javadoc for this method states that in a portlet this method returns "the current request's javax.portlet.PortletRequest instance, which will be either an ActionRequest or a RenderRequest depending upon when this method is called." In most portals all this is fine since ActionRequest and RenderRequest are implemented as subclasses of an implementation of PortletRequest. We've now run across a JSR-168 portal (that has passed the TCK) where the ActionRequest and RenderRequest interfaces are both implemented in the same class and that class is used for all PortletRequest objects. So anywhere that we test the PortletRequest using instanceof, the result is always true regardless of which request type it really represents. Clearly the TCK does not test this issue and the JSR-168 spec does not include a prohibition on implementing both interfaces in the same class. However, it does seem to be a common assumption that a given request object will only implement one of the two interfaces. Can anyone suggest a better way to detect what kind of request is being processed when working with a PortletRequest? 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? Thanks in advance for your opinions on this topic. John Lewis
-- "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams
