SWF and JSF best practices

[msauer]

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)?

[klr8]

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

[jamesclinton]

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

[jeremyg484]

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

[jamesclinton]

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

[jeremyg484]

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

[jamesclinton]

....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.

[Keith Donald]

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

[Keith Donald]

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:

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

[jeremyg484]

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