voyent
Parent - Child UI development question  XML
Forum Index -> General Help
Author Message
creil

Joined: 28/May/2007 00:00:00
Messages: 51
Offline


Say I have a page called parent.jspx and a backing bean called ParentBean. I navigate to a child.jspx from the parent page. The child page has a backing bean ChildBean. Now a make a change on the child page that needs to update an attribute on the ParentBean. What is the best pattern for doing this? In the past I have injected the ParentBean onto the ChildBean so when I made changes on the child page, I could call back on the ParentBean.

I am using IceFaces request scope for the beans.

I am mainly wondering what others are doing. Do you use a pattern similiar to this? What other options are there?



deryk.sinotte


Joined: 26/Oct/2004 00:00:00
Messages: 1008
Offline


Maybe I'm misunderstanding your design, but request-scoped beans on different pages probably won't be able to share information in a useful way. ParentBean on parent.jspx, if requests-scoped, will go away when you navigate to child.jspx. The ChildBean that you reference on child.jspx can be injected with a new instance of ParentBean (either through JSF mechanisms like faces-config.xml or using something like Spring) but it won't be the same ParentBean instance that you had on parent.jspx.

Have I misunderstood what you are asking?

Deryk Sinotte
Team Lead
ICEsoft Technologies, Inc.
creil

Joined: 28/May/2007 00:00:00
Messages: 51
Offline


When I use IceFaces request scope, I do get the same ParentBean instance because I am only doing forwards (not re-directs) when going from the parent page to child page and vice versa.

I am just wondering is this a common pattern to follow? The thing I like about the IceFaces request scope is I can keep the state of the page and only tweak some of the attributes that actually changed without completely re-loading the page.

Is it a better option to do a re-direct to the parent page and just re-load everything? Is it better to not use IceFaces request scope at all? I am just wondering what my options here are and what others have implemented successfully.
deryk.sinotte


Joined: 26/Oct/2004 00:00:00
Messages: 1008
Offline


That's an interesting use of extended request scope. I guess if it works for you, it's a potentially valid solution. I don't know that I'd categorize it as the "right" or common way to do it but you'll probably find various opinions on this. The concept of "better" can get pretty subjective ;-)

Is there a reason (other than a bit more coding) that the attributes you are interested in carrying around between requests can't be put in session-scoped bean? The request-scoped beans could be injected with a session-scoped beans for those attributes that are shared and tweaked by the request-scoped beans. This is more along the lines of what you'd need to do if the navigation switched to redirects and it's probably what you'd find as a more common solution.

I guess another approach, if you are amenable to using something like Seam or Spring, is to use another framework that provided other scopes for beans that might be a better fit.

Deryk Sinotte
Team Lead
ICEsoft Technologies, Inc.
creil

Joined: 28/May/2007 00:00:00
Messages: 51
Offline


Thanks! I think going forward with the next project I will give the redirect option a try. There is no reason I could not do it this way and it sounds like it is more common.

I also noticed the component showcase doing something like this. I thought that was an interesting approach.

Code:
 <ui:define name="page-content">
 
         <ui:include src="#{navigation.selectedIncludePath}" />
 
     </ui:define>
 
creil

Joined: 28/May/2007 00:00:00
Messages: 51
Offline


Ok, I am going the direction of Icefaces request scope using a redirect in the navigation to end the request. But it is not working. The navigation works, but the request does not go out of scope. I know this because I have a breakpoint and log message in the constructor that don't get tripped.

Here is my web.xml

