Announcement Announcement Module
No announcement yet.
FacesContext null on viewState on-render Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • FacesContext null on viewState on-render

    I need to access to the faces viewRoot before the view is displayed :

    <view-state id="myView" view="/pages/myView.jspx">	
    	<evaluate expression="myBean.init()" />	
    In the myBean.init(), method, the FacesContext is null !

    Note : same behavior in 2.0-RC1 and 2.00-RELEASE versions

  • #2

    That is expected behavior in 2.0.0.RELEASE. The FacesContext is only available during the execution of specific (internal JSF) parts of flow processing, and is not generally available to the flow definition.

    Can you provide some insight on what you need the FacesContext for in your action. Perhaps I can suggest a better way to do what you need to do.




    • #3
      In our application, we need FacesContext to modify the JSF components (according to various business rules) in the ViewRoot before the view is displayed.

      The business rules' side is used to parameter whether JSF components are to be rendered, what value they are populated with, if they are read-only, etc...

      Furthermore, after the initial rendering of the JSF components, Ajax actions called within the page are used to dynamically update the JSF components according to user input. This dynamic update also needs to modify the JSF components in the ViewRoot.

      The Spring myBean 's scope is conversation :
      <bean class="org.springframework.webflow.config.scope.ScopeRegistrar" />
      <bean id="myBean" scope="conversation" init-method="init" class="MyBean" >
      <property name="service1" ref="service1" />
      <property name="service2" ref="service2" />
      Note :This architecture works in our application with Spring WebFlow v.1.0.5, but with myBean as a conversation <var>
      -- the FacesContext is not 'null' --.


      • #4
        In general, I recommend letting the model drive the view rendering in cases such as this, dynamically changing the way the view renders by manipulating the model to which component attributes such as "rendered" are bound, instead of manipulating the UIComponents directly. I feel that it leads to a better decoupling of the processing of your business rules from the structure of your view.

        That said, I understand the desire for this approach, given that sometimes it is simpler to walk the component tree and use the components' mutators than to have a proliferation of boolean methods in your bean. Even though the FacesContext is not available during SWF action execution, you could potentially take advantage of the "binding" attribute of the <f:view> tag (or any other tag that is a parent of the components you wish to manipulate) to inject the component reference into your bean. For example:

        <f:view binding="#{myBean.viewRoot}">
        Keep in mind that if you need to manipulate the components before the first time the view is actually rendered, you will need to instantiate them yourself in the bean. (You would have to do the same if you had access to UIViewRoot through the FacesContext, since the component tree does not actually get populated for the first time until it is rendered.)