Java advanced: top ten reasons for choosing JSF not to select struts

Http://tech.ccidnet.com/art/3539/20080129/1356639_1.html

Top 10 reasons for choosing JSF not to select struts
One of my customers does not know whether to use struts or JSF. As you expected, I usually ask: What is the difference between the frameworks in these 2? Of course, many people except my customers face such choices.

In general, we recommend that you prioritize JSF in the new project. Although there are often some commercial factors that force us to select struts for existing projects, and those solutions are still to be tested, let us face the fact that JSF is much better than struts.

The following are the top ten reasons why I chose JSF instead of struts:
1. Components)
2. Render kits
3. renderers
4. Value binding expressions (value binding expression)
5. event model)
6. extensibility (scalability)
7. Managed beans (dependency injection)
8. pojo action Methods
9. JSF is the standard Java-based web app framework (JSF is the standard framework of Java Web applications)
10. There's only one struts (only one struts)

10. There's only one struts (only one struts)
Struts is an open-source product, but JSF is a standard. This detail is often ignored by new JSF learners. In fact, this is obvious because we have multiple JSF implementations. Although JSF is still immature, we have two excellent JSF implementations available: Sun's reference implementation and Apache's MyFaces. On the other hand, we only have one struts.

9. JSF is the standard (JSF is the standard)
Jee 5.0 will provide a JSF implementation, which indicates that JSF will soon be everywhere. This may have nothing to do with you, but it is closely related to the tool supplier. There are about 50 Java Web application frameworks. Tool vendors are reluctant to support a special framework, but they do not hesitate to support a standard. Besides suppliers, open-source projects will quickly gather around JSF to implement the same functions. For example, we don't know facalets until we implement a view similar to the tapestry of shale. (In the long run, I believe this redundancy is a good thing and will bring us benefits)

8. pojo action Methods
The behavior of Struts is bound with the struts API, but the behavior method of JSF can be implemented in pojpo. This means that you do not need to implement a redundant behavior layer between the form and the model object. By the way, there are no behavior objects in JSF, and the behavior is implemented in Model objects. However, please note that you can also generate behavior objects independent from JSF if you like. In struts, you have form bean and action bean. Form bean contains data while action bean contains logic. OO will want to merge the first two, which you cannot do in struts. However, in JSF, you can separate the data and logic, or merge them into an object. It is up to you to decide everything.

7. Managed beans (dependency injection)
Like spring, JSF also uses dependency injection (DJ) (or control inversion (IOC) to instantiate and initialize beans. Struts does generate form bean and action bean for you, But JSF can generate various managed beans for you.

6. extensibility (scalability)
This is important. JSF has six objects to implement most of the functions of this framework, and you can easily replace the original implementation with your own implementation. For example, you want to add a custom parameter to the JSF expression language or add your own view controller to distinguish between components and HTML. In fact, shale implements the above functions. If you are not satisfied yet, JSF provides several places where you can easily control the JSF lifecycle. Shale will give you more.

5. event model)
The event model of JSF allows you to respond to changes in values, actions, and JSF lifecycle stages. In jsf1.1, all the events are handled on the server. This must be a defect. Fortunately, jsf2.0 plans to support client events. Wait and see.

4. Value binding expressions (value binding expression)
In struts, you are responsible for transferring data from form to model objects. The execute method of the action you implement is to use form as a parameter. Then you can manually extract the data from the form bean and put it in the model object. You need to do these tasks for every form in the application. However, in JSF, you only need to do the following: # {model. Property}. The rest will be handled by JSF.

3. renderers
Have you ever seen the source code of struts labels? It directly generates HTML. The JSF component tag does not generate anything. It corresponds to a pair of component-Renderer on the server. Component maintains the component status, and rendered is responsible for obtaining the view. Renderers is pluggable, that is, you can implement it as needed and replace the default implementation. For example, I explained how to implement a custom label Renderer IN THE Felix conversation on nfjs. You only need to configure your Renderer, and JSF will automatically use it in your application.

2. Render kits
A few years ago, I had a job in struts Consulting. We had to support both browsers and wireless devices, which was very painful. However, it is very easy to use JSF to complete that task, because you can generate your own render kit-a set of renderers for a specific display technology-and then configure it in JSF.

1. Components)
Components are the biggest difference between struts and JSF. Just like swing, JSF provides rich underlying components to develop components and then add them to standard component sets. Those underlying components make it easy for you to generate your own components and share them with others. Now we can see custom components jump out everywhere. For example, Oracle's ADF and MyFaces both provide a rich set of components, such as JavaScript calendar and tree. Of course, components are only a part. Typically, components correspond to an independent Renderer, which brings us real benefits (see article 3rd ). But like many of JSF's things, you don't have to stick to the rules. As long as you want, you can implement render's own components, although you will lose the ability to add other Renderer to the components.
(Edit responsibility: BAO Chunlin)