Carsten Ziegeler wrote:
Hi,
while continuing to embed Pluto I'm not wondering about the
FilterManager interface which has three methods that look nearly the
same apart from the portlet parameter.
Now, I guess the idea behind it, is that one is sure that for example
event filters are only applied to EventPortlet instances - and the same
for resource portlets. But - if a portlet is not an EventPortlet or
ResourcePortlet - shouldn't the filters be ignored completely?
Hmm, we might need to review the spec on this again.
I'm not sure but it could be that even if a portlet doesn't implement EventPortlet, the filter(s) might be expected to be invoked
nonetheless. Pluto PortletServlet "injects" no-op EventPortlet/ResourceServingPortlet instances for that purpose, while in Jetspeed we
always wrap a portlet in a PortletInstance class implementing all interfaces.
The other thing is, if we have different methods, I think we should
change the types of the request and response parameters accordingly and
then add for each phase an own method (so separate between render and
action).
I think we should do one or the other (one or four methods) but not such
a mix.
I would prefer a single method.
Looking a bit deeper into the FilterManagerImpl, the invoked FilterChain expects strongly typed request/response instances (e.g. 4 methods)
too, and that is a spec API.
Therefore I would prefer aligning with the spec in this regard, so using 4
methods instead of 1.
Ate
WDYT?
Carsten
