Advantages of JSF
JSF is like an extension to Struts. It follows MVC design pattern and has all the advantages of MVC. A front control to route the events and separation of business logic from view. But whether it has all the advantages of Struts or not is a different discussion. JSF adds to the MVC design pattern a component based architecture to build the view. Each component is a self contained entity. Components like dropdown are coded in JAVA and they take care of rendering required HTML and Javascript, validating submitted data and updating models (Java beans). This architecture has lead to vendors who can independently develop newer components. It's quite a powerful concept.
Disadvantages of JSF
First problem that is quite prominent is its validation framework. Though it sounds great that a component would know what validation applies to it. But think hard, do we really validate a component or we validate data based ? It's an important question. Lets analyze a use case. Say you are creating profile on a website. You have 3 options, namely, save, publish or cancel. If you save, you just need to validate profile name, rest is not yet complete so we need to skip. While publishing the profile every field require validation. When we cancel, not even profile name is required. So, you can see a validation requirement actually depends on the event that you are generating. JSF will be a nuisance while achieving this scenario. If you set a component as required="true", it will validate for anything and everything. JSF gives a workaround for buttons that don't require validation. An attribute immediate="true". The idea is this button will invoke its action immediately. But as you can see. The scope is very limited. If some action requires a different kind of validation, there is simply no way to achieve it. To top it all, you can't customize the error messages for a component differently on different pages. It will keep throwing "value is required" even if you want components to say "First Name is required" and "Email is required".
Second in the list is life cycle. Though component life cycle is one of the selling features of JSF it has shortcomings. It provides adequate steps for submitting data, like restore view, validate, update model and application invocation. But while rendering it makes it a one step process, which is render response. Before render response there is no process for the view to be rendered and after render response it is all done. Many developers get confused with this fact. But dig deep and you will find that in the flow from Login.jsp to Home.jsp. All steps/phases before render response belongs to Login.jsp and there is just one step for Home.jsp which is render response phase. If you are using JSP based view handler then in this phase, both component tree and render HTML get generated simultaneously. If you are using Facelets then it becomes two step process where in the first step a component tree is created then in the next step HTML is generated. This gives Facelets the ability to add features like templates, composition and decoration of web page snippets. But for component developers, available methods to hook their code in are encodeBegin() for start of a tag and encodeEnd() for end of a tag. There are multiple steps that a component architecture needs to provide:
- Attribute value evaluation
- Component addition to the component tree
- Child component creation
- Component rendering
Shortcomings of JSF
There are some features of JSF that doesn't fall under disadvantages but they fall well short of what they could have achieved.
First one is the navigation architecture. It is an improvement over Struts navigation but it doesn't achieve what it should. Through JSF navigation you can configure the destination of a web page for various events. If the requirement is to return to the page where the current page was reached from, then you will start thinking about hacks. For example, customer search can be performed from various screens, once you select a customer you need to return to the calling page. There is no way to configure that. There is no concept of a flow which will encapsulate few pages that form a unit. Navigation doesn't reflect the action that results in the event generation. Actions are configured on the web page. The features that I am talking about are not very apparent till you read and use a framework like Spring Webflow and Seam. We will discuss these frameworks in a different article.
Second is the managed bean concept. Though managed bean concept sounds great. It serves most of the purpose but where it falls short is that it fails to enforce SOA. The action methods inside a managed bean is supposed to call methods on a delegate class and return the event. But there is no way to restrict developers from writing large amount of business logic in it. If you really want your application to follow SOA, then all the business logic should go to some service method.
Imagine a framework that doesn't fall short on any of the features mentioned above and then provides you lot more. You must have a look at the framework I have created at
I guarantee that you will not find a better one than this ever.
