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

  • #16
    James,

    I see your point how just using one IOC container may be simpler. I suppose I've been using JSF + Spring together for so long now that I am used to thinking of the JSF and Spring contexts as one consolidated whole, even though they live in seperate config files and such. The Shale annotations have certainly made this quite a bit simpler as the whole <managed-bean> syntax in faces-config is pretty verbose. Glad to see the EG is aiming to incorporate the Shale annotations style into JSF 2.0.

    -Jeremy

    Comment


    • #17
      Ok here's the thinking for adding to set for 1.0.2:

      Code:
          <set attribute="foo" class="example.Bar" scope="flash"/>
          <set attribute="foo" bean="bar" scope="flash"/>
      We can do this easily in 1.0.2, then we can tackle custom scopes in 1.1. 1.0.2 will be the last scheduled maintenance release and will start work on 1.1 immediately following its release (we could always have a 1.0.3 if there are 1.0.2 issues but the idea is there won't be).

      This will be in addition to the new resolvers already introduced.

      Sound like a compromise? If you're available to help us with the custom scope solution that'd be great as well.

      I just don't want to add in temporary context delegating (and prototype-based) resolvers when we can have a better custom scope solution still in the short term (the 1.1 release train will be an aggressive one). I understand FlowPropertyResolver does that now, but it's likely we will deprecate that class in 1.1 in favor of custom scopes or the new explicit resolvers introduced in 1.0.2.

      Keith
      Last edited by Keith Donald; Apr 3rd, 2007, 10:27 AM.

      Comment


      • #18
        Jeremy,

        I suppose I've been using JSF + Spring together for so long now that I am used to thinking of the JSF and Spring contexts as one consolidated whole, even though they live in seperate config files and such.
        I not quite there yet, only been using JSF since December. But your right - thinking in your way will allow for much more creative implementations, allowing you to get access to the best of JSF and Spring.

        So to clairfy your approach: (hope you don't mind)

        - you managed beans in both contexts.

        - shale annoatations effectively replace faces-config.xml

        - View Controllers (shale lingo, i.e Page Behinds) are only ever managed in the JSF context?

        - SWF manages prototypes and services, but no View Controllers ?

        - Assuming yes to the two above, am I right in thinking that you only ever reference a Spring Managed Bean VIA a JSF managed bean - so that the jsf acts as a controller to the spring state/servicce?

        For example:

        #{jsfBean.swfBean.xxx}

        - If no then I assume you have a mix of bindings and also do:

        #{flowScope.swfBean.xxx}


        Kind regards

        James

        Comment


        • #19
          Originally posted by jamesclinton View Post
          So to clairfy your approach: (hope you don't mind)
          Don't mind at all. :-)

          Originally posted by jamesclinton View Post
          - you manage beans in both contexts.

          - shale annoatations effectively replace faces-config.xml
          Yes to both.

          Originally posted by jamesclinton View Post
          - View Controllers (shale lingo, i.e Page Behinds) are only ever managed in the JSF context?
          - SWF manages prototypes and services, but no View Controllers ?
          Correct, that is my approach. Though I believe if you didn't want to use annotations, you could possibly get away with having the ViewControllers managed by Spring and scoped to the request, because I believe Shale only accesses them in that case through the VariableResolver mechanism...so theoretically it could resolve a Spring managed ViewController with no problem, and I think all of the Shale callbacks would still happen correctly. But one of the things I like best about the annotation approach is that my ViewControllers do not actually have to implement the ViewController interface anymore, allowing for more expressive method names than init(), prerender(), destroy(), and so forth (though I must admit that in practice, most of my developers have continued to use init() and so forth because they were already used to it). The other thing to point out is that you could conceivably get a lot of the same type of functionality provided by Shale's ViewController callbacks (at least the most commonly useful ones, which I find to be init() and prerender() ) through exclusively using SWF's actions.

          Originally posted by jamesclinton View Post
          - Assuming yes to the two above, am I right in thinking that you only ever reference a Spring Managed Bean VIA a JSF managed bean - so that the jsf acts as a controller to the spring state/servicce?

          For example:

          #{jsfBean.swfBean.xxx}

          - If no then I assume you have a mix of bindings and also do:

          #{flowScope.swfBean.xxx}
          Actually, since we are injecting the swfBean into the jsfBean, we usually use Eclipse to generate delegate methods from the jsfBean to the swfBean so that in the XHTML we only ever have:

          #{jsfBean.xxx}

          and we are free to move properties back and forth between the jsfBean and the swfBean depending on whether we need them to be stateful or not without having to change the EL expressions in XHTML. This is generally my one complaint about JSF and the tooling for it is that the view templates are not too refactoring-friendly, so we use this approach to decouple things a bit more.

          -Jeremy

          Comment


          • #20
            Originally posted by Keith Donald View Post
            Ok here's the thinking for adding to set for 1.0.2:

            Code:
                <set attribute="foo" class="example.Bar" scope="flash"/>
                <set attribute="foo" bean="bar" scope="flash"/>
            We can do this easily in 1.0.2, then we can tackle custom scopes in 1.1. 1.0.2 will be the last scheduled maintenance release and will start work on 1.1 immediately following its release (we could always have a 1.0.3 if there are 1.0.2 issues but the idea is there won't be).

            This will be in addition to the new resolvers already introduced.

            Sound like a compromise?
            Yes, that sounds good to me.

            Originally posted by Keith Donald View Post
            If you're available to help us with the custom scope solution that'd be great as well.
            Definitely, I'd love to help. This would be a big step in getting some of my developers to adjust to SWF a bit easier, and I think it will be useful to the community as a whole.

            Originally posted by Keith Donald View Post
            I just don't want to add in temporary context delegating (and prototype-based) resolvers when we can have a better custom scope solution still in the short term (the 1.1 release train will be an aggressive one). I understand FlowPropertyResolver does that now, but it's likely we will deprecate that class in 1.1 in favor of custom scopes or the new explicit resolvers introduced in 1.0.2.
            I understand completely. I will freely admit that my own FlowELResolver is a complete hack and would have looked even uglier in a non-Java 5 JSF 1.1 form. I agree that the <set> solution is better in the short term as it would still allow for the much cleaner #{myStatefulBean} expressions when using JSF-injected properties, and exposes similar functionality to the non-JSF cases.

            Thanks so much for your attention to this, Keith. I think these steps in 1.0.2 go a long way in making SWF fit more logically into a JSF world, and look forward to helping the bigger custom scope based ideas come to fruition.

            -Jeremy
            Last edited by Keith Donald; Apr 3rd, 2007, 10:27 AM.

            Comment


            • #21
              ...we usually use Eclipse to generate delegate methods from the jsfBean to the swfBean so that in the XHTML we only ever have:

              #{jsfBean.xxx}
              Like it.

              ...and we are free to move properties back and forth between the jsfBean and the swfBean depending on whether we need them to be stateful or not without having to change the EL expressions in XHTML. This is generally my one complaint about JSF and the tooling for it is that the view templates are not too refactoring-friendly, so we use this approach to decouple things a bit more.
              Really nice approach - Effectively you have plugged in a SWF adapter.

              ...though I believe if you didn't want to use annotations, you could possibly get away with having the ViewControllers managed by Spring and scoped to the request..
              This is exactly my approach - but I have the controllers scoped to FLOW because I have wizard functionality.

              Code:
              The View Controller
              
              <bean 
                name="accountViewController"   class="com.xxx.flow.account.AccountFlowViewController"
              scope="prototype"/>
              
              The Form Action Managing the View Controller
              
              <bean 
                id="accountFormAction" class="com.xxx.flow.account.AccountFlowFormActionDelegate">
                <property name="formObjectName" value="accountViewController" />
                <property name="formObjectClass" value="com.xxx.flow.account.AccountFlowViewController" />
                <property name="formObjectScope" value="FLOW" />	
                <property name="validator">
                <bean ...
                <property name="accountService" ref="accountServiceTxnl"/>	
              </bean>
              ...The only problem I have found using this approach is when you want to use complex components. However I have discovered that if you only ever access the ViewController via the FormAction in the Flow Def XML file (you'll need to extend FormAction), it all works...(SellItem-jsf doesn't adhere to this so unless I missed something [v.possible], if you use that example as read you'll have problems with paging/sorting datatable components). Apart from that the example is an excellent starting point.

              Thanks again- you def given me something to think about on my next JSF implemenation.

              James
              [London]

              Comment


              • #22
                A new DelegatingFlowVariableResolver has been committed, which will become the recommended default resolver for 1.0.2. Sellitem now illustrates this, and as you can see there is now no SWF-specific variable prefix on the binding expressions. Combined with the embedding of the flow execution key in the view root (also in 1.0.2), your JSF views participating in flows are now written without any Spring Web Flow dependency at all (just standard JSF). This is a significant improvement over the JSF support in 1.0 and 1.0.1.
                Excellent!

                Erwin

                Comment


                • #23
                  Browser Back Button

                  [JSF] Is there any special configuration required in order to get back browser button support turned on, or is it on by default?


                  regards,
                  James
                  Last edited by jamesclinton; Apr 4th, 2007, 07:55 AM.

                  Comment


                  • #24
                    Back button support + always redirect is now turned on by default, consistent with the other environments we support. All you have to do is define a "flowExecutor" bean consistent with how you do it in the other environments. Previously getting this behavior was way too hard in a JSF env.

                    Keith

                    Comment


                    • #25
                      Thanks Keith - will plug that in, hats off to you!

                      Comment


                      • #26
                        Erwin,

                        A new DelegatingFlowVariableResolver has been committed, which will become the recommended default resolver for 1.0.2. Sellitem now illustrates this, and as you can see there is now no SWF-specific variable prefix on the binding expressions. Combined with the embedding of the flow execution key in the view root (also in 1.0.2), your JSF views participating in flows are now written without any Spring Web Flow dependency at all (just standard JSF). This is a significant improvement over the JSF support in 1.0 and 1.0.1.
                        Should all 'flowScope' prefixes be removed, or is both supported?

                        The reason I ask is because I am finding on POSTBACK exceptions are being thrown (Cannot get value for expression), but they are resolved when the prefix 'flowScope' is removed - I have only noticed since moving to build 42 and plugging in Back Button support.


                        Thanks.
                        Last edited by jamesclinton; Apr 4th, 2007, 10:34 AM.

                        Comment


                        • #27
                          [JSF]

                          Could be me, but using Build 42 with the prefix change I am having issues with valueChangeListener.

                          With the prefix it fails, exception stating Flow Eecution thread not bound to prefix: flowScope.

                          Without the prefix, I get a NPE.

                          Hope that helps


                          UPDATE

                          Took out FlowExecutor config for Back Button support and bindings worked on POSTBACK (build 42)

                          Code:
                          <bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
                          		<property name="definitionLocator" ref="flowLocator"/>
                          		<property name="executionAttributes">
                          			<map>
                          				<entry key="alwaysRedirectOnPause">
                          					<value type="java.lang.Boolean">true</value>
                          				</entry>
                          			</map>
                          		</property>
                          		<property name="repositoryType" value="CONTINUATION"/>
                          	</bean>
                          regards,
                          James
                          Last edited by jamesclinton; Apr 4th, 2007, 10:50 AM.

                          Comment


                          • #28
                            Originally posted by jamesclinton View Post
                            Should all 'flowScope' prefixes be removed, or is both supported?
                            Both should still be supported, but if you aren't counting on the spcific behavior of the FlowPropertyResolver (where it asks your application for an instance of the bean if one does not already exist in flow scope) then it should be safe to remove the prefix as long as you have the new resolvers configured.

                            -Jeremy

                            Comment


                            • #29
                              James,

                              What is your faces-config? What resolvers are you using?

                              You're saying it doesn't work with flow executor configured, but does without?
                              BTW, unless you can't use Spring 2.0, you should use the custom <flow:executor> tag in the webflow namespace.

                              Keith

                              Comment


                              • #30
                                Hi Keith

                                faces-config.xml

                                Code:
                                <!-- Navigation handler proxy for a Spring-managed bean that is the Web Flow Navigation Handler -->
                                <navigation-handler>
                                  org.springframework.web.jsf.DelegatingNavigationHandlerProxy
                                </navigation-handler>
                                <property-resolver>
                                  org.springframework.webflow.executor.jsf.FlowPropertyResolver
                                </property-resolver>
                                <variable-resolver>
                                  org.springframework.webflow.executor.jsf.FlowVariableResolver
                                </variable-resolver>
                                <variable-resolver>
                                  org.springframework.web.jsf.DelegatingVariableResolver
                                </variable-resolver>
                                <!-- Extended "webApplicationContext" resolver -->
                                <variable-resolver>
                                  org.springframework.web.jsf.WebApplicationContextVariableResolver
                                </variable-resolver>
                                webflow-config.xml - flowExecutor commented out, this is how I have had it configured for months.

                                Code:
                                <?xml version="1.0" encoding="UTF-8"?>
                                <beans xmlns="http://www.springframework.org/schema/beans"
                                       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                       xmlns:flow="http://www.springframework.org/schema/webflow-config"
                                       xsi:schemaLocation="
                                           http://www.springframework.org/schema/beans
                                           http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                                           http://www.springframework.org/schema/webflow-config
                                           http://www.springframework.org/schema/webflow-config/spring-webflow-config-1.0.xsd">
                                
                                	<flow:registry id="flowDefinitionLocator">		
                                		<flow:location path="/WEB-INF/flows/*-flow.xml" />
                                	</flow:registry>
                                    
                                    <bean name="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
                                      <property name="basename" value="messages"/>
                                    </bean>
                                    
                                    <!-- 
                                    <bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
                                		<property name="definitionLocator" ref="flowDefinitionLocator"/>
                                		<property name="executionAttributes">
                                			<map>
                                				<entry key="alwaysRedirectOnPause">
                                					<value type="java.lang.Boolean">true</value>
                                				</entry>
                                			</map>
                                		</property>
                                		<property name="repositoryType" value="CONTINUATION"/>
                                	</bean>  
                                     -->
                                
                                   <bean id="jsfNavigationHandler" class="org.springframework.webflow.executor.jsf.FlowNavigationHandler" />
                                	
                                   <bean id="flowPhaseListener" class="org.springframework.webflow.executor.jsf.FlowPhaseListener"/>
                                	
                                	
                                </beans>
                                updated websa-config to fix incorrect flowDefinitionLocator .

                                ------------------------------------------------------------------------
                                Rolled back to 1.0.1 and the application runs fine.

                                ----BUILD 39,40,41,42---------------------------- (update: build 40 has same problems) (update: build 39 has same problems)
                                *Back button problems
                                *Problems when 'binding' HtmlDatatable component
                                [ValueBindingImpl] Exception while determining read-only state of value-binding : #{flowScope.bb.userList.dataTable}

                                ----BUILD 38----------------------------
                                *Binding OK
                                *BACK button OK
                                *Refresh OK
                                *Double submit OK

                                Build 38 Config.
                                Code:
                                <?xml version="1.0" encoding="UTF-8"?>
                                <beans xmlns="http://www.springframework.org/schema/beans"
                                       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                       xmlns:flow="http://www.springframework.org/schema/webflow-config"
                                       xsi:schemaLocation="
                                           http://www.springframework.org/schema/beans
                                           http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                                           http://www.springframework.org/schema/webflow-config
                                           http://www.springframework.org/schema/webflow-config/spring-webflow-config-1.0.xsd">
                                
                                	<!-- Creates the registry of flow definitions for this application -->
                                	<flow:registry id="flowDefinitionLocator">		
                                		<flow:location path="/WEB-INF/flows/*-flow.xml" />
                                	</flow:registry>
                                    
                                    <bean name="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
                                      <property name="basename" value="messages"/>
                                    </bean>    
                                
                                    <bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
                                		<property name="definitionLocator" ref="flowDefinitionLocator"/>
                                		<property name="executionAttributes">
                                			<map>
                                				<entry key="alwaysRedirectOnPause">
                                					<value type="java.lang.Boolean">true</value>
                                				</entry>
                                			</map>
                                		</property>
                                		<property name="repositoryType" value="CONTINUATION"/>
                                	</bean> 
                                
                                	<bean id="jsfNavigationHandler" class="org.springframework.webflow.executor.jsf.FlowNavigationHandler" >
                                	  <description>
                                    	Spring configured flow navigation handler delegate, allowing for custom configuration
                                		using standard dependency injection techniques.
                                		
                                		Note: this definition is optional; you may choose to simply specify your FlowNavigationHandler
                                		in your faces-config.xml if its defaults meet your needs.
                                	  </description>
                                	</bean>
                                
                                	<bean id="flowPhaseListener" class="org.springframework.webflow.executor.jsf.FlowPhaseListener"/>
                                	
                                	
                                </beans>
                                -James
                                Last edited by jamesclinton; Apr 4th, 2007, 12:53 PM.

                                Comment

                                Working...
                                X