Spring Web Flow 2.0 M4 - Feedback Requested


News: Spring Web Flow 2.0 M4 - Feedback Requested

  1. Spring Web Flow 2.0 M4 - Feedback Requested (13 messages)

    The final milestone in the Spring Web Flow 2 release roadmap was just met, and introduces many new features. The Web Flow team would like your feedback on the new features before the generally available 2.0 release. Web Flow allows you to implement flows in a web application. It plugs into Spring MVC, Spring's base platform for web applications, and also can be embedded in other web environments. Please see the SpringSource Team Blog for the original feedback request. As noted in the request, the best way to provide feedback is to download the milestone release, evaluate the reference applications, and discuss your thoughts and impressions -- good or bad -- with the team here. The Web Flow team is specifically seeking feedback on the following:
    1. Web Flow 2 M4 introduces a simplified flow definition syntax. Early results show use of this syntax can reduce the size of a version 1 flow definition by up to 50%. What do you think of the new syntax? (See example: old vs. new)
    2. Web Flow 2 M4 includes a new Spring Faces module that provides support for JSF in Spring, including support for rendering JSF views from MVC Controllers and Flows. Faces also includes a lightweight component library for Ajax that degrades when Javascript is not available. What do you think of this JSF support?
    3. Major new features including the integration with Spring Security 2, flow-managed persistence contexts, EL support, view scope, Ajax event handling with partial rendering support, support for popup dialogs, and improved exception handling.
    4. The introduction and refinement of several Web Flow extension points. Are you a framework author building on Web Flow now? If so, how can you see using these extension points?
    The next Web Flow release in the 2 series will be RC1, with a GA release scheduled for the end of the month.

    Threaded Messages (13)

  2. Does it work with Spring Portlet MVC?
  3. Hi Scott, The M4 release does not. We are currently working on Spring Portlet MVC support for Web Flow now. The integration approach is similar to the approach we took in version 1, but there are some differences. Here is the approach: - There exists a Controller adapter that plugs Web Flow into Portlet MVC. - Portlet request-to-flow mapping rules are configurable; a common rule is to map to a flow based on the Portlet mode. - Web Flow 2 knows whether the current request is an action or render request and adjusts its view handling behavior accordingly. This is the trickiest part of the integration to get right, and where we are focusing most of our time. - Flow execution state is preserved across the action/render request life-cycles for you (managed in the PortletSession by default). I would be interested to hear more general feedback on demand for Web Flow features in a Portlet world. I admit we do not get a lot of Portlet questions on our forum, so it has been a little difficult to gauge the user demand and therefore the priority of our version 2 support. However, I know Spring Portlet MVC is especially popular in the Portlet community, and it makes technical sense to be able to take advantage of Web Flow 2 in that context. Best regards, Keith
  4. I tend to avoid putting java code in a flow, since the compiler can't check it, so I probably won't be using either the new or old version of this syntax. My form action classes all tend to resemble 'public Event doSomething(RequestContext context), which I've found to work fairly well What's the story with the 'commit' flag in the demo? I tend to juggle flow state around in either one of the SWF scopes and then do anything that modifies data at the end. Is using a 'commit' flag now part of best practice with SWF, or just the provided demo?
  5. Re: Logic in Flows[ Go to top ]

    Greg, Thanks for the feedback! Good to hear from a long time Web Flow user. I agree with you on the general principle you should not be putting business logic in your flows. I firmly believe your flow should delegate down into your application layer to services or domain objects that encapsulate domain behaviors. With that said, I do think in Web Flow 2 there is a genuine opportunity for you to reduce or eliminate traditional Action glue code. In this reference example, I could have created a single BookingService operation that did all three of these steps in one, and invoked that single method from the flow. Something like:
    There is no reason such a method needs to depend on SWF APIs. Indeed, that would have been better and we will improve this aspect of the demo in the next release. These demos are references designed to illustrate best practice (we will have other demos we call 'showcases' that just show features). The story with the commit flag is as follows. When you enter a end-state marked with the 'commit' flag as true, that end-state will commit changes made within the flow's entity manager in a transaction (the flow must be a to have a EntityManager scoped with it). This is a "flow managed" way to synchronize changes to a object graph made during the course of flow execution with the database. In this example, it would have been perfectly suitable to use a @Transactional-scoped EM at the service layer with a detached Booking object in flow scope, instead of the flow-managed persistence context feature. The managed persistence is most useful for flows that modify an existing object graph over the course of a series of steps with a commit at the end. Best regards, Keith
  6. Re: Logic in Flows[ Go to top ]


    Thanks for the feedback! Good to hear from a long time Web Flow user.

    Hi Keith, I think the best thing that the Spring team could do for Web Flow is to more or less leave it as is, and upgrade the doco for it for new users. I still get the impression that a lot of people use Spring MVC, which is pretty much completely superceded by SWF. I now build everything as a flow, for if/when the application evolves or requirements change and pages need to be strung together in a new or revised use-case. The only exceptions are where you need to end an application URL with .xls or .doc, etc, to compensate for IE basically ignoring the content-type. I've converted a lot of Spring MVC code to SWF and its pretty painless. A lot of code also disappears when converting to SWF. I am also mystified by the integration with JSF. I think JSF needs SWF more than SWF needs JSF, but I guess that's the 'Spring way' to just integrate and not judge what sucks and what doesn't suck. Regards,
  7. Re: Logic in Flows[ Go to top ]

    Hi Greg, Yes, the role Web Flow plays in your web architecture is the same in SWF 2 as it is in SWF 1. The major difference in SWF 2 of course is the flow definition language simplification, and the addition of new features such a security integration and a model for handling Ajax events. The great thing about Spring MVC is it is so extensible. Absolutely, you can use SWF to implement most of your controllers if you want; you can also run multi action @Controllers along side flows. SWF will always benefit from the base Spring MVC provides for things like URL handler mapping, request interception, and exception handling. Regarding the flow definition language improvements: I think once you start moving to SWF 2 you will see the value of these simplifications. In SWF 1, a typical flow consisted of at least 2 (sometimes 3-4) artifacts: the flow definition, a FormAction class, and a local bean definition resource. The goal in SWF 2 is to reduce those artifacts to *1* -- the flow definition -- while reducing overall implementation complexity at the same time. I think this goal has merit and expect you to be even more productive with SWF 2 than version 1 as a result, while still able to naturally layer your architecture with a clear separation between your control logic and your business logic. For extensive SWF 1 installations like yours, I would recommend to wait until RC1 before attempting any serious migration, since RC1 will provide a migration guide and compatibility for version 1 flows. I definitely encourage you to keep the M4 evaluation process going, and let us know what else what you like and don't like. Your suggestion earlier in this thread was helpful, and led to concrete improvements in our reference application. Thanks Keith
  8. Re: Logic in Flows[ Go to top ]

    Hi Greg,

    Yes, the role Web Flow plays in your web architecture is the same in SWF 2 as it is in SWF
    Hi Keith, I pretty much think SWF is complete, and that you guys have done a great job. I'm not too excited about SWF2 features since I don't have too many pain points with SWF1. Having 1 less file isn't such a big deal for me, and might even be a step backwards in some respects since I kind of like seeing validators appearing declaratively in the *-flow-context.xml file. I also don't like how the command object is seemingly being engineered out of the flow. Since we have flow/conversation scopes now, I find the command object is much cleaner and can be passed down to services without feeling too dirty about doing that, so building a flow minus the command object isn't something I want to achieve. It would be interesting for me if you guys could show how SWF can be used with something like Ext (www.extjs.com) Also, for a while I've been thinking of building a SWF Generator, a one-way code generator which spits out SWF files (.xml x 2 + command + form action). Maybe something like this could be built as part of the recently announced SpringSource tools. The generator would be freemarker and sitemesh based, and allow user-defined templates, e.g. grid pages, edit pages. The only hassle with SWF right now, like you say, is doing the braindead activity of getting the initial flow and artifacts up and running.
  9. Re: Logic in Flows[ Go to top ]

    I also don't like how the command object is seemingly being engineered out of the flow. Since we have flow/conversation scopes now, I find the command object is much cleaner and can be passed down to services without feeling too dirty about doing that, so building a flow minus the command object isn't something I want to achieve.
    In SWF 2 the domain objects managed by a flow can, and generally should, be independent of any SWF API. For simple applications this decoupling isn't always necessary, but for most applications with real business logic it is the way to go. The generally recommended SWF 2 approach has such domain objects declared as instance variables inside your flow definition, instead of externally managed Spring bean definitions. You can still use external beans, too, but I find the most natural place to define such objects is with the flow itself. The concept of flow instance variables makes a lot of sense... I'm glad to hear you don't have a lot of pain points with SWF 2. I still think you'll like SWF 2 more once you start using the new features. :-)
    It would be interesting for me if you guys could show how SWF can be used with something like Ext (www.extjs.com)
    We integrate both Dojo and ExtJs with SWF 2. We currently provide declarative tags that encapsulate use of these UI toolkits through our own Javascript library called Spring.js. The tags provided are Facelet tags (for use with a JSF UI), but a similar set of tags could be built for a JSP/Velocity/Freemarker environment as well. Also, you can always use Spring.js directly and we will have examples of how to do this available soon. Keith
  10. xml is not a replacement for java[ Go to top ]

    xml is not a replacement for java and shouldnt be used in situations like these.
  11. I believe XML is a fine medium for expressing structure, and what you should be doing when you define a flow is expressing the navigational structure of a task your users can accomplish. I agree, if you are embedding a lot of condition and imperative logic within your flow, you *are* abusing the medium, and furthermore, you're likely tangling control logic with business logic. Flows allow you to use EL to invoke actions written in a real programming languages like Java for good reason. Keith
  12. Flow inheritance[ Go to top ]

    I have been using Webflow for 6 months or so and closely following the Spring Webflow support forum. There were a couple of features that I was really hoping would be available in WebFlow 2.0. I looked at the documentation (which is still pretty sparse) and the example but couldn't tell if these were addressed yet: 1) Flow inheritance - If you have several flows in a system and they all share a set of common global transitions or exception handlers or what not, is there a way to have them inherit from a parent flow so as to not have to reproduce this xml everywhere? 2) Return to last view state functionality - I've seen several requests for this in the forums and had to implement it myself using a Listener and Exception Handler. If a render action for a particular view state throws an exception, in many cases the correct action for our application is to return to the previous view state and show an error message. Has 2.0 made this any easier to implement without having to explicitly add on-exception transitions everywhere? Thanks!
  13. Re: Flow inheritance[ Go to top ]

    Sam, Great questions. 1) XML-based flow definition inheritance will make 2.0 GA, yes. We have the inheritance / merge algorithm working and are doing integration testing of it now with the existing FlowDefinitionRegistry infrastructure. I expect a RC1 nightly build to have this functionality integrated in the coming days. 2) This is a good suggestion for enhancement, and a straightforward one to integrate given there is an existing JIRA and patches that have been submitted. I can't promise anything yet, but we'll look a integrating this in time for the GA release. Thanks Keith
  14. Spring WebFlow rocks![ Go to top ]

    I'm just a junior java developer, so I really dont have the level to make you remarks about what should be ameliorated in Spring WebFlow, just wanted to say that I'm using it since a few months and it is really a great tools and wanted to congratulate the team