>
> J.Enrique Ruiz wrote:
> > Hi Rainer,
> >
> > I think that it isn't a feature :) The specification says:
> [...]
> > As you are using
> "request.getPortletSession().getAttribute("..")" and
> > the API says that this method returns the object with the
> specified name
> > for the |PORTLET_SCOPE, it could be there is a bug on your portlet
> > container.|
>
> No, everything works as expected for the result stored in
> session. It's
> only the result propageted as request attribute in
> request.setAttribute(MODEL_AND_VIEW, result);
> which is picked up by the render action of every portlet window.
>
That is definitely a bug. The Portal should handle keeping the request
attributes separate for each instance of the portlet on the page, so it is
probably a bug in the Portal. It is possible that we are doing something
weird in Spring that breaks this however.
What Portal are you using?
> So everything would be fine if we always use the portlet session for
> result propagation, but I don't want to enforce the usage of
> a session
> just for result propagation.
> Maybe a compromise would be to rely solely on the session if
> 'storeResultInSession' is true (since than a session is used
> anyway). In
> this case the multiple window problem could be avoided. If
> you don't use
> a session, the portlet window is refreshed to the initial form view
> anyway, so there is not much point in creating multiple
> portlet windows
> anyway.
>
I've had to use the portlet-session-for-communication hack before, and I
really don't like it, although sometimes it does seem to be required.
The rest of the changes look very useful.
Nick
|
