Top ten reasons to choose JSF not to choose struts

One of my clients doesn't know whether to use struts or JSF. As you might expect, I usually ask: what is the difference between frames in these 2? Of course, a lot of people are facing this option besides my client.

In general, I recommend that JSF be given priority in new projects. While there are often some commercial factors that force us to choose struts for our existing projects, and those solutions have yet to be tested, let us face the fact that JSF is much better than struts.

Here are ten reasons why I chose JSF over struts:

1.Components (component)

2.RenderKits

3.Renderers

4.ValueBindingExpressions (value-binding expression)

5.EventModel (Event model)

6.Extensibility (Scalable)

7.ManagedBeans (dependencyinjection Dependency Injection)

8.POJOActionMethods

9.jsfisthestandardjava-basedwebappframework (JSF is the standard framework for Javaweb applications)

10.There ' sonlyonestruts (only one struts)

10.There ' sonlyonestruts (only one struts)

Struts is an open source product, but JSF is a standard. This detail is often overlooked by new JSF learners, but it is obvious because we have multiple implementations of JSF. Although JSF is still immature, we have 2 excellent JSF implementations to choose from: Sun's reference implementation and Apache myfaces. On the other hand, we have only one struts.

9.JSFisthestandard (JSF is standard)

JEE5.0 to provide a JSF implementation, which suggests that JSF will soon be ubiquitous. This may have nothing to do with you, but it is closely related to the tool vendor. There are now about 50 Javaweb application frameworks, and tool vendors will not be willing to support a particular framework, but they will not hesitate to support a standard. And more than just suppliers, open source projects will quickly gather in JSF's four weeks, scrambling to achieve the same functionality. For example, I didn't know facalets until we realized a view that was essentially the same as shale's tapestry. (in the long run, I believe that this kind of redundancy is a good thing and will bring us benefits)

8.POJOActionMethods

The behavior of struts is tied to the API of struts, but the JSF behavior method can be implemented in POJPO. This means you don't have to implement an extra layer of behavior between the form and the model object. Incidentally, there is no behavioral object in JSF, and behavior is implemented in the model object. But also note that if you want, you can also generate a behavior object that is independent of JSF. In struts, you have Formbean and Actionbean. Formbean contains data and Actionbean contains logic. The Oo Maniac wants to merge the top 2 and you can't do it in struts. But in JSF, you can separate data and logic, or you can merge into an object, and it's up to you to decide.

7.ManagedBeans (dependencyinjection Dependency Injection)

Like spring, JSF uses a dependency injection (DJ) (or a control reversal (IoC)) to instantiate and initialize the bean. Struts did generate Formbean and Actionbean for you, but JSF can generate a variety of managedbean for you.

6.Extensibility (Scalable)

This is very important. JSF has 6 objects that implement most of the functionality of the framework, and you can easily replace the original implementation with your own implementation. For example, you want to add a custom parameter in the JSF expression language, or add a view controller of your own to make it easier to differentiate between components and HTML. In fact, shale implements the above function. If you're not satisfied, JSF offers a few places where you can easily control the JSF lifecycle. Shale will give you more.

5.EventModel (Event model)

The JSF event model allows you to react to value changes, actions, JSF lifecycle phase transformations, and so on. In JSF1.1, those events are handled on the server side, which is certainly a flaw, but the JSF2.0 plan to support client events is to wait and see.

4.ValueBindingExpressions (value-binding expression)

In struts, you are responsible for passing data from form to model objects. The Execute method of the action you implement is to take the form as an argument. Then you manually remove the data from the Formbean and put it inside the model object. You have to do these things for each form in the application, but in JSF you just need to be like this: #{model.property} is enough, and the others are handled by JSF.

3.Renderers

Have you ever seen the source code for struts labels? It generates HTML directly. The JSF component label does not generate anything, and it corresponds to a pair of component-renderer on the server. Component maintains the component State and rendered is responsible for obtaining the view. The point is that renderers is pluggable, that you can implement it according to your own needs and then replace the default implementation. For example, I nfjs the Felix conversation above to illustrate how to implement a custom labelrenderer. All you have to do is configure your RENDERER,JSF to automatically use it in your application.

2.RenderKits

A few years ago I had a struts consulting job and we had to support both browsers and wireless devices, which was very painful. But it's very easy to do that with JSF, because you can generate your own renderkit-as a set of renderers for a particular display technology-and then configure it into JSF.

1.Components (component)

Components are the biggest difference between struts and JSF. Like swing, JSF provides rich underlying artifacts to develop components and then add to the standard set of components. Those low-level artifacts make it easy for you to build your own components and share them with others. Now we can see the custom components popping up everywhere, like Oracle's ADF and Myfaces, both of which provide a rich set of components, such as JavaScript calendars, tree, and so on. Of course, components are just a part. Typically, the component corresponds to an independent renderer, which gives us real benefits (see article 3rd). But like many things in JSF, you don't have to be in the rut. As long as you want, you can implement render your own components, though you will lose the ability to add other renderer to your component.

There are a lot of things can not be explained, such as renderer. If you don't translate well, you can go and see the original. Originally from Davidgeary ' Sblog, the original address is: http://jroller.com/comments/dgeary/Weblog/

Source: http://blog.csdn.net/cqluojia/services/trackbacks/