Jacek Wiślicki <jacek.wislicki <at> gmail.com> writes: > > Wiadomosc od Michael Gustav Simon z 2006-02-08 18:04 brzmiala: > > > Hello j2-community, > > i have a question about the never ending http stateless problem. > > How can I prevent the right state, if an user uses the browser back- > > or forward button? > > > > Example: > > If I set a portlet in the edit mode, use the back button and after > > reload the page the portlet is in the edit mode again! > The portlet rememners its state/mode when you move between different > portal pages. Is it wrong? >
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? aaron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
