Fundamental flaws in Java Server Faces
Fundamental flaws in Java Server Faces (JSF)
After working with Struts framework for many years I wanted to try something new and decided to investigate JSF. I was very impressed with my initial evaluation and recently used it in one of my project. Middle of the project I released many glaring issue with the framework and had to break my head to complete the project on time.
One of the major reasons why I choose JSF was that it had a clean way of mapping a form to a bean(s) and a nice way to perform form actions and navigation between forms.
Although the framework is very promising in many ways, I think the framework is not yet complete and the developer has to fix lot of holes to make the application to work properly.
Following are the glaring functionality that is missing or confusing or messed up in JSF.
1)JSF does not provide a way to disable PROCESS_VALIDATION phase. For some reason if one wants to skip one phase another, JSF has made it near to impossible to skip.
2)The framework does not provide an easy way to invoke an action method directly by calling a URL (Similar to Struts action method invocation). This is very essential because many/most of the time one needs to check the authorizations of the user to view a page.
3)JSF does not support form GET method. They are giving all sorts of reasons not to do this. It抯 practically very difficult to develop an application with just POST operations.
4)There should be an easy way for the developer to tell JSF not to copy the request to the backing bean or at least skip the event phase that copies the request to the backing bean.
5)JSF does many operations in each phases. JSF should not overload multiple operations in one phase. Custom validation should be separated from native framework validation. Calling a command button with immediate set to true should be a separate phase event. This should not be mixed with other operation.
6)It is very difficult or near to impossible to programmatically unit test JSF application. I don抰 know what they thought when they developed this framework. Dude抯 we are in the TDD time period, not 4GL.
7)In my opinion one or more backing beans can be linked to a page and a page can be made up of one or more jsp抯. The fundamental flaw with the JSF is that JSF tries to dynamically map a jsp collection to beans. I don抰 know who decided this model. They should have implemented such that the user in the faces xml or dynamically say what beans maps to a jsp page. Then they can copy the request objects to the bean and then do other stuff. This way the framework will give lot of control to the developer. In my opinion, if they have to do this then they will have to implement the 憇truts?action controller framework and then extend the JSF framework on top of it.
8)The framework has some piece of implementation very easy like mapping the bean to the form and command actions and the others near to impossible to understand or make it to work.
I am surprised to see big players like IBM and Oracle backing this product. What I don抰 understand is why?What are they betting for?
Anyway, I will definitely keep an eye on the JSF progress. But for now, let me take care of my bum. It was a bumpy ride working with JSF framework.
[3334 byte] By [
leo9aa] at [2007-10-2 12:41:21]
Just a few notes. Some of what you listed is potentially valid. And other points could be clarified with a better understanding of JSF framework and its life cycle. But to try answering your last question.
The big Java players like IBM are trying to compete and catch up with what Microsfot did with ASP.NET (please read a bit about this model or framework)
I think the main barrier that traditional Java web programmers need to overcome to better appreciate JSF is how they have done business so far. Essentially top to bottom scripting of a JSP page using JSTL while mixing HTML and Java code.
Perhaps the big players like IBM recognize the need for web programming to progress and go to the next level. Hence providing a clean separation between the code and presentation layer by using a well structured framework life cycle, a component based one, event driven, object oriented and easy to develop (a RAD paradigm).
Check out WSAD or RAD 6 IBM JSF provided implementation. A rich library that fully implements a code behind concept (a great separation between a JSP file and java code that drives it), a templating capability (very close to page inheritance), a pageload/postback events and much more. Basically progressing toward the rich/client programming paradigm.
I am not very experience or expert in jsf...
But i would like share my thought/ answer on this issue.
1) JSF does not provide a way to disable PROCESS_VALIDATION phase. For some reason if one wants to skip one phase another, JSF has made it near to impossible to skip.
- YES.....jsf make it impossible to disable validation. But it does make it possible to skip some validation with immediate attribute. Anyway..based on My experienc working on immediate attribute.....it was not so easy/flexible to skip the validation as compared to struts..
2) The framework does not provide an easy way to invoke an action method directly by calling a URL (Similar to Struts action method invocation). This is very essential because many/most of the time one needs to check the authorizations of the user to view a page.
-I am not sure about this.......But i personally think jsf does not provide this functionality.
3) JSF does not support form GET method. They are giving all sorts of reasons not to do this. It抯 practically very difficult to develop an application with just POST operations.
- YES....I personally also feel that this is a BIG disadvantage...
4) There should be an easy way for the developer to tell JSF not to copy the request to the backing bean or at least skip the event phase that copies the request to the backing bean.
- YES...agreed.....jsf should make this easier..
5) JSF does many operations in each phases. JSF should not overload multiple operations in one phase. Custom validation should be separated from native framework validation. Calling a command button with immediate set to true should be a separate phase event. This should not be mixed with other operation.
- No comment..
6) It is very difficult or near to impossible to programmatically unit test JSF application. I don抰 know what they thought when they developed this framework. Dude抯 we are in the TDD time period, not 4GL.
7) In my opinion one or more backing beans can be linked to a page and a page can be made up of one or more jsp抯. The fundamental flaw with the JSF is that JSF tries to dynamically map a jsp collection to beans. I don抰 know who decided this model. They should have implemented such that the user in the faces xml or dynamically say what beans maps to a jsp page. Then they can copy the request objects to the bean and then do other stuff. This way the framework will give lot of control to the developer. In my opinion, if they have to do this then they will have to implement the 憇truts?action controller framework and then extend the JSF framework on top of it.
- No really understand what u trying to say...But I dun think this should be a isssue...
8) The framework has some piece of implementation very easy like mapping the bean to the form and command actions and the others near to impossible to understand or make it to work.
- What is the "other" mean?
