Wiadomosc od Aaron Evans z 2006-02-08 19:10 brzmiala:
This relates to our discussion around render parameters (see thread "How to
clear RenderParameters set in action ?"). In that discussion, users found it
strange that if a portlet had certain render parameters set, then if the user
navigates to a different portal page and then back again, the render parameters
were still set.
To me it makes perfect sense. Say I have a render parameter called FLASH_MODE
and the values can be true or false indicating that the portlet will be
rendered using flash elements. I provide a linke that the user can use
to turn off flash. Just because they navigate away from the page and then
come back does not mean I am going to show them the flash view again. However
this example might instead be considered a user preference, but whatever. Even
then, I might use the user preference to determine a render parameter.
This behaviour is correct as far as the portlet spec goes. Render parameters
retain their values until another action URL targetting the same portlet is
invoked.
However, jetspeed provides a way via configuration to alter this behaviour.
The difference here is that we are talking about a portlet mode rather than
a render parameter.
So the question becomes, should portlet modes and window states behave like
render parameters (ie. keep their states until another action URL targetting
the given portlet is invoked). Intuition tells me yes. The fact that they
are a "state" and "mode" also tells me yes.
However, I have not found anything in the portlet spec (although I haven't
looked that thoroughly) to suggest that they must behave in this way. If
someone else finds a definitive answer one way or the other, please speak up.
I did find this (PLT.12.2.2 Portlet Modes and Window State Changes):
"Portlets cannot assume that subsequent renders will be called in the set
portlet mode or window state as the portal/portlet-container could override
these changes."
Sounds pretty ambiguous if you ask me.
Like render parameters you of course wouldn't want the window state or mode to
change on subsequent render requests while on the same page. Another reason
why I think they would behave in the same manner.
However, *unlike* render parameters, a window state or portlet mode doesn't
get "cleared" like render parameters do if a portlet action URL is called. But
that only tells me that they hold their state to a greater extent than render
parameters.
Thoughts?
I gave it a look. The problem becomes quite dangerous if a user logs-out
and leaves a browser window opened (tested with IE, Firefox and Opera).
Using history back retrieves all the previous pages. For example, if one
with some admin/manager priviledges leaves some fragment in edit mode
befor logging-out, the edition is still possible... Also access to all
administrative fragments is possible, provided their pages are in the
history (their actions rather wouldn't work, but the data is viewable).
I'll try to see if the problem can be resolved on HTTP level, but it's
hard to say when.
--
pozdrawiam,
Jacek Wislicki
[EMAIL PROTECTED]
tel.: +48 502 408 444
gg: 2540358
skype: jacek_wislicki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
