In the previous section, we created a simple flow with passages. Here we will develop the code from the previous section by enriching it with a few elements that will help us improve the program. What we want to achieve:

  • Add an item that will check if the user of this email is already subscribed to the newsletter. If it turns out that it is, then redirect the view informing it.
  • Add a summary page showing all the data and thank you for subscribing to the newsletter.
  • Add a second flow that will allow you to register your store account, but this time you will see more views.
  • Make one global final state indicating the correct end of the flow without having to define a transition to it in each successive state in case you press the “cancel” button in some state.
  • Add a subfeature that will run when the user enters a promotional code.


We start with the task: ” Add an element that will check if the user of this email is already subscribed to the newsletter. If it turns out that it is, then redirecting the view informing about it. “

To our previously created DAO, I add a new method, which is supposed to check if the user with the given email address already exists or not yet. We do not play here in the database course, I just checked whether my email or some other. If someone gives an email address , the method returns “true” telling the existence of such a user.

Let’s now go to the flow configuration file. Let’s look at line 13. Previously, if the form was approved here was redirected to the “save user” state, now it is redirected to the new state – “instance”. This is a decision state. Depending on the conditions checked, the flow may go in quite different directions. Our decision state (lines 17-22) checks if the user with the given email address already exists or not yet. This is done using the DAO userExists method (this dao was declared as bean in the previous chapter). To the userExists method, we pass the contents of the email field from the complement of the object that was completed during this flow. Depending on whether the method returns true or false, we will be redirected either to the “userName” state or to the “save user” state.

In case the user has not yet found it, then the case is so simple that you just go to write the object. However, if you find that you already have a user with this email address, you should display an informational page. So now we will look at lines 24-26. We have another view state here.

For this moment as the view, I gave “userIstniejeForm”. We did not create it before, temporarily added such entry to anything here. We will create a view layer. Note that here I also pass the object to the model (the one that we complete the flow). For what? Because I will want to reach its contents in this view – specifically to the email address. In line 25 we get a new event – return. It will be triggered by the already known structure when someone clicks on the new information page “return” link. In this case, you will be redirected to the “newsletter” state of our form.

Now let’s go to the view layer. I created the above file “userIstniejeForm.jsp”

An email supplemented during the user flow, that is, directly to the email that we typed in the form (explaining the model parameter in the new view-state). Line 12 is a well-known call-to-action design. This time it is an action called “return” which according to the records in our flow configuration file will return to the form. Let’s look at the action. I complete the form and approve.

Called in our decision state, the method verifies that the user with the email already exists and moves to the state of the “userName” view.

Clicking the “Back” link triggers a “return” action and therefore returns to the fill form.

Now it works so that after completing the form we return to the start page.