JSF (Java Server Faces) is a representation layer technology currently specified as a VIEW layer standard. The current version is 1.1. Struts is a more wide open source MVC framework. There are many people used in China, and the current version is also 1.1. The author is working on a project framework, so these two technologies have been studied. I intend to make a pair and analysis of the knowledge you have mastered. Because it is a beginner, there may be incorrect or incomplete places, I hope everyone can actively discuss and correct. It is said that the main person in charge of JSF is the main authors of Struts, so there are still many similar points.
TAGLIB is used to handle the representation layer: In the JSP page, both use a set of tag libraries to handle the page representation and the MODEL layer interaction. Both use the bean as a Model layer corresponding to the JSP page. The MODEL layer saves data on the JSP page, and you can do some verification work. In Struts, FORMBEAN is FORMBEAN, in JSF is Back Bean. Both beans are used as the control layer. The ActionBean is used in Struts to handle business logic. For simple applications, the business logic code can be written directly in the ActionBean, or call additional beans or EJBs to handle business logic; for JSF, BACKING BEAN is used To handle business logic, the BACKING BEAN can also directly write business logic or call other beans to handle business logic. All issues with XML configuration files are used to process the configuration of beans, page navigation, and other issues, increase the flexibility of the system. All resource documents are used to handle international and localization issues. However, there are many different points of the two, and below shows:
First of all, the side focus is different, and Struts focuses on the control layer, focusing on how to assign and process the user's request, so the TAGLIB function of the layer is not strong enough. The JSF focuses on the representation, realizing a large number of standard components, allowing developers to have more control over the representation, and JSF implements an open architecture, allowing developers to create their own components, or in existing Inherited on the component, developing a more powerful component. I think this is a biggest feature of JSF. (A bit similar to the VCL and .NET components) and the MODEL layer corresponding to the JSP, use FormBean in Struts to save the data entered by the user, and the type of the substantially field is String. And you can perform simple verification, of course, if dynamic FORMBEAN cannot be verified in the FormBean. In Struts, JSP and FORMBEAN are closely combined, as long as you write a JSP, you must correspond to a FORMBEAN, and each component on the JSP corresponds to the field of the same name in the FORMBEAN. I think it is not too flexible, for example, when the development page must consider the implementation of the background's FormBean, if this page does not have FORMBEAN, the program will be wrong. In JSF, the components in the JSP page are associated with the field attribute and the field of the backing bean, so there is a relatively large flexibility, each component on the page can correspond to the same BACKING BEAN, or the different backing bean (of course I believe that in general applications, the components on a page should still correspond to a backing bean), and when the design page can be designed, the backing bean can be considered after designing the page after designing the page. problem. With regard to data verification, Struts can be verified in the verification function in the FormBean, or use Validator to verify (regarding this verification method, I have not tested, I don't know how the effect, I hope to have experience "."). In JSF, some standard Validator is available. You can do some simple verification on the input data, such as the range of validating value data, whether the field is required. But its verification feedback information is in English. If the information cannot be customized, then it is not suitable for domestic applications. At present, I have not found the feedback information to be customized. In addition to components of the Input type can be associated with a validation method of the backing bean via the Validator property. It is also a way to verify in an event processing method. There is also a problem in JSF is that in the page generated by JSF, the component's ID naming is weird. All the IDs of all components are similar to "form: componentid" name ":" component ID. This is not very convenient to access components through JavaScript, which seems to be unable to access components via form.id. I don't know if you have a good solution.
