Announcement Announcement Module
Collapse
No announcement yet.
SWF and JSF best practices Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • SWF and JSF best practices

    I was reading the JSF and Spring Web Flow presentation from the 2006 SpringOne conference and a couple of items on the slides have me a bit confused. For JSF - Web Flow integration one slide recommends that web flow assume all navigation duties. Another slide later talks about what makes a good flow and states that pages such as menus and simple form submissions are not good candidates but flows are best for supporting business process workflows. I have an application that has both simple pages/menus and complex flows. Should I then configure all navigation in web flow or would a mixture - some in web flow, some in the normal JSF navigation configuration be a better approach (assuming that is even possible)?

  • #2
    Personally I would advise a mixture.
    However, you can also do everything using SWF if you prefer to use one technology for all pages.

    Erwin

    Comment


    • #3
      I have done everything in SWF apart from my menu component. Works well.

      Comment


      • #4
        I have been using SWF as a complete replacement for JSF navigation-rules, even in the case of our simpler pages and menus. I was happy to be able to take it to this extreme as it would be a bit too confusing for my team to have navigation rules defined in multiple places.

        I find that even with the simpler pages in JSF, you oftentimes need something to manage the state of your model across multiple requests to the page...there are many solutions for this problem in the JSF community (Tomahawk's saveState tag, Shale's dialog framework, etc.), but I personally find SWF's multiple scopes to be the most robust and elegant solution. Even for the simpler pages, we typically use SWF's flash scope to store model state. This did take some extra work, as we had to write a custom ELResolver to be able to access more than just flow scope via EL expressions (something I will likely contribute back to the community), but once that was done it works quite seamlessly. For handling the application menu, I have found global transitions to work well.

        As a side note, combining this use of SWF for all navigation along with using Shale's annotation-based configuration mechanism for the managed beans, we end up with almost nothing in our faces-config file.

        -Jeremy

        Comment


        • #5
          Jeremy,

          Have you managed to get a paging/sorting datatable to work?

          I have but using a slightly different implementation to that of sellitem-jsf. It would be really good to hear from you on this matter as very few people seem to be successful in implementing swf+jsf when it comes to using clever components.

          All the best

          James

          Comment


          • #6
            Originally posted by jamesclinton View Post
            Have you managed to get a paging/sorting datatable to work?
            There is this example that I had provided when you were having problems awhile back:
            http://forum.springframework.org/showthread.php?t=36805

            In looking back at it, I realize that there were some shortcuts taken for the sake of simplicity that may ultimately have made it slightly confusing. Perhaps I should revise it and upload a more complete example that more closely follows how I typically set things up in my own projects.

            I do use the Tomahawk dataScroller component quite a bit in our applications, but I typically don't use the sorting. Most of the places I use it are for rather large (500+ rows) lists of objects. One of the drawbacks of the dataScroller component is that it essentially was designed around the idea that the entire list would already be loaded into memory. I use a custom JSF DataModel object to back the dataTable that dynamically loads the list from the database only 50 rows at a time. I have some trickery in the DataModel that allows it to work under the fully-loaded-list assumptions of the dataScroller.

            I think perhaps one reason I don't run into any trouble is because my usage of JSF + SWF is different from what a lot of people seem to try at first. I still use JSF managed beans for fine-grained actions within a given page, and only use SWF's state transitions when I have some action that is exclusively a part of a flow (i.e., it only is needed when going from view A to view B under certain conditions). It seems that many people are trying to replace JSF managed beans altogether and that tends to create more problems than it solves. Perhaps such an approach would be more feasible if one could use actual JSF-aware EL expressions in their flow definitions.

            My typical architecture is to use JSF request-scoped managed beans to define any fine-grained event listeners and actions that occur within the scope of a given view. These beans typically manipulate a seperate model object which is stored in one of SWF's scopes (most often flash scope). This model object is injected into the managed bean using JSF's managed-property mechanism. So in the case of the paged dataTable, I am just binding into a list that is stored in this stateful model object.

            Oftentimes for my flows, I will use a helper object that exposes the originating managed bean to flowscope (so that I can access its properties from an SWF action) and then removes it from flowscope at the end of the request. This too wouldn't be necessary if I were able to use JSF-aware EL expressions in my flow definitions. (As you might guess by my now having mentioned it twice, that is something I'd like to look into implementing in SWF.)

            -Jeremy

            Comment


            • #7
              ....what a lot of people seem to try at first. I still use JSF managed beans for fine-grained actions within a given page, and only use SWF's state transitions when I have some action that is exclusively a part of a flow (i.e., it only is needed when going from view A to view B under certain conditions). It seems that many people are trying to replace JSF managed beans altogether and that tends to create more problems than it solves.
              This is exactly my approach. It works well, but your right getting there was v.troublesome.

              Perhaps such an approach would be more feasible if one could use actual JSF-aware EL expressions in their flow definitions.
              Nice idea!

              Perhaps I should revise it and upload a more complete example that more closely follows how I typically set things up in my own projects.
              If you could I think the SWF community would greatly appreciate it...plus it would be good to compare my pure SWF managed beans implementation (search-car.zip) to your hybrid example.

              Comment


              • #8
                Jeremy and James,

                You might want to check the latest 1.0.2 nightly build for a thing called "FlowExecutionPropertyResolver" and "FlowExecutionVariableResolver".

                The former, when used with the latter, gives you access to scopes flash/flow/conversation plus searching capability through each scope when no explict prefix is used (e.g. flowExecution.foo vs. flowExecution.flowScope.foo)

                It'd be great to have your feedback on this before 1.0.2 goes out--there has been a good deal of work done in the JSF area for 1.0.2 in general

                Keith

                Comment


                • #9
                  Jeremy,

                  What does it take to access JSF expressions? FWIW, in a JSF environment the FacesContext is available from within a SWF flow definition via the RequestContext, which serves as the root object for all definition expressions (the default expression language being OGNL).

                  Specifically:
                  Code:
                  externalContext.facesContext
                  Will get you access to the FacesContext from inside SWF.

                  You can customize the default expression parser in SWF as well. It requires opening up some of the internals hidden by the config subsystem, but it can be done.

                  Let me know what you would need to get at JSF expressions programatically and I'll see if I can help in this effort.

                  Keith

                  Comment


                  • #10
                    Keith,

                    It depends on how tied you want to be to the JSF API. The simplest way would definitely be to get at the EL context through the FacesContext.

                    The other option would be to use the newer standalone EL implementation and set up a custom EL context that doesn't necessarily have to depend on FacesContext, but would perhaps merge in its resolvers if they are present. I believe Facelets takes a similar approach. This could be useful and worth the effort if you think some non-JSF users would like the ability to use standard EL expressions instead of OGNL expressions. In general though, I don't see how this would be especially appealing. OGNL is a bit more powerful as Jacob Hookom illustrates here:
                    http://weblogs.java.net/blog/jhook/a...arisons_1.html

                    It might be nice for JSF users though to only have to use one expression syntax, so being able to swap out the default expression parser could potentially be really useful. I would have to think further about all of the ways expressions are used in flow definitions in order to decide if that's a realistic idea.

                    This is all rather speculative at the moment as I haven't dug deeply into the internals of the config subsystem or the current binding library. I will try to look a little deeper today and perhaps do some quick prototyping of the idea.

                    -Jeremy

                    Comment


                    • #11
                      Jeremy,

                      You can set the expression parser on a flow registry basis. Setting the parser is just not yet supported from the 'flow:registry' convenience element in config, because we support no other parsers out of the box yet. This doesn't stop you from doing this though:

                      Code:
                      	<bean id="flowRegistry" class="org.springframework.webflow.engine.builder.xml.XmlFlowRegistryFactoryBean">
                                 <property name="expressionParser" ref="myExpressionParser"/>
                      		<property name="flowLocations" value="classpath:test-flow.xml"/>
                      	</bean>
                      ... in place of using the <flow:registry/> tag.

                      Keith

                      Comment


                      • #12
                        Ok, so I've spent more time analyzing this in detail and playing around with some different ideas. I have come to think that implementing an EL-aware ExpressionParser and the necessary supporting classes would indeed be the cleanest approach. Not only would it allow for JSF users to use EL expressions in their flow definitions in much the same way they are used to doing throughout JSF, but it could potentially also allow for users of other view technologies to access all of the features of the new Variable/Property Resolvers via the same expressions (though they would probably have to be converted to ELResolvers first so as to get rid of the JSF dependency).

                        At least from what I've been able to find as far as how expressions are currently used in SWF, I don't think a general user would be losing anything by using EL instead of OGNL, and the only new dependency that would be introduced is the EL RI.

                        More to come...

                        -Jeremy

                        Comment


                        • #13
                          Unless I'm missing something, people would lose a decent amount going to EL instead of OGNL, w/regards to the expressiveness of the language. EL is basically just JavaBeans traversals plus collection element access,while OGNL allows a decent amount more.

                          On the negative side, OGNL is pretty slow, but I don't necessarily know that EL is any faster...

                          Colin

                          Comment


                          • #14
                            Yes, I realize OGNL has certain features that EL doesn't (see my earlier link to Jacob Hookom's blog on the topic...there is a performance comparison there as well) such as projections. But my point is to question whether these extra features are really utilized within SWF. Also note that it is possible to extend EL to add more features if so desired. The initial value proposition is that by using EL, access is easily gained to JSF managed beans from within the flow definition. But I don't think it has to stop there...it would be possible to include any JSP 2.1 resolvers or even some other library like Seam's resolvers all within the same evaluation chain.

                            -Jeremy

                            Comment


                            • #15
                              Originally posted by jeremyg484 View Post
                              Not only would it allow for JSF users to use EL expressions in their flow definitions in much the same way they are used to doing throughout JSF
                              I believe this is mentioned as one of the benefits of using the Shale dialog manager. I considered using Shale for this reason but stopped because of the inferior subflow capabilities (e.g. passing data to subflows/subdialogs).

                              Comment

                              Working...
                              X