RE: Portlet Modes in MyFacesGenericPortlet

[Stan Silvert]

I demoed using modes at JavaOne.  You can find my slides on Sun’s site.  Also, I wrote up some stuff on the MyFaces wiki and my JBoss blog:   http://wiki.apache.org/myfaces/UsingPortletModes http://jboss.org/jbossBlog/blog/Stan%20Silvert/   Because the JSF spec doesn’t cover modes, it takes a bit of manual work on your part.  Any suggestions as to how this can be built into the framework are welcome.  Please see the short discussion on the blog about this.   Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert From: Kong, Wei Jun [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 4:34 PM To: dev@myfaces.apache.org Subject: Portlet Modes in MyFacesGenericPortlet   Hi Everyone,   I've been trying out the MyFacesGenericPortlet, I am not sure to how get the portlet to show different content when switching portlet modes. What is the best way to do this? I've looked at the DefaultViewSelector and thought I could implement that interface to look up init parameters for other default views based on the portlet mode, but it seems that the interface is lacking access to the PortletConfig object (  the PortletContext object gets init parameters for the application ). Could the DefaultViewSelector interface include access to the PortletConfig object in just the same way as the PortletContext? For now hard coded default views jsps for the edit mode and the help mode, the next problem I faced was that a render Parameter view_id was included in my portlet mode urls. Looks like the performAction for the MyFacesGenericPortlet was setting              if (!facesContext.getResponseComplete())             {                 response.setRenderParameter(VIEW_ID, facesContext.getViewRoot().getViewId());             }             The only time that I could see VIEW_ID used was in the next facesRender call,         String viewId = request.getParameter(VIEW_ID);         if ((viewId == null) || sessionTimedOut(request))         {             setPortletRequestFlag(request);             nonFacesRequest(request,  response);             return;         }        Should this be changed to look up the information from the facesContext from the session instead? Or is this a bug with the Portal implementation that I am using? Please let me know if I should open a JIRA issue. Thanks in advance, Wei Jun