Thanks Aaron. I tried to use both SessionNavigationalState and PathNavigationalState and it seems didn't affect anything (Sure I did restart the server every time). Any more ideas ? Thanks Yiguang
-----Original Message----- From: Aaron Evans [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 31, 2006 9:27 AM To: Jetspeed Users List Subject: Re: jsf with portlet problem This sounds like that old discussion we had about render parameters being set in the action phase are kept for all subsequent renders until another action targetting that portlet is invoked (and this is what the spec calls for). Some folks didn't like this behaviour and so there are other "navigational state" configurations you can use. I can't be sure that is what is happening since I'm not sure of the details of the JSF-bridge implementation, but it sure sounds like the same thing. See the thread titled "How to clear RenderParameters set in action ?" on January 27th. Here is a quote from Ate summarizing the available configurations: +++++++++++++ To summarize: Jetspeed currently provides three implementations for encoding and storing portletwindow state and parameters: a) fully encoded on the url (like for instance Pluto does): use class org.apache.jetspeed.container.state.impl.PathNavigationalState b) only portletwindow state (window state and portlet mode) are saved in the session, parameters are encoded on the url: use class org.apache.jetspeed.container.state.impl.SessionNavigationalState c) state and parameters are saved in the session (the default): use class org.apache.jetspeed.container.state.impl.SessionFullNavigationalState ++++++++++++++++++ And details about configuration from David: ++++++++++++++++++ The default configuration stores render parameters state in the session. See portal-url-generation.xml. <!-- Navigation state we are currently using --> <bean id="NavigationalState" class="org.apache.jetspeed.container.state.impl.SessionFullNavigationalS tate" singleton="false" > <constructor-arg><ref bean="NavigationalStateCodec"/></constructor-arg> </bean> If you don't want to make render parameters stateful, use SessionNavigationalState instead: <!-- Navigation state we are currently using --> <bean id="NavigationalState" class="org.apache.jetspeed.container.state.impl.SessionNavigationalState " singleton="false" > <constructor-arg><ref bean="NavigationalStateCodec"/></constructor-arg> </bean> IF you want to store navigational state in the URL, change your spring configuration to: <!-- Navigation state we are currently using --> <bean id="NavigationalState" class="org.apache.jetspeed.container.state.impl.PathNavigationalState" singleton="false" > <constructor-arg><ref bean="NavigationalStateCodec"/></constructor-arg> </bean> finally, another Nav state impl available: PortletWindowRequestNavigationalState which also stores state in the server side and allows for optionally render parameters when synchronizes state /** * true if for a targeted PortletWindow using StateFullParameters the saved (in the session) render parameters * must be cleared when synchronizing the states. * Prevents the default behavior when using StateFullParameters to copy the parameters from the session * when no parameters are specified in the PortletURL. * Used if for the targeted PortletWindow no render parameters are specified. */ private boolean clearParameters; public void setClearParameters(boolean ignoreParameters) { this.clearParameters = ignoreParameters; } ++++++++++++++++++++++ HTH, aaron On 5/31/06, Hu, Yiguang <[EMAIL PROTECTED]> wrote: > Yes. Looks like it was reinvoking the portlet at the same place it left > off. So how could I goto the same start place (index.jsp) when I click > the same link http://localhost:8080/jetspeed/portal/home.psml every > time? > > Thanks > -----Original Message----- > From: Ralph Goers [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 31, 2006 12:37 AM > To: Jetspeed Users List > Subject: Re: jsf with portlet problem > > What makes you think it should restart? It sounds like you are > reinvoking the portlet at the same place it left off so it is going back > > there. > > Hu, Yiguang wrote: > > I run into a strange problem while trying to using jsf bridge. I have > > the following simple jsp pages, when it was first loaded by clicking > the > > psml that point to the index.jsp, I can see both the command button > and > > link from the index.jsp page. When I click either the button or link, > it > > goes to the second page (first.jsp) correctly. But when I click the > same > > psml link again, it goes directly to the page (first.jsp) instead of > the > > index.jsp. > > > > Any ideas? > > > > Thanks > > > > Yiguang > > > > Index.jsp > > > > <f:view> > > > > <h:form id="index" > > > > > <h:commandButton id="submit" action="first" value="Goto First" /> > > > > > > > > <h:commandLink action="first"> > > > > <h:outputText value="Page1" /> > > > > </h:commandLink> > > > > > > > > </h:form> > > > > </f:view> > > > > > > > > Portlet def: > > > > <portlet id="home"> > > > > <description> Home</description> > > > > <portlet-name>home</portlet-name> > > > > <display-name>Home</display-name> > > > > > > > <portlet-class>org.apache.portals.bridges.jsf.FacesPortlet</portlet-clas > > s> > > > > <init-param> > > > > <name>ViewPage</name> > > > > <value>/WEB-INF/index.jsp</value> > > > > </init-param> > > > > <supports> > > > > <mime-type>text/html</mime-type> > > > > <portlet-mode>VIEW</portlet-mode> > > > > </supports> > > > > <supported-locale>en</supported-locale> > > > > <portlet-info> > > > > <title>exception</title> > > > > <short-title>exception</short-title> > > > > </portlet-info> > > > > </portlet> > > > > > > > > Faces navigation rule: > > > > <navigation-rule> > > > > <description> > > > > test > > > > </description> > > > > <from-view-id>/WEB-INF/index.jsp</from-view-id> > > > > <navigation-case> > > > > <description> > > > > goto first page > > > > </description> > > > > <from-outcome>first</from-outcome> > > > > <to-view-id>/WEB-INF/first.jsp</to-view-id> > > > > </navigation-case> > > > > </navigation-rule> > > > > > > > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- 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]
