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