What can we use Spring WebFlow for? This module allows you to perform multi-step flows – something like installation wizards. We can create a multi-page registration form in a relatively simple way.

In this chapter, we will start by adding two very simple functionalities for the needs of the online store. One will allow you to sign up for the newsletter, the other will set up a store account. We start by creating a regular Spring MVC application. Nothing new or extraordinary is here, but I will highlight some key elements:

Web.xml entry:

All subpages of this application with extension .do will be supported by Spring.

To ***** – servlet.xml you will need to add namespaces associated with Spring WebFlow, so we’ll do it right away:

More specifically, I want to add a namespace:

xmlns: Flow = “http://www.springframework.org/schema/webflow-config”

and its position:

WebFlow requires additional libraries, so besides what you usually add, you will still need spring-web flow, spring-binding and springframework.js libraries:

All three jar files are located in the project libs directory that is included with this article.

I also add the most common in the world controller with one method mapping address “/start.do”:

I have added two links to the JSP file that supports this request:

And now it will start … In the **** file – servlet.xml we have to add some essential elements. For the needs of at least one flow, we have to have all the configuration I put in my file on lines 29-63 … We will discuss the variable elements that will vary in different applications.

Let’s start with the flow that will bring you to add your email address to the newsletter. A little later we will expand our project.

Each flow will have a separate configuration file in which we will describe what is to be run and under what conditions. We register these configuration files in the flow-registry section (lines 51-53). The parameter ID is very important here because it is associated with a so-called flow trigger. If the address of our form is /newsletter.do, WebFlow will search the register for the newsletter id if the registration address of the store account is /registration.this will search for the registration id. Only the “tip” counts, the triggers themselves may be in the form of /modul1/newsletter.do.

This triggering address means the beginning of the flow – in this case, the registration of the newsletter.

As you can see in the flow log for the id “newsletter” I pointed to a newsletter-flow.xml file located in the / WEB-INF / flows directory. So we create a subdirectory flows in WEB-INF and put in it an empty file called newsletter-flow.xml.

Inside this file we put this configuration:

Every element here is one “step” in our flow. This step can be to display the page, perform some action, make a conditional decision. Each flow must have exactly one start state and at least one end. They are the first and last step in the flow. Between these steps we can add another, nothing is in the way. In our mini project in this flow will be only two steps. One is the display of the form to which we enter our email address, the other is the final status which simply redirects us to the start page. A little later, we will make sure that, depending on whether we approve or cancel the form, a message is displayed.

Let’s look at the element in lines 11-14. It means to display a jsp page called newsletter form (which should be in WEB-INF / jsp – as configured in the bean with the viewResolver ID in the **** file – servlet.xml). Note that this element also has a “newsletter” id. This is the initial state, which means that the newsletterForm page will be displayed as the first step in this flow. There are also signs here <transition on = “x” to = “y” /> What does this mean? If you are (for now not specified) “SEND” the name “approval”, the control is to be redirected to the “added” element. If the same “SEND” appears with the name “cancel”, the control is to be redirected to an item called “canceled”.

This is “whats” are messages sent from the view and we will take care of this. At the moment, let’s look at the elements of line 18-21. There are two possible end states. Both now do the same thing – they redirect to the start page. Which of the end states will depend on whether the message is “sent” or “canceled”?

Let’s now go to our “newsletterForm” view file which is displayed in the first step of our flow. Soon we will see the fields to which we will introduce data, now we are interested only in the flow as such.

Maybe wondering the strange address of the link I gave. Let’s start with the left. Appears here

$ {flowExecutionUrl} – thanks to this fragment we return to the flow in which we are. This tag is visible in the address bar:

Next we have a mysterious string containing _ eventId = commit, and the other _eventId = cancel . I think when you look at the following configuration file for this flow, it will all become clear:

But if you do not drink morning coffee, then I explain – this is our “CODE” that triggers the transition to the next state. But what state? In the first case to the state called “added”, in the second to the state called “canceled”. Now, look at the part of the newsletter-flow.xml file below:

Clicking these links will move you to the end states of the flow. Of course, one could give here another state – even another view. Everything is cool, but a bit weak signing up for the newsletter, if we do not provide your email address

Let’s now enrich our application with the object in which we will collect data about the user. The victim will be the class object we have to create.

