Welcome to lesson number 7, Rendering a View. We will be defining a Controller, not a RestController. Return types from controllers are interpreted as destinations and they're done that by triggering a ViewResolver based off whatever is on your classpath in order to locate a view in HTML JSP or whatever it may be. In our case, we will be rendering an HTML 5 View and we'll be sending data through to that View from our Controller via the DispatcherServlet and the request. Spring MVC is a web framework that uses both Controller and RestController beans to handle requests. A request comes into the DispatcherServlet, it is mapped to a RestController or a Controller through HandlerMappings. The DispatcherServlet uses the HandleAdapters to invoke the methods that the URLs are mapped to in the Controllers. It will convert parameters going in and responses going out, there'll be an ExceptionResolver in case something goes wrong. Return types from controllers are past the DispatcherServlet, they are considered not to be written directly to the response objects as we did with RestControllers, they are to be considered as a view and pass to a ViewResolver who will identify the view for the DispatcherServlet to dispatch to. Although we can inject the request in, set an attribute in the request, and ReturnString. We're very coupled passing in the whole request object. The return string here is going to be passed to the DispatcherServlet onto the ViewResolver and the ViewResolver because of our dependencies using Thymeleaf will say it's in templateshome.html. A different framework for ViewTemplates would look in a different location based off your POM dependencies. This approach also couple's after the fact that we're just using HTTP, which we probably are for most of the time, so spring provides an alternative just in case you move to a different protocol in the future, called the Model. It's a glorified map the DispatcherServlet always creates before delegating to a Controller method. Which means it's available for you to inject into your methods and your controller. Here's my GetMapping, my getAll and my Model's injected in. I don't need an annotation for this, it knows what model is. It's part of the web application contexts. Again, we returned home, so that's going to be our destination. But instead of dealing with the Quest directly, we're dealing with the Model and we're putting in an attribute employees. What's going to happen with this Model? Well, the DispatcherServlet has a reference to it of course, it knows where it is. It can get hold of it. It takes the state of the Model and puts it in the HTTP requests, takes the home string that we returned, passes it to the ViewResolver. It says we need to go to templates home HTML. Since we've now populated the Requests, it does a service side forward with that Request object to the view, and then it will render the view and return that to the client. The Request is available in the view, and therefore the data we put in the Model that went to the Request is available in the view. Where's the view, remember our dependencies in our POM be returned home. It looks under source, main resources, looks under the templates. There is our home HTML, that's where we're going to go. In our home HTML, when we start to reference JavaScript or Cascading Style Sheet, it's going to look in static. That's a static there will be the images CSS JavaScript files frequently makes up sub-directories of CSS, JavaScript and images, but it's under static. Now we saw how we inject it in the Model and we set an attribute in it. There is a convenience class called a ModelAndView that you can return from your Controller methods. As the name somewhat gives away, it has a means to add state into it is key-value pairs so I'm adding an object, employees getAll. I could add another one, and it also enables me to set a view name. This then is returned to the DispatcherServelet, and the DispatcherServlet says, I know what to do with the ModelAndView, I need to take the ViewName out and give it to the ViewResolver. I need to take the objects out and take those and put them in the Request. If you're just dealing with one object, much like I'm doing here that you want to put into the Model and hence the Request. You can use the convenience constructor of ModelAndView, which is the ViewName and then the single key-value pair. That is going to be the state of that convenience class. You could also inject the modeling as well if you really wanted and add things directly into the Model of the DispatcherServlet is really clever. It can say I've got a model with state in, I've got a modeling view being returned. No problem, I can deal with that I can populate the request and I know where to go because I'm going to have this off to the ViewResolver. Once the dispatcher receives, this is the view I want to go to. The Request is being populated. We can then render the view and give a response back to the client. If we go back here, we can see that we're sending back state in the form of a key-value pair of employees from an injected Dao. Dao was placed in the requests by the DispatcherServelet. You can see employees in this HTML 5 snippet get each employee and display it's firstName and lastName. You can see on my right, that the state is now being displayed on the view because it's available in that page. We're going to do a very small final lab here where we're going to get you to use a controller method to RenderView. We've kept this side of the course pretty small because primarily Spring Boot is used for RESTful services. But this does give you an idea that you could create a web application within Spring Boot and not necessarily rely on something else consuming your RESTful services as we saw with our angular front end previously. I'll let you follow the instructions, make sure your lab is set up for Maven. We will then walk through it and I'll see you on the other side.
