Well, I'm on the mend now, not entirely mind you, so I figure I would get back to JSPs.
You might remember waaaaayyyyy back when I talked about servlets? Well today, what I'm going to cover real quick is creating a servlet that will forward us to another JSP.
Basically, what the servlet will do when you try to access it is "forward" the request. That's pretty much it.
So the overview is this, index.jsp will have a link that will send us to to ContactKeeper/App servlet. The servlet will then send us to the welcome.jsp page.
The servlet will become the main hub for our application. Basically, anytime we click on a link within the ContactKeeper application, it will just basically send us back to the ContactKeeper/App servlet.
In fact, let's skip the coding for now, I will get to that tomorrow. For now let's learn a little theory.
The reason for this, primarily, is so that our application logic can be stored in the Servlet code. Our display logic will be stored in the JSPs that we create. This separation is the starting point for something known as Model-View-Controller or (MVC) for short.
Like I said we created beans so that we store data logic in Java code outside of the JSP. Thus our JSPs focus more on just display and page control and the beans deal with storing the information.
At the moment our beans don't do much, they just store the information in memory. However, we could easily change that so that we store the data in something like a database.
Our JSPs handle page control at the moment which is basically done via tags which is standard HTML stuff. However, this pretty much leaves us in linear mode for page logic, which granted for an address book, you don't need a whole lot of logic.
However, what if we needed more powerful logic? Javascript? No way! Putting Java code in the JSP? No way! We're trying to get away from that. The goal would be to allow some piece of Java code decide where the application should go next based on the current session's values. Enter the Servlet as the central hub.
To get an overview of what this looks like, here is a rough draft of what we will be doing. (Shout out to http://www.draw.io, you all rock!)
 |
| Quick overview what exactly we will be doing. |
The servlet can send these request for data to the Data Access Object (DAO). The DAO will handle all the little details about the actual data, so the servlet may ask to add a contact. The DAO will actually know how to do this. The DAO sends back to the servlet a pass or fail result, and then the servlet will forward the request to the proper JSP.
The servlet will pass to the JSP an entry point in the DAO to see the detail results of what was requested. (Why a name couldn't be added, the name has been successfully added, the listing of all contacts, etc...) The JSP will use that entry point to display the results from the DAO.
As you can see each section is concerned with one part of logic. The Model deals with handling all of the data ins and outs. It creates data, removes data, and so on. It is the data handler.
The Controller makes sure that everything happens in a controlled manner. If the model says that a name cannot be added, the controller forwards the client to the error page. However, do note, that the Controller doesn't actually check to see if the incoming data is valid or not, that is the job of the Model. The controller simply passes the data to the correct department to be handled and if the data is invalid, let's the user know that.
The view is what our users see. It is primarily concerned with displaying what is going on and what has been requested. The view presents all the forms our users will be entering and formats all of the data for the user that is sent to us from our Model. Forms that get filled out and submitted are sent to the controller for processing, from there the controller may delegate the processing of a form to some other subsystem and so on...
So while the MVC architecture looks a bit confusing at first, it provides a method for separating the major functions of a web application into manageable bits. Each bit is pretty independent of the other.
For example, we can change our JSPs to have a new style without messing up any of the navigation code or how we access a database. We can change our system from a in-memory style system to an actual database so long as the DAO keeps the same interface for the controller to call. We can implement a new navigation scheme by changing the controller, without messing up our JSPs or our data access.
The ability to break into independent pieces is a requirement for service flexibility.
You might notice that in my model I have the DAO using data beans and direct access. Using direct access is sometimes a necessary evil in models. Especially if your data requires a lot of calling stored procedures to get the data. However, I recommend that you try to limit as much as possible "direct access". Use data beans as much as possible, eventually I will get to entity frameworks and what ORM means, and this is like data beans on database steroids.
Okay I know I talked a whole lot and didn't give much code. I'll do that next visit. I'm just not strong enough yet to really do one of my go for the gusto posts where I talk forever and then code forever. Maybe when I get over the flu completely I will come back to the twenty page posts.
cheers!
No comments:
Post a Comment