Announcement Announcement Module
Collapse
No announcement yet.
1.0.2 sanity testing - feedback requested Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Yes I've thought about the same thing as well. Currently, when a top-level flow execution ends the root flow session is popped off the stack and the execution is then no longer active (no session information can be obtained from that point on, and the execution must be thrown away). The only way to access flow information then is through the read-only model map returned in the confirmation view selection. This view selection model is actually available via the current FlowExecutionHolder view selection property in a JSF environment, so it's possible we could support this in DelegatingFlowVariableResolver as a special case.

    It is definitely worth creating a JIRA on this noting this limitation... Mister X can you create a JIRA?

    Keith

    Comment


    • #62
      I've just create a JIRA: http://opensource.atlassian.com/proj...browse/SWF-285. I would appreciate if this would be fixed for 1.0.2 if a simple solution is possible.

      Comment


      • #63
        I did some additional tests with a slightly modified version of sellitem-jsf. For this purpose I used the example with added ajax4jsf functionality. I could verify that it works perfectly with MyFaces 1.1.5 and JSF-RI 1.1_02 on Tomcat 5.5.23 and Tomcat 6.0.10. Furthermore, it also works with JSF-RI 1.2_04-p01 on Tomcat 6.0.10. Additionally, I added Facelets 1.1.12 to get JSF 1.2 work on Tomcat 5.5. No problems here. Interestingly enough, at least for me, the previously described limitation when using JSF UI components in end-states views does not exist if Facelets are used as the view technology! If anyone is interested I could provide the example.

        Comment


        • #64
          Originally posted by MisterX View Post
          Interestingly enough, at least for me, the previously described limitation when using JSF UI components in end-states views does not exist if Facelets are used as the view technology!
          I hadn't thought about that, but that makes sense since Facelets aims to be (and succeeds beyond measure) a complete replacement for JSP with JSF. I honestly can't imagine why anyone would not use it at this point, unless prohibited by some corporate restriction. Not only does it solve most of the problems that existed with JSF's original JSP integration, but it also contains a lot of smart optimizations that increase rendering performance a good bit. Glad to see it is on the list of things being included in JSF 2.0.

          -Jeremy

          Comment


          • #65
            Mister X,

            Providing the example would be excellent. We'd like to illustrate best-practices of using JSF in our samples (which of course includes using SWF), so integrating Facelets and other good libraries like Ajax4JSF make a lot of sense. If you can help us with that by submitting the example to JIRA we can work to integrate it for 1.1, that'd be grand.

            I suspect we can still handle this special case failure inside DelegatingFlowVariableResolver easy enough for 1.0.2.

            Keith

            Comment


            • #66
              Mister X,

              I have committed a patch to DelegatingFlowVariableResolver to address SWF-285 and tested it with the sellitem-jsf sample, which now uses JSF components with EL expressions in the confirmation view. If you could confirm their are no issues with this for your tests that would be great.

              Keith

              Comment


              • #67
                Keith,

                the limitations for using JSF UI components in end-state views are gone now. Thanks for fixing this so quickly! I will provide the previously mentioned example through JIRA soon.

                Jens

                Comment


                • #68
                  Originally posted by jeremyg484 View Post
                  I don't see anyplace in sellitem-jsf where you're using the binding attribute, and I think herein lies the confusion. The only bindings you have in there are value bindings (i.e., value="#{sale.foo}") where you are just referencing some property on a bean to get its value, whereas what James is having problems with are component bindings (i.e., binding="#{flowScope.bb.accountList.dataTable}") meaning he is actually binding the instance of UIData to his backing bean so that he can manipulate it programatically.

                  -Jeremy
                  The approach of binding to a flow scoped bean seems to violate the following from the facelets faq:
                  The second way this (Duplicate ID Errors) can happen is when you using 'binding' attributes on your components. If you are binding components to anything other than request-scope, you can run into problems where components, and their assigned identifiers, get injected into another page, conflicting with their identifiers. Again, you can attempt to provide explicit id's to your components to avoid conflict and guarantee uniqueness, but it doesn't fix the greater issue with application/session scoped bindings:

                  1) UIComponents are not Serializable-- and therefore cannot be clustered

                  2) UIComponents are not thread safe can cannot be used by multiple requests at once

                  Binding UIComponents to backing beans is actually something worth doing to ease particular use cases. Instead of using a session/application scoped bean, use a request-scoped composite mediator that receives your session beans and the UIComponent instance to coordinate behavior.
                  I was trying to bind a UIData to a flow scoped bean and I ended up getting Duplicate ID Errors. Moving the binding to my request scoped backing bean fixed that problem. Unfortunately this complicates the ability to pass information to a sub flow. I wanted to pass the item from a search results table to an edit flow. I am not able to do the input mapping I wanted to since I can not access the request-scoped bean in the flow attribute mapping. I am not able to do the equivalent using a request-scoped bean:
                  Code:
                          <mapping source="${flowScope.searchBean.resultsTable.rowData.oid}" 
                              target="id" />
                  The duplicate ID errors manifested themselves in an odd way. I could go from my search results to my edit page and back to may search results page once with no problem. If I then navigated to the edit of another item and then tried to return to the search, that is when the duplicate ID errors were encountered.

                  Comment


                  • #69
                    Originally posted by msauer View Post
                    I was trying to bind a UIData to a flow scoped bean and I ended up getting Duplicate ID Errors.
                    Well, first off, were you remembering to make the UIData instance transient in your bean?

                    That said, I don't recommend binding the actual UIData instances because of the way the ids for the components within the table rows are generated no matter what you supply for the component id. In almost all cases, you can achieve the same things by binding to your own managed instance of a DataModel instead. For example, say you are using the dataTable to display a list of objects as follows:

                    Code:
                    <h:dataTable id="myTable" var="row" value="#{flowScope.searchBean.searchResults}">
                    ...
                    Instead of this in SearchBean.java:

                    Code:
                    List searchResults = new ArrayList();
                    you can do this:

                    Code:
                    List resultList = new ArrayList();
                    ListDataModel searchResults = new ListDataModel(resultList);
                    and then the mapping in your flow definition would instead become:

                    Code:
                    <mapping source="${flowScope.searchBean.searchResults.rowData.oid}" 
                                target="id" />
                    and you won't have to worry about the issues of binding the UIData instance.

                    -Jeremy

                    Comment


                    • #70
                      Thanks. Setting the UIData item to transient does not eliminate the duplicate ID errors.

                      I will attempt to follow the approach you set forth.

                      I am assuming that if I use the new DelegatingFlowVariableResolver I will not be able to expect that my bean will be created from the spring context as it was before. My understanding is that with this recommended variable resolver I will have to use the set element to create the flow scope bean. Is that correct?

                      So if I am creating JSF beans and injecting the flow scoped beans I should do the following?
                      faces-config:
                      Code:
                      <application>
                        <navigation-handler>
                          org.springframework.webflow.executor.jsf.FlowNavigationHandler
                        </navigation-handler>
                        <variable-resolver>
                      org.springframework.webflow.executor.jsf.DelegatingFlowVariableResolver
                        </variable-resolver>
                        <view-handler>
                            com.sun.facelets.FaceletViewHandler
                        </view-handler>
                      </application>
                      	
                      <lifecycle>
                      <phase-listener>org.springframework.webflow.executor.jsf.FlowPhaseListener</phase-listener>
                      </lifecycle>
                      <managed-bean>
                          <managed-bean-name>searchBean</managed-bean-name>
                          <managed-bean-class>com.xxx.SearchController</managed-bean-class>
                          <managed-bean-scope>request</managed-bean-scope>
                          <managed-property>
                            <property-name>searchModel</property-name>
                            <value>#{searchModel}</value>
                          </managed-property>
                       </managed-bean>
                      spring bean config:
                      Code:
                        <bean id="searchModelBean" class="com.xxx.SearchFlowModel" scope="prototype" lazy-init="true"
                        />
                      flow config:
                      Code:
                      <start-actions>
                        <set attribute="searchModel" bean="searchModelBean" scope="flow"/>
                      </start-actions>
                      <start-state idref="searchView" />
                      
                      <view-state id="searchView" view="/search.xhtml">
                      ...
                      I am trying to use the latest 1.0.2 nightly and I am getting the following error when I try this:
                      Attribute 'bean' is not allowed to appear in element 'set'

                      Comment


                      • #71
                        Msauer,

                        That is right, the set element has not been enhanced for 1.0.2 and will not be as we decided it was too significant of an enhancement for a point release (will consider it again for 1.1).

                        Regardless in your case you should use flow variables with the 'var' element. See sellitem-jsf for an example.

                        Keith

                        Comment


                        • #72
                          Originally posted by msauer View Post
                          I am assuming that if I use the new DelegatingFlowVariableResolver I will not be able to expect that my bean will be created from the spring context as it was before. My understanding is that with this recommended variable resolver I will have to use the set element to create the flow scope bean. Is that correct?
                          You will indeed need some other way to populate your flow variables if you opt not to also use the original FlowVariableResolver and FlowPropertyResolver. But keep in mind that you can configure as many variable and property resolvers as you want, so you could potentially continue to use ${flowScope.xxx} and let the old resolver delegate to the application context for bean creation on demand.

                          Jeremy

                          Comment


                          • #73
                            Build 51 has resolved my component binding errors present in 39-42.

                            Thank you.

                            Comment

                            Working...
                            X