Time to add a second flow, this time to set up an account in our online store. You will need to provide your name, contact details, address, invoice data etc. Totally transparent and comfortable it will be if we do it on one side. It’s better to break it down into several stages. Separate sub-title to name, separate to contact data, address and separate to invoice data. The flow will be one, but during this time we will complete one object.

We start by editing our **** file – servlet.xml to register a new flow. New entries marked in red. I added the address of the start page of the flow – account.to, and the name and location of the configuration file of the next flow – the account-flow.xml.

Let’s look at our flow configuration file.

The flow is relatively simple because it is limited to four consecutive states of view and at the end of one state of the action that saves the new account to the database.

During this flow, we will complement the object of the Account class. We’ll be back in a moment, now let’s look at the other transitions of this flow. Each of the views will have three buttons – go back, cancel. The first moves to the next step, the second to the previous one and the third cancels the entire flow and returns to the start page. All view states have a declared model parameter – we will supplement the object, so these states must have access to it. Note that in each successive state we have a declaration like this:

<transition on = “cancel” to = “start” />

Declaring the cancellation step at every step is at least tiring. What if we wanted to change the state to which the flow goes after clicking “cancel”? In the next steps, we will declare a global transition and we will not have to declare this transition in each state.

The flow consists of three forms and one summary view. In the first form, we complete the contact details and account information, the second delivery address, the third invoice data. In the summary view, we see all the data that we have completed and we can possibly go back and correct something.

Throughout all stages we complete the class account, so let’s take a look at this class.

Of course, there are also getters and setters in those classes. We see here the objects of the Address and DataDocuments classes.

Note that in the fields that are objects we have to use the default constructor. For simple types I do not do that. This must be because Spring creates a new class object that we declared as a flow variable but does not do it for “subobjects.” If we do not reinvent them ourselves, we will get an error when trying to access their fields. Let us also see the declaration of the method of recording which I call in the state of “save” our flow. As you can see it is a plug – we do not deal with Spring integration with databases.

This means that we must have yet declared bean to this class in the ***** file – servlet.xml:

Let’s now look at the view layer, our forms and the summary page. Form 1 (step1) is used to supplement your account and contact information. Traditional input fields to fill in the immediate fields of the class object Account and buttons that I mentioned earlier:

Take a good look at the parameters “path” … This is how we refer to the subobjects and their fields. The third step is to add data to the invoice. We see references to even more nested subobjects.

Here is a standard way to display data from an object using the “$ {object.pole}” method. We display data supplemented at all stages. We can do this because we are working on a single Account class object initialized at the beginning of the flow. We refer to fields, subobjects, subobject fields exactly as we do for servlets – in the end we do it with JSTL tags. Buttons like before, but we all know that this is a summary page, there is no form here. So what are the “<form: form>” tags doing here? Without them, our buttons would not work because they approve the forms! Otherwise, we would have to replace them with links.