David Sean Taylor <david <at> bluesunrise.com> writes: > > Frank Villarreal wrote: > > >>We correctly keep the render parameters *until* an action on the > >>targeted portlet is invoked. At that point the render parameters are > >>cleared for the targeted portlet (only). > > > > > > Ahhh, so it is by design (of the portlet spec). Hmmm ... am I alone in the > > "portal/portlet" community in feeling that this behaviour seems > > counter-intuitive for a web site?!? By "storing" the render parameters > > until another action is called, you're basically duplicating the > > functionallity of session variables, no? IMHO navigating off a page should > > be another use-case where render-parameters should be cleared. This IS how > > most well-designed web sites behave anyway ... at least in my experience. > > How else would a user "get back" to the "top" of a portlet that is > > multi-layered (many views) without being able to click the portal menu that > > got them to the portlet in the first place? Just my 2 cents. > > > > The parameters are lost if you navigate to another page > But as long as you stay on the same page, they are posted back to your > portlet. It gives you more possibilities for keeping state in the URL > instead of using the session >
An excerpt from the portal spec: ------------------------------------------------------ PLT.12.2.3 Render Parameters Using the setRenderParameter and setRenderParameters methods of the ActionResponse interface portlets may set render parameters during an action request. A call to any of the setRenderParameter methods must replace any parameter with the same name previously set. These parameters will be used in all subsequent render requests until a new client request targets the portlet. If no render parameters are setduring the processAction invocation, the render request must not contain any request parameters. ------------------------------------------------------ I guess the question is does the re-calling of a portal page (HTTP GET to a PSML page) constitute a client request targeting a portlet within it. My interpretation would be no. Only portal links that directly target a portlet would qualify. Thus, I would think that the correct behaviour would be to *keep* the render parameters even if you navigate away from the page and then back again. I suppose it may seem somewhat redundant with session attributes, but these are parameters that apply strictly to the render phase of a given portlet instance for a given user/client. These are the parameters that allow a client to put a portlet into a given state and be assured that it stays that way until the user does something to alter it's state. I think that the portal/portlet model is a bit of a paradigm shift when compared to the traditional servlet model. It is necessary because of the nature of a portal page in terms of aggregation and the sharing of a single request/response for multiple applications. I think that this is what is perhaps throwing some developers off as they get used to the new model. Anyway, just my opinion, but I think that some clarification is needed around when render parameters should indeed be cleared. aaron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
