I have to correct myself. The dispatcher extends the GenericPortlet
class, but it overrides the render method because of the specialized
mode handling. But the effect is still the same, the window state
logic in doDispatch is not invoked.
Sorry for the confusion.
Nils-H
On 6/26/07, Nils-Helge Garli <[EMAIL PROTECTED]> wrote:
All portlets are responsible for what to render in the different
window states, even when caching is enabled, if the portlet is the
"target" of a user interaction (PLT.18.1 in the spec). But usually
when creating portlets, you extend the GenericPortlet class, which has
built in logic for skipping rendering in the "doDispatch" method when
the window state is minimized. Quote from the javadoc for
GenericPortlet:
"If the window state of this portlet is minimized, this method does
not invoke any of the portlet mode rendering methods."
The Jsr168Dispatcher in Struts 2 does not extend GenericPortlet (it
just implements the Portlet interface, since the handling of modes is
a bit different from a "regular" portlet), so this logic is missing.
This means, that for now, the responsibility of what is rendered in
the minimized state is up to the developer.
I'll create an improvment request in the JIRA for adding default
window state handling to the Struts 2 portlet dispatcher.
For now, a workaround would be to subclass the Jsr168Dispatcher (or
modify it directly) and in the render method, do something like
if(!request.getWindowState().equals(WindowState.MINIMIZED)) {
super.render(request, response);
}
Nils-H
On 6/26/07, tom tom <[EMAIL PROTECTED]> wrote:
>
> > "When a portlet is in MINIMIZED window state, the
> > portlet should only render
> > minimal output or no output at all."
>
> Ealier we were using struts-bridge for portlet
> development, there it was showing no output for the
> MINIMIZED window state, also I have seen lot of other
> portlet development strategies where it shows nothing
> for the minimized window state.
>
> > As I interpret this, it's the responsibility of the
> > portlet to display the
> > correct content. So you need to do some checking for
> > the window state and
> > take according action in your portlet.
>
> I DONT THINK this is possible, The reason is as
> follows.
>
> In S2 when I submit a form (not a HREF) it goes to an
> action and there after forward to a JSP, Now being in
> the same page if I switch between modes, it does not
> go the action class but shows the content probably
> from cache or already rendered content, Due to this
> reason how can I check for the Window State in the
> corresponding action class.
>
>
>
>
>
> >
> > However, there wasn't much information about the
> > minimized window state in
> > the spec. I couldn't find any description of the
> > contract between the portal
> > server's "window buttons" and the window states, so
> > there might be different
> > behaviour from server to server.
>
> We have different portlet development strategies
> working fine with uPortal, hence this is nothing to do
> with the uPortal or any other portal container.
>
>
>
> Please let me know if any way around for this.
> This should be a common problem to anyone, Can we
> enforce it to hit the action class for each switch
> between windows states so that in the portet we can do
> something.
>
> Thanks
>
>
>
>
>
>
>
____________________________________________________________________________________
> Got a little couch potato?
> Check out fun summer activities for kids.
>
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