My class contains four simple fields. They are not included in the show, but the class also has getters and setters for these fields. Class must be serializable.

I also add some fake knife to the objects of the class of the victim. The save method accepts the user object after filling in the form and returns the ID where the object landed in the database. Here is some “rigid” value so that we do not have to complicate our lives with database-related issues. There is also a print method that takes a user object parameter and writes its contents to the console. Of course, in no normal DAO, such a method would not appear, here it is only for the purpose of presenting the flow of work.

Since I am about to refer to a class object of the Drake class method in a flow configuration file, Spring needs to know what this is for Drake. Therefore, we declare this class as a bean in the file *** – servlet.xml:

Let’s now go to the flow configuration file. Here are some new things:

An item marked 1 is a variable that will be visible throughout the entire flow. Spring will create an object named in the “name” parameter of the class specified in the “class” parameter and place it in the flow. Our newsletterForm view has gained a new colleague in the form of parameter model. Note that the name of our new variable is here – the user. In the form we will supplement the field of the object – so it would indicate that.

Without this add-on, in reality the flow will work (in the sense there will be passages and no mistakes) but the filled fields will go into space and the object at the end of the flow will remain empty (organoleptically checked). In line 13 there is also a small change – the transition does not go to the final state and into the “save user” state that has just appeared. Action-state means the execution of some action-method call, not a view-state view of a view. Let’s look at this element now. “Evaluate expression” indicates the method to be executed. This is a “save” method from the class object userWhen the bean was added to the **** file – servlet.xml. For this method, the object is passed as a parameter to the user … which we defined before

It is an object that we, as part of our flow, supplements. In our form which is supplemented, we added the fields of this object. In this step we pass it to the method to save it in the database. This object is already supplemented by the values entered by the form. This also shows the result. The object that we write will land in the database under an identifier, and this identifier is returned by the save method. It will be useful for later displaying, or for example, hooking up another object under this one. The result will substitute for the id of our flow object the value returned by the method invoked in the evaluate expression. Action-state, after executing the expected operation, passes the control to the “printout” state. The print status of the user is the state of the action that calls the dao method written and passes the completed object to the view. Further flow is passed to the final state added.

In conclusion – the first state is the view state that displays the form from the newsletterForm.jsp file, using which we suppose the object that is visible in the entire flow. Once the form is validated, the “save user” action will be written to the database and added to the id field where it landed in the database. The control is passed to the “printout” state which on the console prints the contents of the object and passes the control to the final state that redirects to the start page.

A little change was also made in the form itself to fill in the data.

In lines 2-5 there were imports into the tag libraries we use. You must have it, otherwise the form will not work. Elements from lines 21 and 22 are already familiar, but we’ll leave them for comparison with the 17th and 18th line elements that will replace them. Let’s start from the beginning – line 12. <forms: forms …. in principle means the beginning of the form, </ form: form> its end. All input fields must be between them.

In the opening tag, the parameter commandName = “victim” is displayed. Certain suspicions about what this is like, should already be slipping yourself. This is an indication of the object that we will complement, more specifically, the User object class that we declared in the flow configuration file. After all, we have several declarations <var …. />

<form: input path = “field name” /> refers to the fields of this object. In short, these are text boxes to complete the fields name, email address in the object of the victim.

Lines 17 and 18 are buttons. One will approve the form, the other will cancel. More precisely – they will trigger the action that we declared in the flow configuration file. Pay attention to their names. To fulfill the assumed role, they must consist of _ eventId _ elements and our triggering transition to the next state.

If you look at the elements of “transition on …. This is … I think you will not need to explain anything more. Links already made (lines 21 and 22) can already be deleted.

Since we have all the elements, let’s see how it works. We begin the flow by going to the newsletter.to:

We are in the first condition. This is the status of the “newsletter” view. I complete all fields:

Upon approval, the “commit” event is triggered, which causes the “save user” action.

The first line comes from a trigger called “save user”. As you can see the data entered by the form, but the id field remains blank. This is supplemented by the “save user” action. Then the action comes in “PrintUser” which presents us on the console already completed with ID data. The last line comes from our front-end backbone where the flow was redirected by the end state.

Previous articleVariable paths
Next articleDecision-making