Response to Sebastian Hennebrueder's JSF2 Evaluation and Test entry Blog
Back in November, Sebastian Hennebrueder published a detailed, thoughtful, and mostly objective analysis of JSF2. I'd like to use this entry to respond to his entry, which may be found at http://www.laliluna.de/jsf-2-evaluation-test.html. I have excerpted the parts of his article that pertain to my comments here.
| JSF 2 - evaluation and test |
IntroductionJSF is a standard to implement Java based web framework. There is a reference implementation of the standard, Mojarra JSF...
[...] Add the following libraries to the build path of the web application.
The deployment approach for JSF libraries is slightly picky. Glassfish provides already JSF 2 libraries. You may need to update them using the update mechanism of Glassfish. Just search for ?glassfish JSF2? to find more... [...]
Modify the web.xmlThe Servlet class FacesServlet starts the JSF request processing life cycle and must be defined in the web.xml. The servlet mapping tag defines the for which URL the FacesServlet should be executed. The pattern /faces/* is commonly used by the JSF specification but any other prefix or extension is possible. The example uses as web-app attribute version=?2.5? this means we are using servlet-api version 2.5. If you use tomcat 6 we need minimum servlet-api in version 2.5. Compared with jsf 1.2 nothing changed in this example. edburns: If you are on Glassfish v3 final you don't even need a web.xml at all. The /faces/* and *.xhtml url-patterns are mapped by default to the FacesServlet. Also, if you're using Glassfish V3, please set the version to 3.0. Below you can see the web.xml... [...] Technical detailsThe following diagram shows all places where events listener are called. The diagram is slightly simplified. The FacesServlet is the entry point of the JSF application. It calls the lifecycle, which in return executes the different phases. Every phase calls global phase event listener before and after the actual work is done. Sample: 3 and 4 in the RestoreView phase. PhaseEvent listener can be defined per view as well. These listener are called by the root component, UIViewRoot. This happens in the diagram for example at 9 and 14. FaceEvents (alias Application events) are broadcasted by the UIViewRoot component. This happens in every phase. Sample: 12, 21, 28, ? edburns: This sequence diagram is excellent! System events are broadcasted immediately at various points in JSF. Just search the source code for publishEvent... [...]
The second problem of standardizing is that a standard is a compromise and it progresses very slowly. A compromise does not include very innovative or individual features and needs to ensure that it doesn't change vertically. Changing vertically means that it adds more responsibility as it had before. In JSF 1.x Ajax behaviour were not defined. Every component provider solved Ajax requirements differently and now JSF 2 introduces its own mechanism. edburns: This mechanism was designed by the component vendors who built Ajax components for JSF 1.2. The point of the standard jsf.js file is that those vendors will be able to drop their proprietary JavasScript code and use the standard one, thus allowing component interoperability. There is a fair chance that components... [...] ComponentsJSF offers two types of components: composite components and the classic ones. Composite components are introduced with JSF 2. I would call it a snippet instead of component, which allows to render a number of components using a single custom tag. I think that it is a mistake to introduce a new component approach and to leave the old heavy components which have quite a number of contracts to follow. edburns: As you point out, we are committed to backward compatibility and wanted to allow JSF 1.2 style components to work. More importantly, composite components build on top of the infrastructure of 1.2 style components. Composite components are of course a great help... [...] edburns: Doch, every composite component has an optional "top level component" which can be in Java or in Groovy. This top level component is an actual JSF UIComponent and has access to all of its children component declared in the XHTML. Furthermore, it can override any of the UIComponent methods to take special action in the lifecycle. Writing custom components is frequently... used to ensure a consistent look and feel in [...] large enterprise application. Modern frameworks like Google Web Toolkit (GWT), Tapestry or Wicket try to make this as simple as possible. As a consequence, it is a common and frequently task for developers using those technologies. In JSF writing of components is a job for experts only. In fact most people use only finished component collections and would never write a component themselves. In my opinion, this is one of the strongest weaknesses of JSF 1.x and it is not fixed with JSF 2 and as the JSF interest groups are mostly industry companies preferring backward compatibility over efficiency and innovation we won't even see it fixed in any JSF version.
edburns: You depart here from your normally objective analysis to make opinions about the difficulty of building components in JSF2. Composite components ARE true JSF UI components. They have properties, methods, events, can support listeners, converters, validators and facets. They can be as simple as a single XHTML file, or as complex as to involve CSS, Script, and Ajax. ScopesJSF introduces now a flash scope... [...] ValidationThe validation can be ajaxified with the new<f:ajax> tag. Leaving an input field will validate the input for that field. An Ajax request is sent to the server, which causes a partial processing of the input element. This is much better than waiting for a form submit but could cause DOS attacks against the server. edburns: This is true for any Ajax solution. This is not a fault of JSF. Any Ajax allows users to leave themselves open to this problem. Just press the TAB-button, let the cursor jump from input field to input... [...] The integration of the Hibernate Validation framework (Bean Validation spec) looked liked a great improvement on the first view. You add annotations like @Size or @Length to a field of the managed bean or directly in an entity bean. This allows to use the same set of validation rules for Hibernate and for JSF. This is pretty nice and the integration works like a charm. The problem is actually not a problem of JSF but of Bean Validation. Somehow in the last moment, they changed the group validation to use class name instead of strings. edburns: Ah yes, type safety is a knife that cuts both ways, isn't it? Group validations are an important feature to... [...]
To summarize, the lack of a DI container as core of the framework is a disadvantage of JSF. I assume that this is again a tribute to be backward compatible. edburns: I'm quite sure that if JSF introduced its own DI container then you'd be saying something like, "this is yet another reason why JSF is bloated...". The fact is, the [...] JSF EG is not the DI EG. Different experts, different expertise. Also, separation of concerns is vitally important. Surely you know that innovation happens elsewhere.
Future of web frameworksI will add this section after the Devoxx conference end of November. It is an outlooked how component oriented frameworks could change.... [...] SecurityThere is no build in security but you will find examples how to integrate JSF with Spring Security. edburns: What do you mean by that? We've had the ability to encrypt the view state since JSF 1.2. Security is a cross cutting concern that was baked into every design decision. If you use JSF with JBoss Seam,... [...] |
Technorati Tags: edburns