Kuiper: allowed window states and portlet modes partially checked.

[David Barral <da...@elrincondelprogramador.com>]

Hi.

We have noticed that the current Kuiper container needs an improve on
this subject.

As it is now, Kuiper only concers about the portal support of modes and
window states, leaving aside the user permissions, etc.
Currently, the portletWindow setState/Mode methods don't throw any 
Mode/State Exception and the ActionResponseImpl doesn't take care of the 
check either. The methods at PlutoEnvironment interface 
(isWindowStateAllowed and isPortletModeAllowed) are focused on the 
portal support and there has to be a per porlet policy as stated in the 
spec.

Our proposal to fix this:

1. Extend the PortletWindow interface. setWindowState and setPortletMode
throws WindowStateException and PortletModeException respectively.Two 
new methods: isPortletModeAllowed and isWindowStateAllowed. This way, 
the portal can decide whether the mode/state is allowed or not for the 
current portlet.

2. ActionResponseImpl already relies on PortletWindow to set state and
mode. No changes needed here.

3. ActionRequestImpl isWindowStateAllowed and isPortletModeAllowed will
rely on the PortletWindow instead of the PlutoEnvironment (as it is now,
this are the only ones to use the PlutoEnvironment. The rest already
delegates on the portlet window).

4. PlutoEnvironment isPortletModeAllowed and isWindowState allowed could
be deleted (they seem to be no longer needed). This checks are only
needed trhough ActionResponse and ActionRequest and that has already
been solved .

Any questions, ideas, comments, flaws?

This is what we are going to do until a better solution appears. If you
like it we'll be glad to send patches (just tell us the way you expect
them).

Regards.
David.

-- 
/**
  * David Barral
  * david@elrincondelprogramador.com
  */

Re: Kuiper: allowed window states and portlet modes partially checked.

["David H. DeWolf" <dd...@apache.org>]

Sounds great!. Patches would be most welcomed.  See: 
http://jakarta.apache.org/site/source.html#Patches for format.

David

David Barral wrote:

>
> Hi.
>
> We have noticed that the current Kuiper container needs an improve on
> this subject.
>
> As it is now, Kuiper only concers about the portal support of modes and
> window states, leaving aside the user permissions, etc.
> Currently, the portletWindow setState/Mode methods don't throw any 
> Mode/State Exception and the ActionResponseImpl doesn't take care of 
> the check either. The methods at PlutoEnvironment interface 
> (isWindowStateAllowed and isPortletModeAllowed) are focused on the 
> portal support and there has to be a per porlet policy as stated in 
> the spec.
>
> Our proposal to fix this:
>
> 1. Extend the PortletWindow interface. setWindowState and setPortletMode
> throws WindowStateException and PortletModeException respectively.Two 
> new methods: isPortletModeAllowed and isWindowStateAllowed. This way, 
> the portal can decide whether the mode/state is allowed or not for the 
> current portlet.
>
> 2. ActionResponseImpl already relies on PortletWindow to set state and
> mode. No changes needed here.
>
> 3. ActionRequestImpl isWindowStateAllowed and isPortletModeAllowed will
> rely on the PortletWindow instead of the PlutoEnvironment (as it is now,
> this are the only ones to use the PlutoEnvironment. The rest already
> delegates on the portlet window).
>
> 4. PlutoEnvironment isPortletModeAllowed and isWindowState allowed could
> be deleted (they seem to be no longer needed). This checks are only
> needed trhough ActionResponse and ActionRequest and that has already
> been solved .
>
> Any questions, ideas, comments, flaws?
>
> This is what we are going to do until a better solution appears. If you
> like it we'll be glad to send patches (just tell us the way you expect
> them).
>
> Regards.
> David.
>