如何在Java Web应用程序中实现复杂的页面流

Question

I am trying to implement a reasonably complex page flow (100+ pages) as a traditional web application. I found a few options, but none of them are 100% convincing

1. Hand code the flow into the controllers, do redirects, etc. This is obviously not the best thing for maintenance
2. JSF not only handles the flow, but also requires to use JSF as the view technology. I don't like this lock-in
3. Spring web flow. The current version 2.3.1 defines flows in XML that is not easy to maintain. The upcoming 3.0 release promises to define flows with annotations in pure java, but it does not even have a timeline. Additionally the project development slowed down significantly in the past years.
4. GWT and Vaadin's concept is closer to a traditional desktop application then to a web application, that is really convenient to use, but it wont fit to my project.

Additionally I found dozens of abandoned projects like this: http://javasteps.sourceforge.net/

I am wondering why all these projects are abandoned, what is the way to implement a complex page flow in 2012?

Answer 1

Personally, I'd recommend Single Page Architecture:

Architecture of a single-page JavaScript web application?

I'm not sure if that is feasible or not with your application. I've used all the flows you mentioned above and am currently working on a single-page application and I love it. We're using Dojo on the client-side, which calls a REST API on the server. It's been pretty nice.

Vaadin is pretty solid too and is much easier to set up than just bare-bones GWT. If you have a lot of UI guys on your project that like to code in CSS and Javascript, they'll hate that approach though.

Spring Webflow is pretty solid actually. I haven't looked at it in a while, but when I was using it, it got the job done for what I worked on at the time.

Answer 2

There is a new MVC framework and web flow implementation for Vaadin component model called Lexaden Web Flow

You can try it out for your application as possible alternative.

Answer 3

This is really late but I don't see a satisfactory answer to this question and would like to share an approach I had tried in a recent project which I feel is better than the spring web flow approach which is strictly tied down to spring views. I created a SPA using angular js with Spring MVC. In angular js I did not use routers or state, rather I created a div within the controller like below

<div width="100%" id="fullertonDataPanel" ng-include="page"></div>

On the server side to capture all possible transitions from one frame(I am referring to a particular screen in the SPA) to another I created a tree of rules using MVEL . So in the database I had a structure which stored a tree of rules for every frame . The data in the MVEL expressions were being set by the various services each action invoked. Thus on any action the following steps were followed.

1) Validate the action.

2) Invoke various services.

3) Capture the data from these services and merge it with the existing data of the user.

4) Feed this captured data into collection of rules for each frame along with the details of the current frame.

5) Run the rules of the tree wrt to current frame and fetch its output.

6) If there is only one transition then that is the final transition. If there are 2 transitions and one is default then ignore the default transition and use the other transition.

7) Return the template name of the transition to the angular controller and set the value of the page variable in the scope of the controller.

Using this approach all my services had to do was store data in different data fields wrt a particular action. All the complex if-else conditions for Web Flows or any complex process definitions(like the one defined in Spring-Web Flow) were not required. The MVEL rule engine managed all that and since it was all in the database it could be changed without needing a server re-start.

I believe this generic approach with MVEL is a flexible approach which comprehensively handles the problem of a convoluted flow without making the application code a mess or adding additional unnecessary xml files.