On the way to componentization (2) -- What problems does JSF solve?

First, let's take a look at some problems encountered when using struts and other frameworks for development:

1. From URL to Action B and S is HTTP. What we can express in http is only a URL and several string format parameters. Therefore, in any business development process, we need to map the previous URL + parameters to the backend business methods. This is boring, and there is no technical content. It can be regarded as physical activity-but it has to be done.

2. to request a page to display data, you must first prepare the data for Action and then forward it to the page. This is completely different from the previous jsp + javabean development or asp development, the latter is actually your request for a page, so you first arrive at this page, and then do something like preparing data during the processing of this page. I think the latter method is more natural.

3. When the backend does not know what request is sent from the front end to the backend, the application server packs the HTTP request as a request object and places all request Parameters in it. Therefore, when the backend receives a parameter, we do not know what html elements the parameter corresponds to at the front end. This problem is particularly prominent when handling the input in the drop-down box. When writing a page, we define the option element below select to tell the application that only one of the several options can be selected, and then to ensure that the data is correct, at the backend, we still need to check whether the user input is one of those options. This is equivalent to the allowed range that we tell the system twice. Why can't I do it only once. In the previous development process, the backend does not know what the frontend has.

4. The stateless Action layer in the past development, another important issue is about the status. HTTP is a stateless protocol, so HTTP-based jsp and struts are also stateless. What is stateless? A typical manifestation is that a piece of data that is queried during your first request is as follows, cannot be found (we can't simply put most of such common data into the session/application Scope ). This means that in the Hibernate scenario, in order to update an object correctly, you need to query the database again when submitting the form to obtain this object, set the attributes modified by the user to the object and save the changes. At the same time, in order to achieve Optimistic Locking, you need to send the version information to the client in a form-if the client returns a fake, very high version number to you, then your optimistic lock is like a false one-two people open a record at the same time, and the person who submits the record can completely overwrite the submitted result of the previous person without anyone's knowledge.

JSF/seam solves these problems for us. Based on JSF, I used Spring to replace Seam, which can also solve these problems.