We will make the easiest possible form for adding cars. The structure of the configuration files is the same as in the previous chapters, so I will go to the right part, ie what you need to create and maintain the form.

We start by creating a domain class – that is, the class whose objects will represent the cars added.

The class has three fields that we will complement through the form. The fields are private because there are also setters and getters available in the classroom. We must have this because of Spring’s requirements. The overloaded toString method or the constructors shown below are not required. I created them only for my own convenience in later work.

Now let’s go to the controller class:

Spring supports addresses starting with “/ forms” – web.xml configuration issue. The controller class itself therefore supports: / forms / form

This is class level mapping discussed in earlier chapters. The controller contains methods that will handle this particular call address, but one of them if it is a POST request, the other two GETs – but only if there is an additional parameter. There is no problem, of course, that each method maps a separate address. This would remove the mapping at the class level and add the value parameter to the @RequestMapping annotation of the appropriate methods.

Let’s start by looking at the view from the method in lines 33-38. Since we have to map at the class level, in @RequestMapping for this method I add only the method call – GET. So when someone calls an address/forms / form without any additional parameter, this method will be called. To the model, I add a car brand “Skoda”. This object, called “car”, is passed to the view layer and displayed there. From this, it follows that if someone calls an address/forms / form without a parameter, the fields in the form will be supplemented with information about our sample Skoda. As the JSP page, I want to use to display the form, I chose the form.jsp file whose name I am returning to line 37.

Let’s compare this method with the viewNewForm method from line 27-31. Due to class-level mapping, this method supports the same address (/ forms/form), but since we have params = “new” it will only be called if the new parameter is passed by the address bar. So if you call the “/ forms/form” address, you call the previous viewForm method, and if you call the “/ forms/form” new “viewNewForm method. In the first case, a new car with completed data is passed to the model and the new empty object in the second. Both methods are supported by the same JSP page.

We will return to the post method after the form is discussed because it is called after the approval. Let’s look at the contents of the form.jsp file that supports our form:

You need to have a reference to a tag library like mine on line 2. I often forget about it and then wonder why the form does not work. The correct form is lines 11-18. The entire form must be enclosed in <form: form> and </ form: form> tags.

I do not think it is surprising for people in contact with the basic HTML :)As you can see in line 11, the form supports sending data by POST method. However, there is no “action” tag …

This means that the form data will be sent to the same address at which we are now, except that the call will be POST. The “modelAttribute” parameter specifies the name of the object whose fields we will fill in on the form. Take a look at lines 29 and 36 on the controller. The object name must overlay here. Go back now and look at the cars in the class Car that I declared a few steps earlier. Now, look at lines 13-15 of this form. As you can see, the following input fields have a “path” parameter whose value must match the names of the model object fields passed to and from the form. In addition, these fields must have getters and setters to be able to reference them.

Depending on whether the transferred object will be supplemented with data, our input fields will be supplemented or not. It all depends on the content of the object passed to the view under the name indicated by “modelAttribute” on line 11. Line 17 is the usual form validation button.

Let’s recall now how to call the view from and viewNewForm methods.

Compare the call addresses and see what appears in the edit fields. Now everything should be clear;)

The form approval support remains. Let’s go back to our controller for a moment:

The POST method is used to handle POST. The object previously passed to the model, then filled in the form and then returned to the post this method by the parameter. The name of this method parameter does not have to match the name in the model truth.