Code:
 <?xml version="1.0" encoding="UTF-8"?>
 <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.5" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee   http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
   <session-config>
   	<session-timeout>120</session-timeout>
   </session-config>
 
   <context-param>
     <param-name>contextConfigLocation</param-name> 
 	<param-value>/WEB-INF/config/applicationContext-config.xml</param-value> 
   </context-param>
 
   <context-param>
     	<param-name>javax.faces.CONFIG_FILES</param-name> 
 	    <param-value>/WEB-INF/faces-config.xml,/WEB-INF/faces-manged-beans.xml,/WEB-INF/faces-navigation.xml</param-value>
   </context-param>
   
   <context-param>
     <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
     <param-value>server</param-value>
   </context-param>
   <context-param>
     <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
     <param-value>.jspx</param-value>
   </context-param>
   <context-param>
     <param-name>facelets.DEVELOPMENT</param-name>
     <param-value>false</param-value>
   </context-param>
   
   <!--  <context-param>
     <param-name>facelets.REFRESH_PERIOD</param-name>
     <param-value>-1</param-value>
   </context-param> -->
   
   <!-- For local development use a refresh period of 2, so that that compiler will check for changes every 2 seconds  
   <context-param>
     <param-name>facelets.REFRESH_PERIOD</param-name>
     <param-value>2</param-value>
   </context-param> -->
   
 <!-- Set this flag to true if you want the JavaServer Faces
      Reference Implementation to validate the XML in your
      faces-config.xml resources against the DTD.  Default
      value is false. -->
   <context-param>
     <param-name>com.sun.faces.validateXml</param-name>
     <param-value>false</param-value>
   </context-param>
 
 <!-- Set this flag to true if you want the JavaServer Faces
      Reference Implementation to verify that all of the application
      objects you have configured (components, converters,
      renderers, and validators) can be successfully created.
    	 Default value is false. -->
   <context-param>
     <param-name>com.sun.faces.verifyObjects</param-name>
     <param-value>false</param-value>
   </context-param>
 
 <!-- Specifies to the ICEfaces framework whether to support multiple views of a 
      single application from the same browser.  When running in a Portlet 
      environment, this parameter must be set to true. -->
     <context-param>
         <param-name>com.icesoft.faces.concurrentDOMViews</param-name>
         <param-value>true</param-value>
     </context-param>
 
 <!-- Specifies to the ICEfaces framework that synchronous update mode is to be 
      used.  By default, ICEfaces uses asynchronous update mode to support 
      server-initiated updates (AJAX push).  Setting to true will enable 
      synchronous update mode and disable AJAX push features. -->
     <context-param>
         <param-name>com.icesoft.faces.synchronousUpdate</param-name>
         <param-value>false</param-value>
     </context-param>
 
 <!-- Specifies the amount of time in milliseconds that the bridge will wait for  
      a response from the server for a user-initiated request before declaring 
      the connection lost.  Un-comment and change the default value, if necessary. -->    
     <context-param>
         <param-name>com.icesoft.faces.connectionTimeout</param-name>
         <param-value>60000</param-value>
     </context-param>
 
 
 <!-- Specifies the amount of time in milliseconds that an idle asynchronous 
      blocking connection should be held open before being released. Normally, 
      the blocking connection is closed and re-opened with every communication to 
      the browser, such as user interaction or a heartbeat ping. The purpose of 
      this setting is to remove the possibility of threads being held blocked for 
      a long duration on a dead or completely inactive client connection. This 
      value should be longer than the heartbeat interval to avoid unnecessary
      network traffic.  Un-comment and change the default value, if necessary. -->    
     <context-param>
         <param-name>com.icesoft.faces.blockingConnectionTimeout</param-name>
         <param-value>90000</param-value>
     </context-param>
 
 
 <!-- Specifies the amount of time in milliseconds between heartbeat messages.  
      Un-comment and change the default value, if necessary. -->    
     <context-param>
         <param-name>com.icesoft.faces.heartbeatInterval</param-name>
         <param-value>50000</param-value>
     </context-param>
 
 
 <!-- Specifies how many consecutive heartbeat connection attempts may fail 
      before the connection is considered lost.  Un-comment and change the 
      default value, if necessary. -->    
     <context-param>
         <param-name>com.icesoft.faces.heartbeatRetries</param-name>
         <param-value>3</param-value>
     </context-param>
 
 
 <!-- Specifies the number of milliseconds that a heartbeat request waits for a 
      successful response before it is considered timed out.  Un-comment and 
      change the default value, if necessary. -->    
     <context-param>
         <param-name>com.icesoft.faces.heartbeatTimeout</param-name>
         <param-value>30000</param-value>
     </context-param>
 
 
 <!-- Specifies a page URI to redirect the client to when an asynchronous 
      connection is lost. The parameter value must be surrounded by single 
      quotes.  Un-comment and change the default value, if necessary. -->    
 	<!--  <context-param>
 		<param-name>com.icesoft.faces.connectionLostRedirectURI</param-name>
 		<param-value>'connectionLost.iface'</param-value>
   	</context-param> -->
 
 <!-- ConfigureListener is not generally required. Due to an apparent bug in 
      Tomcat users have reported seeing the following error "SEVERE: ICEfaces 
      could not initialize JavaServer Faces. Please check that the JSF .jar files 
      are installed correctly.". Specifying the ConfigureListener resolves the 
      issue. 
     <listener> 
         <listener-class>com.sun.faces.config.ConfigureListener</listener-class> 
     </listener>
 --> 
   	  	
   <context-param>
     <param-name>com.icesoft.faces.uploadDirectory</param-name>
     <param-value>upload</param-value>
   </context-param>
   
   <context-param>
     <param-name>com.icesoft.faces.uploadMaxFileSize</param-name>
     <param-value>4048576</param-value>
   </context-param>
   
   <error-page>
   	<error-code>500</error-code>
   	<location>/errorPage.faces</location>
   </error-page>
     
   <listener>
     <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
   </listener>
   
   <listener>
     <listener-class>com.icesoft.faces.util.event.servlet.ContextEventRepeater</listener-class>
   </listener>
   <servlet>
     <servlet-name>Faces Servlet</servlet-name>
     <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
     <load-on-startup>1</load-on-startup>
   </servlet>
   <servlet>
     <servlet-name>Persistent Faces Servlet</servlet-name>
     <servlet-class>com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet</servlet-class>
     <load-on-startup>1</load-on-startup>
   </servlet>
   <servlet>
     <servlet-name>Blocking Servlet</servlet-name>
     <servlet-class>com.icesoft.faces.webapp.xmlhttp.BlockingServlet</servlet-class>
     <load-on-startup>1</load-on-startup>
   </servlet>
   <servlet>
     <servlet-name>uploadServlet</servlet-name>
     <servlet-class>com.icesoft.faces.component.inputfile.FileUploadServlet</servlet-class>
     <load-on-startup>1</load-on-startup>
   </servlet>
 
   <!-- Persistent Faces Servlet Mappings -->
   <servlet-mapping>
     <servlet-name>Persistent Faces Servlet</servlet-name>
     <url-pattern>/xmlhttp/*</url-pattern>
   </servlet-mapping>
 
   <servlet-mapping>
     <servlet-name>Persistent Faces Servlet</servlet-name>
     <url-pattern>*.iface</url-pattern>
   </servlet-mapping>
 
   <!-- Blocking Servlet Mapping -->
   <servlet-mapping>
     <servlet-name>Blocking Servlet</servlet-name>
     <url-pattern>/block/*</url-pattern>
   </servlet-mapping>
   
   <servlet-mapping>
     <servlet-name>uploadServlet</servlet-name>
     <url-pattern>/uploadHtml</url-pattern>
   </servlet-mapping>
   
   <welcome-file-list>
     <welcome-file>index.jsp</welcome-file>
   </welcome-file-list>
   
   <!-- tag libraries -->
   <context-param>
 	<param-name>facelets.LIBRARIES</param-name>
 	<param-value>
 		/WEB-INF/custom_comp/ia.taglib.xml
 	</param-value>
   </context-param>
   
 </web-app>
 


And here is my navigation.

Code:
 <navigation-rule>
     	<from-view-id>/admin/manageUsers.jspx</from-view-id>
           <navigation-case>
             <from-outcome>addEdit</from-outcome>
             <to-view-id>/admin/manageUserDetail.iface</to-view-id>
         </navigation-case>
     </navigation-rule> 
     
     <navigation-rule>
     	<from-view-id>/admin/manageUserDetail.jspx</from-view-id>
           <navigation-case>
             <from-outcome>saveCancel</from-outcome>
             <to-view-id>/admin/manageUsers.iface</to-view-id>
             <redirect/>
         </navigation-case>
     </navigation-rule>
 


The stange thing is if I add a servlet mapping for the PersistentFacesServlet of *.faces and use .faces instead of .iface in my to-view-id of the navigation. It works. Not sure what is going on here.
 
Forum Index -> General Help
Go to:   
Powered by JForum 2.1.7ice © JForum Team