Why has the FilterManager three methods?

[cziegeler]

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?

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.

WDYT?
Carsten
--
Carsten Ziegeler
cziegeler@...

[cziegeler]

Carsten Ziegeler wrote:
> Hi,
>
> while continuing to embed Pluto I'm not wondering about the
                                     ^now^

> 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?
>
> 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.
>
> WDYT?
> Carsten

--
Carsten Ziegeler
cziegeler@...

[Ate Douma]

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

[cziegeler]

Ate Douma wrote:
> 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.
I scanned the section about the filters in the spec and it says that the
last component in the chain is the receiving portlet. Now, if an event
is sent and a portlet is not implementing the EventPortlet interface,
the portlet never gets the event; therefore filters can never be applied.
At least this is how I read the spec :)

> 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.
Yes, ok, so if noone objects, I'll change the interface to have four
methods.

Carsten

--
Carsten Ziegeler
cziegeler@...